draft-ietf-dots-architecture-03.txt   draft-ietf-dots-architecture-04.txt 
DOTS A. Mortensen DOTS A. Mortensen
Internet-Draft Arbor Networks Internet-Draft Arbor Networks
Intended status: Informational F. Andreasen Intended status: Informational F. Andreasen
Expires: December 7, 2017 Cisco Expires: January 4, 2018 Cisco
T. Reddy T. Reddy
McAfee, Inc. McAfee, Inc.
C. Gray C. Gray
Comcast Comcast
R. Compton R. Compton
Charter Charter
N. Teague N. Teague
Verisign Verisign
June 05, 2017 July 03, 2017
Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture
draft-ietf-dots-architecture-03 draft-ietf-dots-architecture-04
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 44 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 December 7, 2017. This Internet-Draft will expire on January 4, 2018.
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 37 skipping to change at page 2, line 37
1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
2. DOTS 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 . . . . . . . . . . . . . . . . 12 2.3. DOTS Agent Relationships . . . . . . . . . . . . . . . . 12
2.3.1. Gatewayed Signaling . . . . . . . . . . . . . . . . . 14 2.3.1. Gatewayed Signaling . . . . . . . . . . . . . . . . . 14
3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Signaling Sessions . . . . . . . . . . . . . . . . . . . 16 3.1. DOTS 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 DOTS Session . . . . . . . . . . . . 16
3.1.3. Maintaining the Signaling Session . . . . . . . . . . 17 3.1.3. Maintaining the DOTS Session . . . . . . . . . . . . 17
3.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 18 3.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 18
3.2.1. Direct Signaling . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . 24 3.3.1. Manual Mitigation Request . . . . . . . . . . . . . . 24
3.3.2. Automated Conditional Mitigation Request . . . . . . 25 3.3.2. Automated Conditional Mitigation Request . . . . . . 25
3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 26 3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 26
4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 4. Security Considerations . . . . . . . . . . . . . . . . . . . 26
skipping to change at page 4, line 45 skipping to change at page 4, line 45
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 administrators servers based on criteria determined by DOTS client administrators
and the underlying network configuration. The number of DOTS and the underlying network configuration. The number of DOTS
servers with which a given DOTS client has established signaling servers with which a given DOTS client has established
sessions is determined by local policy and is deployment-specific. communications is determined by local policy and is deployment-
For example, a DOTS client of a multi-homed network may support specific. For example, a DOTS client of a multi-homed network may
built-in policies to establish DOTS relationships with DOTS support built-in policies to establish DOTS relationships with
servers located upstream of each interconnection link. 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.
skipping to change at page 6, line 42 skipping to change at page 6, line 42
| | <------- 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 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(s). The client signal may also information about the attack target(s). The client signal may also
include telemetry information about the attack, if the DOTS client include telemetry information about the attack, if the DOTS client
has such information available. The DOTS server in turn sends a has such information available. The DOTS server in turn sends a
server signal to inform the DOTS client of whether it will honor the server signal to inform the DOTS client of whether it will honor the
mitigation request. Assuming it will, the DOTS server initiates mitigation request. Assuming it will, the DOTS server initiates
skipping to change at page 10, line 7 skipping to change at page 10, line 7
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 administrator. 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 signal
signaling session from a disconnected or defunct session, the DOTS channel from a disconnected or defunct session, the DOTS client sends
client sends a heartbeat over the signal channel to maintain its half a heartbeat over the signal channel to maintain its half of the
of the signaling session. The DOTS client similarly expects a channel. The DOTS client similarly expects a heartbeat from the DOTS
heartbeat from the DOTS server, and may consider a signaling session server, and may consider a session terminated in the extended absence
terminated in the extended absence of a DOTS server heartbeat. 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
DOTS clients. The DOTS server authenticates and authorizes DOTS DOTS clients. The DOTS server authenticates and authorizes DOTS
clients as described in Section 3.1, and maintains signaling session clients as described in Section 3.1, and maintains session state,
state, tracking requests for mitigation, reporting on the status of tracking requests for mitigation, reporting on the status of active
active mitigations, and terminating signaling sessions in the mitigations, and terminating sessions in the extended absence of a
extended absence of a client heartbeat or when a session times out. client heartbeat or 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 session with a DOTS server may reasonably
reasonably expect some level of mitigation in response to a request expect some level of mitigation in response to a request for
for coordinated attack response. 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
administrative domain, such that a DOTS client from one domain is not administrative domain, such that a DOTS client from one domain is not
able to influence the network path to another domain. A DOTS server able to influence the network path to another domain. A DOTS server
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,
skipping to change at page 11, line 10 skipping to change at page 11, line 10
not in scope: it may be as simple as an alert to mitigator operators, not in scope: it may be as simple as an alert to mitigator operators,
or highly automated using vendor or open application programming or highly automated using vendor or open application programming
interfaces supported by the mitigator. The DOTS server MUST report interfaces supported by the mitigator. The DOTS server MUST report
the actual scope of any mitigation enabled on behalf of a client. the actual scope of any mitigation enabled on 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 signal
signaling session from a disconnected or defunct session, the DOTS channel from a disconnected or defunct channel, the DOTS server MUST
server MUST send a heartbeat over the signal channel to maintain its send a heartbeat over the signal channel to maintain its half of the
half of the signaling session. The DOTS server similarly expects a channel. The DOTS server similarly expects a heartbeat from the DOTS
heartbeat from the DOTS client, and MAY consider a signaling session client, and MAY consider a session terminated in the extended absence
terminated in the extended absence of a DOTS client heartbeat. of a DOTS client heartbeat.
2.2.3. DOTS Gateway 2.2.3. DOTS Gateway
Traditional client/server relationships may be expanded by chaining Traditional client/server relationships may be expanded by chaining
DOTS sessions. This chaining is enabled through "logical DOTS sessions. This chaining is enabled through "logical
concatenation" of a DOTS server and a DOTS client, resulting in an concatenation" of a DOTS server and a DOTS client, resulting in an
application analogous to the SIP logical entity of a Back-to-Back application analogous to the SIP logical entity of a Back-to-Back
User Agent (B2BUA) [RFC7092]. The term DOTS gateway is used here in User Agent (B2BUA) [RFC7092]. The term DOTS gateway is used here in
the descriptions of selected scenarios involving this application. the descriptions of selected scenarios involving 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 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 | | +----+
skipping to change at page 13, line 48 skipping to change at page 13, line 48
consequently to include measures aimed at reducing the likelihood of consequently to include measures aimed at reducing the likelihood of
negative outcomes. Simple measures might include: negative outcomes. Simple measures might include:
o Requesting mitigation serially, ensuring only one mitigation o Requesting mitigation serially, ensuring only one mitigation
request for a given address space is active at any given time; request for a given address space is active at any given time;
o Dividing the protected resources among the DOTS servers, such that o Dividing the protected resources among the DOTS servers, such that
no two mitigators will be attempting to divert and scrub the same no two mitigators will be attempting to divert and scrub the same
traffic; traffic;
o Using multi-homing for redundancy only. In this case, the DOTS o Restricting multi-homing to deployments in which all DOTS servers
servers would be affiliated, and through shared communications are coordinating management of a shared pool of mitigation
ensure that the redundant mitigation requests do not result in resources.
overlapping traffic diversion announcements.
2.3.1. Gatewayed Signaling 2.3.1. Gatewayed Signaling
As discussed in Section 2.2.3, a DOTS gateway is a logical function As discussed in Section 2.2.3, a DOTS gateway is a logical function
chaining signaling sessions through concatenation of a DOTS server chaining DOTS sessions through concatenation of a DOTS server and
and DOTS client. DOTS client.
An example scenario, as shown in Figure 7 and Figure 8, is for an An example scenario, as shown in Figure 7 and Figure 8, is for an
enterprise to have deployed multiple DOTS capable devices which are enterprise to have deployed multiple DOTS capable devices which are
able to signal intra-domain using TCP [RFC0793] on un-congested links 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] to a DOTS gateway which may then transform these to a UDP [RFC0768]
transport inter-domain where connection oriented transports may transport inter-domain where connection oriented transports may
degrade; this applies to the signal channel only, as the data channel degrade; this applies to the signal channel only, as the data channel
requires a connection-oriented transport. The relationship between requires a connection-oriented transport. The relationship between
the gateway and its upstream agents is opaque to the initial clients. the gateway and its upstream agents is opaque to the initial clients.
skipping to change at page 16, line 7 skipping to change at page 16, line 7
This document anticipates scenarios involving multiple DOTS gateways. This document anticipates scenarios involving multiple DOTS gateways.
An example is a DOTS gateway at the network client's side, and 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 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 a CPE to aggregate requests from multiple DOTS clients enabled in an
enterprise network. The second DOTS gateway is deployed on the enterprise network. The second DOTS gateway is deployed on the
provider side. This scenario can be seen as a combination of the provider side. This scenario can be seen as a combination of the
client-side and server-side scenarios. client-side and server-side scenarios.
3. Concepts 3. Concepts
3.1. Signaling Sessions 3.1. DOTS 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 A DOTS session is established, bilateral exchange of data between an
session. At its most basic, for a DOTS signaling session to exist associated DOTS client and a DOTS server. In the DOTS architecture,
both signal channel and data channel must be functioning between DOTS data is exchanged between DOTS agents over signal and data channels.
agents. That is, under nominal network conditions, signals actively Regardless, a DOTS session is characterized by the presence of an
sent from a DOTS client are received by the specific DOTS server established signal channel. A data channel associated with a signal
intended by the client, and vice versa. channel may be thought of as part of the DOTS session, but the
termination of that data channel does not terminate the DOTS session.
Conversely, a DOTS session cannot exist without an established signal
channel: when an established signal channel is terminated for any
reason, the DOTS session is also said to be terminated.
3.1.1. Preconditions 3.1.1. Preconditions
Prior to establishing a signaling session between agents, the owners Prior to establishing a DOTS session between agents, the owners of
of the networks, domains, services or applications involved are the networks, domains, services or applications involved are assumed
assumed to have agreed upon the terms of the relationship involved. to have agreed upon the terms of the relationship involved. Such
Such agreements are out of scope for this document, but must be in agreements are out of scope for this document, but must be in place
place for a functional DOTS architecture. for a functional DOTS architecture.
It is assumed that as part of any DOTS service agreement, the DOTS It is assumed that as part of any DOTS service agreement, the DOTS
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 DOTS Session
With the required business agreements in place, the DOTS client With the required business agreements in place, the DOTS client
initiates a signal session by contacting its DOTS server(s) over the initiates a signal session by contacting its DOTS server(s) over 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
skipping to change at page 17, line 26 skipping to change at page 17, line 30
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].
The DOTS client SHOULD successfully authenticate and exchange The DOTS client SHOULD successfully authenticate and exchange
messages with the DOTS server over both signal and data channel as messages with the DOTS server over both signal and data channel as
soon as possible to confirm that both channels are operational. soon as possible to confirm that both channels are operational.
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 DOTS session.
session. A signaling session is not active until DOTS agents have A DOTS session is not active until DOTS agents have agreed on the
agreed on the values for these signaling session parameters, a values for these DOTS session parameters, a process defined by the
process defined by the protocol. protocol.
Once the DOTS client begins receiving DOTS server signals, the Once the DOTS client begins receiving DOTS server signals, the DOTS
signaling session is active. At any time during the signaling session is active. At any time during the DOTS session, the DOTS
session, the DOTS client may use the data channel to adjust initial client may use the data channel to adjust initial configuration,
configuration, manage black- and white-listed prefixes or addresses, manage black- and white-listed prefixes or addresses, leverage
leverage vendor-specific extensions, and so on. Note that unlike the vendor-specific extensions, and so on. Note that unlike the signal
signal channel, there is no requirement that the data channel remain 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 DOTS 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
[I-D.ietf-dots-requirements]. DOTS agent operators SHOULD configure [I-D.ietf-dots-requirements]. DOTS agent operators SHOULD configure
the heartbeat interval such that the frequency does not lead to the heartbeat interval such that the frequency does not lead to
accidental denials of service due to the overwhelming number of accidental denials of service due to the overwhelming number of
heartbeats a DOTS agent must field. heartbeats a DOTS agent must field.
Either DOTS agent may consider a signaling session terminated in the Either DOTS agent may consider a DOTS session terminated in the
extended absence of a heartbeat from its peer agent. The period of extended absence of a heartbeat from its peer agent. The period of
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 DOTS session may take the form of direct signaling between the DOTS
DOTS clients and servers, as shown in Figure 11. 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 DOTS session, DOTS client and server are communicating
communicating directly. A direct signaling session may exist inter- directly. Direct signaling may exist inter- or intra-domain. The
or intra-domain. The signaling session is abstracted from the DOTS session is abstracted from the underlying networks or network
underlying networks or network elements the signals traverse: in a elements the signals traverse: in direct signaling, the DOTS client
direct signaling session, the DOTS client and server are logically and server are logically adjacent.
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 DOTS 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 DOTS 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 DOTS session resembles the following, as shown in
shown in Figure 12. Figure 12.
+-------------+ +---------------+ +-------------+ +---------------+
| |<-(1)-- signal session 1 -->| | | |<-(1)--- DOTS 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)--- DOTS session 1 ---X| |
| | | | | | | |
| | | | | | | |
+-------------+ +---------------+ +-------------+ +---------------+
^ ^
| |
(3) signal session 2 (3) DOTS 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 DOTS session 1 exists between a DOTS
client and DOTS server 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 DOTS session
session with the redirection target, the DOTS client initiates with the redirection target, the DOTS client initiates and
and establishes a signaling session with DOTS server B. establishes DOTS session 2 with DOTS server B.
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. DOTS 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
and mitigators. and mitigators.
In the course of normal DOTS operations, a DOTS client communicates In the course of normal DOTS operations, a DOTS client communicates
the need for mitigation to a DOTS server, and that server initiates the need for mitigation to a DOTS server, and that server initiates
skipping to change at page 20, line 20 skipping to change at page 20, line 20
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 offers an A recursive signaling model as shown in Figure 13 offers an
alternative. In a variation of the use case "Enterprise with an alternative. In a variation of the use case "Enterprise with an
upstream transit provider DDoS mitigation service" described in upstream transit provider DDoS mitigation service" described in
[I-D.ietf-dots-use-cases], a domain operating a DOTS server and [I-D.ietf-dots-use-cases], a domain operating a DOTS server and
mitigator also operates a DOTS client. This DOTS client has an mitigator also operates a DOTS client. This DOTS client has an
established signaling session with a DOTS server belonging to a established DOTS session with a DOTS server belonging to a separate
separate administrative domain. 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 . +----+ +-----------+ . +----+ 1 . +----+ +-----------+ .
| Cc |<--------->| Sn |~~~~~~~| Mitigator | . | Cc |<--------->| Sn |~~~~~~~| Mitigator | .
+----+ . +====+ | Mn | . +----+ . +====+ | Mn | .
. | Cn | +-----------+ . . | Cn | +-----------+ .
example.com . +----+ . example.com . +----+ .
client . ^ . client . ^ .
. . .|. . . . . . . . . . . . . . . . .|. . . . . . . . . . . . . .
| |
B | 1 |
| |
. . .|. . . . . . . . . . . . . . . . .|. . . . . . . . . . . . . .
. v . . v .
. +----+ +-----------+ . . +----+ +-----------+ .
. | So |~~~~~~~| Mitigator | . . | So |~~~~~~~| Mitigator | .
. +----+ | Mo | . . +----+ | Mo | .
. +-----------+ . . +-----------+ .
. . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
example.org domain example.org domain
Figure 13: Recursive Signaling Figure 13: Recursive Signaling
In Figure 13, 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 DOTS session 1 to the DOTS server Sn belonging to the
the example.net domain. DOTS server Sn enables mitigation on example.net domain. DOTS server Sn enables mitigation on mitigator
mitigator Mn. DOTS server Sn is half of DOTS gateway Gn, being Mn. DOTS server Sn is half of DOTS gateway Gn, being deployed
deployed logically back-to-back with DOTS client Cn, which has pre- logically back-to-back with DOTS client Cn, which has pre-existing
existing inter-domain signaling session B with the DOTS server So inter-domain DOTS session 2 with the DOTS server So belonging to the
belonging to the example.org domain. At any point, DOTS server Sn example.org domain. At any point, DOTS server Sn MAY recurse an on-
MAY recurse an on-going mitigation request through DOTS client Cn to going mitigation request through DOTS client Cn to DOTS server So, in
DOTS server So, in the expectation that mitigator Mo will be the expectation that mitigator Mo will be activated to aid in the
activated to aid in the defense of the attack target. 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]). requirements ([I-D.ietf-dots-requirements]).
[[EDITOR'S NOTE: Recursive signaling raises questions about Deployment of recursive signaling may result in traffic redirection,
operational and data privacy, as well as what level of visibility a examination and mitigation extending beyond the initial bilateral
client has into the recursed mitigation. We ask the working group relationship between DOTS client and DOTS server. As such, client
for feedback and additional discussion of these issues to help settle control over the network path of mitigated traffic may be reduced.
the way forward.]] DOTS client operators should be aware of any privacy concerns, and
work with DOTS server operators employing recursive signaling to
ensure shared sensitive material is suitably protected.
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
within a DOTS deployment, but neither does the architecture exclude within a DOTS deployment, but neither does the architecture exclude
it. Domains operating DOTS servers MAY deploy DOTS servers with an it. Domains operating DOTS servers MAY deploy DOTS servers with an
anycast Service Address as described in BCP 126 [RFC4786]. In such a anycast Service Address as described in BCP 126 [RFC4786]. In such a
deployment, DOTS clients connecting to the DOTS Service Address may deployment, DOTS clients connecting to the DOTS Service Address may
be communicating with distinct DOTS servers, depending on the network be communicating with distinct DOTS servers, depending on the network
configuration at the time the DOTS clients connect. Among other configuration at the time the DOTS clients connect. Among other
benefits, anycasted signaling potentially offers the following: benefits, anycast signaling potentially offers the following:
o Simplified DOTS client configuration, including service discovery o Simplified DOTS client configuration, including service discovery
through the methods described in [RFC7094]. In this scenario, the through the methods described in [RFC7094]. In this scenario, the
"instance discovery" message would be a DOTS client initiating a "instance discovery" message would be a DOTS client initiating a
signaling session to the DOTS server anycast Service Address, to DOTS session to the DOTS server anycast Service Address, to which
which the DOTS server would reply with a redirection to the DOTS the DOTS server would reply with a redirection to the DOTS server
server unicast address the client should use for DOTS. unicast address the client should use for DOTS.
o Region- or customer-specific deployments, in which the DOTS o Region- or customer-specific deployments, in which the DOTS
Service Addresses route to distinct DOTS servers depending on the Service Addresses route to distinct DOTS servers depending on the
client region or the customer network in which a DOTS client client region or the customer network in which a DOTS client
resides. resides.
o Operational resiliency, spreading DOTS signaling traffic across o Operational resiliency, spreading DOTS signaling traffic across
the DOTS server domain's networks, and thereby also reducing the the DOTS server domain's networks, and thereby also reducing the
potential attack surface, as described in BCP 126 [RFC4786]. potential attack surface, as described in BCP 126 [RFC4786].
skipping to change at page 23, line 8 skipping to change at page 23, line 8
As long as network configuration remains stable, anycast DOTS As long as network configuration remains stable, anycast DOTS
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.
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, Network instability is of particular concern with anycast signaling,
as DOTS signaling sessions are expected to be long-lived, and as DOTS signal channels 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
may not have the security state of the existing session, forcing the may not have the security state of the existing session, forcing the
DOTS client to initialize a new signaling session. This challenge DOTS client to initialize a new DOTS session. This challenge might
may in part be mitigated by use of pre-shared keys, as described in in part be mitigated by use of pre-shared keys and session resumption
[I-D.ietf-tls-tls13], but keying material must be available to all [RFC5246][RFC6347], but keying material must be available to all DOTS
DOTS servers sharing the anycast Service Address in that case. servers sharing the anycast Service Address in that case.
While the DOTS client will try to establish a new signaling session While the DOTS client will try to establish a new DOTS session with
with the DOTS server now acting as the anycast DOTS Service Address, the DOTS server now acting as the anycast DOTS Service Address, the
the link between DOTS client and server may be congested with attack link between DOTS client and server may be congested with attack
traffic, making signal session establishment difficult. In such a traffic, making signal session establishment difficult. In such a
scenario, anycast Service Address instability becomes a sort of scenario, anycast Service Address instability becomes a sort of
signal session flapping, with obvious negative consequences for the signal session flapping, with obvious negative consequences for the
DOTS deployment. DOTS deployment.
Anycast signaling deployments similarly must also take into account Anycast signaling deployments similarly must also take into account
active mitigations. Active mitigations initiated through a signaling active mitigations. Active mitigations initiated through a DOTS
session may involve diverting traffic to a scrubbing center. If the session may involve diverting traffic to a scrubbing center. If the
signaling session flaps due to anycast changes as described above, DOTS session flaps due to anycast changes as described above,
mitigation may also flap as the DOTS servers sharing the anycast DOTS mitigation may also flap as the DOTS servers sharing the anycast DOTS
service address toggles mitigation on detecting signaling session service address toggles mitigation on detecting DOTS session loss,
loss, depending on whether the client has configured mitigation on depending on whether the client has configured mitigation on loss of
loss of signal. signal.
3.3. Triggering Requests for Mitigation 3.3. Triggering Requests for Mitigation
[I-D.ietf-dots-requirements] places no limitation on the [I-D.ietf-dots-requirements] places no limitation on the
circumstances in which a DOTS client operator may request mitigation, circumstances in which a DOTS client operator may request mitigation,
nor does it demand justification for any mitigation request, thereby nor does it demand justification for any mitigation request, thereby
reserving operational control over DDoS defense for the domain reserving operational control over DDoS defense for the domain
requesting mitigation. This architecture likewise does not prescribe requesting mitigation. This architecture likewise does not prescribe
the network conditions and mechanisms triggering a mitigation request the network conditions and mechanisms triggering a mitigation request
from a DOTS client. from a DOTS client.
skipping to change at page 26, line 7 skipping to change at page 26, line 7
When automated conditional mitigation requests are enabled, When automated conditional mitigation requests are enabled,
violations of any of the above conditions, or any additional violations of any of the above conditions, or any additional
operator-defined conditions, will trigger a mitigation request from operator-defined conditions, will trigger a mitigation request from
the DOTS client to the DOTS server. The interfaces between the the DOTS client to the DOTS server. The interfaces between the
application detecting the condition violation and the DOTS client are application detecting the condition violation and the DOTS client are
implementation-specific. implementation-specific.
3.3.3. Automated Mitigation on Loss of Signal 3.3.3. Automated Mitigation on Loss of Signal
To maintain a signaling session, the DOTS client and the DOTS server To maintain a DOTS session, the DOTS client and the DOTS server
exchange regular but infrequent messages across the signaling exchange regular but infrequent messages across the signal channel.
channel. In the absence of an attack, the probability of message In the absence of an attack, the probability of message loss in the
loss in the signaling channel should be extremely low. Under attack signaling channel should be extremely low. Under attack conditions,
conditions, however, some signal loss may be anticipated as attack however, some signal loss may be anticipated as attack traffic
traffic congests the link, depending on the attack type. congests the link, depending on the attack type.
While [I-D.ietf-dots-requirements] specifies the DOTS protocol be While [I-D.ietf-dots-requirements] specifies the DOTS protocol be
robust when signaling under attack conditions, there are nevertheless robust when signaling under attack conditions, there are nevertheless
scenarios in which the DOTS signal is lost in spite of protocol best scenarios in which the DOTS signal is lost in spite of protocol best
efforts. To handle such scenarios, a DOTS client operator may efforts. To handle such scenarios, a DOTS client operator may
configure the signaling session to trigger mitigation when the DOTS configure the DOTS session to trigger mitigation when the DOTS server
server ceases receiving DOTS client signals (or vice versa) beyond ceases receiving DOTS client signals (or vice versa) beyond the miss
the miss count or period permitted by the protocol. count or period permitted by the protocol.
The impact of mitigating due to loss of signal in either direction The impact of mitigating due to loss of signal in either direction
must be considered carefully before enabling it. Signal loss is not must be considered carefully before enabling it. Signal loss is not
caused by links congested with attack traffic alone, and as such caused by links congested with attack traffic alone, and as such
mitigation requests triggered by signal channel degradation in either mitigation requests triggered by signal channel degradation in either
direction may incur unnecessary costs, in network performance and direction may incur unnecessary costs, in network performance and
operational expense alike. operational expense alike.
4. Security Considerations 4. Security Considerations
skipping to change at page 27, line 6 skipping to change at page 27, line 6
mitigation activities or subvert black/whitelists. From an mitigation activities or subvert black/whitelists. From an
architectural standpoint, operators SHOULD ensure best current architectural standpoint, operators SHOULD ensure best current
practices for secure communication are observed for data and signal practices for secure communication are observed for data and signal
channel confidentiality, integrity and authenticity. Care must be channel confidentiality, integrity and authenticity. Care must be
taken to ensure transmission is protected by appropriately secure taken to ensure transmission is protected by appropriately secure
means, reducing attack surface by exposing only the minimal required means, reducing attack surface by exposing only the minimal required
services or interfaces. Similarly, received data at rest SHOULD be services or interfaces. Similarly, received data at rest SHOULD be
stored with a satisfactory degree of security. stored with a satisfactory degree of security.
As many mitigation systems employ diversion to scrub attack traffic, As many mitigation systems employ diversion to scrub attack traffic,
operators of DOTS agents SHOULD ensure signaling sessions are operators of DOTS agents SHOULD ensure DOTS sessions are resistant to
resistant to Man-in-the-Middle (MitM) attacks. An attacker with Man-in-the-Middle (MitM) attacks. An attacker with control of a DOTS
control of a DOTS client may negatively influence network traffic by client may negatively influence network traffic by requesting and
requesting and withdrawing requests for mitigation for particular withdrawing requests for mitigation for particular prefixes, leading
prefixes, leading to route or DNS flapping. 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. Contributors 5. Contributors
Mohamed Boucadair Mohamed Boucadair
skipping to change at page 27, line 48 skipping to change at page 27, line 48
[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>.
8.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-05 (work in
progress), March 2017. progress), June 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 (DDoS) Open Threat Signaling", Open Threat Signaling (DDoS) Open Threat Signaling",
draft-ietf-dots-use-cases-05 (work in progress), May 2017. 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, [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>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
skipping to change at page 28, line 47 skipping to change at page 28, line 42
[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>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <http://www.rfc-editor.org/info/rfc4786>. December 2006, <http://www.rfc-editor.org/info/rfc4786>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>. <http://www.rfc-editor.org/info/rfc6763>.
[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 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
 End of changes. 55 change blocks. 
150 lines changed or deleted 149 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/