draft-ietf-dots-architecture-04.txt   draft-ietf-dots-architecture-05.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: January 4, 2018 Cisco Expires: April 28, 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
July 03, 2017 October 25, 2017
Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture
draft-ietf-dots-architecture-04 draft-ietf-dots-architecture-05
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 January 4, 2018. This Internet-Draft will expire on April 28, 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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
skipping to change at page 3, line 4 skipping to change at page 3, line 4
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
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 27 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.1. Normative References . . . . . . . . . . . . . . . . . . 27
8.1. Normative References . . . . . . . . . . . . . . . . . . 27 7.2. Informative References . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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
skipping to change at page 4, line 16 skipping to change at page 4, line 15
valuable in their own right, as when aggregating intra-domain DOTS valuable in their own right, as when aggregating intra-domain DOTS
client signals for inter-domain coordinated attack response. client signals for inter-domain coordinated attack 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 A detailed set of DOTS requirements are discussed in
[I-D.ietf-dots-requirements], and the DOTS architecture is assumed to [I-D.ietf-dots-requirements], and the DOTS architecture is designed
follow those requirements. Only new behavioral requirements are to follow those requirements. Only new behavioral requirements are
described in this document. 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
attack [RFC4732]. Some operators may utilize non-impacted paths attack [RFC4732]. Some operators may utilize non-impacted paths
or networks for DOTS, but in general conditions should be assumed or networks for DOTS, but in general conditions should be assumed
to be hostile and that DOTS must be able to function in all to be hostile and DOTS must be able to function in all
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
skipping to change at page 5, line 33 skipping to change at page 5, line 30
when available. However, DOTS itself does not address how that when available. However, DOTS itself does not address how that
may be done. 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 and data channels may be loosely coupled, and may not o The signal and data channels are loosely coupled, and may not
terminate on the same DOTS server. terminate on the same DOTS server.
2. DOTS 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 |
+-----------+ +-------------+ +-----------+ +-------------+
| |
skipping to change at page 6, line 28 skipping to change at page 6, line 24
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 is 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 The DOTS client may be provided with a list of DOTS servers, each
server and the DOTS client. associated with one or more IP addresses. These addresses may or may
not be of the same address family. The DOTS client establishes one
or more sessions by connecting to the provided DOTS server addresses.
As illustrated in Figure 2, there are two interfaces between a DOTS
server and a DOTS client; a signal channel and (optionally) a data
channel.
+---------------+ +---------------+ +---------------+ +---------------+
| | <------- 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
associated with one or more IP addresses. These addresses may or may
not be of the same address family. The DOTS client establishes one
or more sessions by connecting to the provided DOTS server 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
attack mitigation, and periodically informs the DOTS client about the attack mitigation, and periodically informs the DOTS client about the
status of the mitigation. Similarly, the DOTS client periodically status of the mitigation. Similarly, the DOTS client periodically
informs the DOTS server about the client's status, which at a minimum informs the DOTS server about the client's status, which at a minimum
provides client (attack target) health information, but it may also provides client (attack target) health information, but it should
include telemetry information about the attack as it is now seen by also include efficacy information about the attack mitigation as it
the client. At some point, the DOTS client may decide to terminate is now seen by the client. At some point, the DOTS client may decide
the server-side attack mitigation, which it indicates to the DOTS to terminate the server-side attack mitigation, which it indicates to
server over the signal channel. A mitigation may also be terminated the DOTS server over the signal channel. A mitigation may also be
if a DOTS client-specified mitigation lifetime is exceeded. Note terminated if a DOTS client-specified mitigation lifetime is
that the signal channel may need to operate over a link that is exceeded. Note that the signal channel may need to operate over a
experiencing a DDoS attack and hence is subject to severe packet loss link that is experiencing a DDoS attack and hence is subject to
and high latency. severe packet loss 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. The primary purpose of
required in the DOTS architecture. The primary purpose of the data 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,
using JSON to serialize the data: using JSON to serialize the data:
{ {
skipping to change at page 8, line 25 skipping to change at page 8, line 20
being exchanged during a DDoS attack. being exchanged during a DDoS attack.
2.1. DOTS Operations 2.1. DOTS Operations
DOTS does not prescribe any specific deployment models, however DOTS DOTS does not prescribe any specific deployment models, however DOTS
is designed with some specific requirements around the different DOTS is designed with some specific requirements around the different DOTS
agents and their relationships. agents and their relationships.
First of all, a DOTS agent belongs to a domain that has an identity First of all, a DOTS agent belongs to a domain that has an identity
which can be authenticated and authorized. DOTS agents communicate which can be authenticated and authorized. DOTS agents communicate
with each other over a mutually authenticated signal channel and data with each other over a mutually authenticated signal channel and
channel. However, before they can do so, a service relationship (optionally) data channel. However, before they can do so, a service
needs to be established between them. The details and means by which relationship needs to be established between them. The details and
this is done is outside the scope of DOTS, however an example would means by which this is done is outside the scope of DOTS, however an
be for an enterprise A (DOTS client) to sign up for DDoS service from example would be for an enterprise A (DOTS client) to sign up for
provider B (DOTS server). This would establish a (service) DDoS service from provider B (DOTS server). This would establish a
relationship between the two that enables enterprise A's DOTS client (service) relationship between the two that enables enterprise A's
to establish a signal channel with provider B's DOTS server. A and B DOTS client to establish a signal channel with provider B's DOTS
will authenticate each other, and B can verify that A is authorized server. A and B will authenticate each other, and B can verify that
for its service. A is authorized 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.
skipping to change at page 9, line 52 skipping to change at page 9, line 48
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 administrator. Such mitigation feedback (e.g. mitigation efficacy) at the direction of
direction may involve manual or automated adjustments in response to its local administrator. Such direction may involve manual or
feedback from the DOTS server. automated adjustments in response to updates from the DOTS server.
To provide a metric of signal health and distinguish an idle signal To provide a metric of signal health and distinguish an idle signal
channel from a disconnected or defunct session, the DOTS client sends channel from a disconnected or defunct session, the DOTS client sends
a heartbeat over the signal channel to maintain its half of the a heartbeat over the signal channel to maintain its half of the
channel. The DOTS client similarly expects a heartbeat from the DOTS channel. The DOTS client similarly expects a heartbeat from the DOTS
server, and may consider a session terminated in the extended absence server, and may consider a session 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 from DOTS clients. The DOTS server authenticates and authorizes DOTS
clients as described in Section 3.1, and maintains session state, clients as described in Section 3.1, and maintains session state,
tracking requests for mitigation, reporting on the status of active tracking requests for mitigation, reporting on the status of active
mitigations, and terminating sessions in the extended absence of a mitigations, and terminating sessions in the 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 session with a DOTS server may reasonably maintaining an active session with a DOTS server may reasonably
expect some level of mitigation in response to a request for expect some level of mitigation in response to a request for
coordinated attack response. coordinated attack response.
skipping to change at page 11, line 22 skipping to change at page 11, line 19
send a heartbeat over the signal channel to maintain its half of the send a heartbeat over the signal channel to maintain its half of the
channel. The DOTS server similarly expects a heartbeat from the DOTS channel. The DOTS server similarly expects a heartbeat from the DOTS
client, and MAY consider a session terminated in the extended absence client, and MAY consider a session 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 Session Initiation Protocol (SIP)
User Agent (B2BUA) [RFC7092]. The term DOTS gateway is used here in [RFC3261] logical entity of a Back-to-Back User Agent (B2BUA)
the descriptions of selected scenarios involving this application. [RFC7092]. The term DOTS gateway is used here in the descriptions of
selected scenarios involving this application.
A DOTS gateway may be deployed client-side, server-side or both. The 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 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:
+-------------+ +-------------+
skipping to change at page 13, line 30 skipping to change at page 13, line 30
Figure 6: Multi-Homed DOTS Client Figure 6: Multi-Homed DOTS Client
Deploying a multi-homed client requires extra care and planning, as Deploying a multi-homed client requires extra care and planning, as
the DOTS servers with which the multi-homed client communicates may the DOTS servers with which the multi-homed client communicates may
not be affiliated. Should the multi-homed client simultaneously not be affiliated. Should the multi-homed client simultaneously
request for mitigation from all servers with which it has established request for mitigation from all servers with which it has established
signal channels, the client may unintentionally inflict additional signal channels, the client may unintentionally inflict additional
network disruption on the resources it intends to protect. In one of network disruption on the resources it intends to protect. In one of
the worst cases, a multi-homed DOTS client could cause a permanent the worst cases, a multi-homed DOTS client could cause a permanent
routing loop of traffic destined for the client's protected protected routing loop of traffic destined for the client's protected services,
services, as the uncoordinated DOTS servers' mitigators all try to as the uncoordinated DOTS servers' mitigators all try to divert that
divert that traffic to their own scrubbing centers. traffic to their own scrubbing centers.
The DOTS protocol itself provides no fool-proof method to prevent The DOTS protocol itself provides no fool-proof method to prevent
such self-inflicted harms as a result deploying multi-homed DOTS such self-inflicted harms as a result deploying multi-homed DOTS
clients. If DOTS client implementations nevertheless include support clients. If DOTS client implementations nevertheless include support
for multi-homing, they are expected to be aware of the risks, and for multi-homing, they are expected to be aware of the risks, and
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;
skipping to change at page 16, line 17 skipping to change at page 16, line 17
3.1. DOTS 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.
A DOTS session is established, bilateral exchange of data between an A DOTS session is established to support bilateral exchange of data
associated DOTS client and a DOTS server. In the DOTS architecture, between an associated DOTS client and a DOTS server. In the DOTS
data is exchanged between DOTS agents over signal and data channels. architecture, data is exchanged between DOTS agents over signal and
Regardless, a DOTS session is characterized by the presence of an data channels. Regardless, a DOTS session is characterized by the
established signal channel. A data channel associated with a signal presence of an established signal channel. A data channel may be
channel may be thought of as part of the DOTS session, but the established as well, however it is not a prerequisite. Conversely, a
termination of that data channel does not terminate the DOTS session. DOTS session cannot exist without an established signal channel: when
Conversely, a DOTS session cannot exist without an established signal an established signal channel is terminated for any reason, the DOTS
channel: when an established signal channel is terminated for any session is also said to be terminated.
reason, the DOTS session is also said to be terminated.
3.1.1. Preconditions 3.1.1. Preconditions
Prior to establishing a DOTS session between agents, the owners of Prior to establishing a DOTS session between agents, the owners of
the networks, domains, services or applications involved are assumed the networks, domains, services or applications involved are assumed
to have agreed upon the terms of the relationship involved. Such to have agreed upon the terms of the relationship involved. Such
agreements are out of scope for this document, but must be in place agreements are out of scope for this document, but must be in 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
skipping to change at page 16, line 49 skipping to change at page 16, line 48
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 DOTS 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 (possibly) the data channel. To allow for DOTS
flexibility, neither the order of contact nor the time interval service flexibility, neither the order of contact nor the time
between channel creations is specified. A DOTS client MAY establish interval between channel creations is specified. A DOTS client MAY
signal channel first, and then data channel, or vice versa. establish 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 IP address and port, and directly to use a specific DOTS server IP address and port, and directly
provided with any data necessary to satisfy the Peer Mutual provided with any data necessary to satisfy the Peer Mutual
Authentication requirement in [I-D.ietf-dots-requirements], such as Authentication requirement in [I-D.ietf-dots-requirements], such as
symmetric or asymmetric keys, usernames and passwords, etc. All symmetric or asymmetric keys, usernames and passwords, etc. All
configuration and authentication information in this scenario is configuration and authentication information in this scenario is
provided out-of-band by the domain operating the DOTS server. provided out-of-band by the domain operating the DOTS server.
skipping to change at page 17, line 25 skipping to change at page 17, line 25
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].
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 (if used) data
soon as possible to confirm that both channels are operational. channel as 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 DOTS session. lifetime, and heartbeat intervals when establishing the DOTS session.
A DOTS session is not active until DOTS agents have agreed on the A DOTS session is not active until DOTS agents have agreed on the
values for these DOTS session parameters, a process defined by the values for these DOTS session parameters, a process defined by the
protocol. protocol.
Once the DOTS client begins receiving DOTS server signals, the DOTS Once the DOTS client begins receiving DOTS server signals, the DOTS
session is active. At any time during the DOTS session, the DOTS session is active. At any time during the DOTS session, the DOTS
client may use the data channel to adjust initial configuration, client may use the data channel to manage aliases, manage black- and
manage black- and white-listed prefixes or addresses, leverage white-listed prefixes or addresses, leverage vendor-specific
vendor-specific extensions, and so on. Note that unlike the signal extensions, and so on. Note that unlike the signal channel, there is
channel, there is no requirement that the data channel remain no requirement that the data channel remains operational in attack
operational in attack conditions (See Data Channel Requirements, conditions (See Data Channel Requirements,
[I-D.ietf-dots-requirements]). [I-D.ietf-dots-requirements]).
3.1.3. Maintaining the DOTS 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.
skipping to change at page 18, line 25 skipping to change at page 18, line 25
A DOTS session may take the form of direct signaling between the DOTS A DOTS session may take the form of direct signaling between the 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 DOTS session, DOTS client and server are communicating In a direct DOTS session, the DOTS client and server are
directly. Direct signaling may exist inter- or intra-domain. The communicating directly. Direct signaling may exist inter- or intra-
DOTS session is abstracted from the underlying networks or network domain. The DOTS session is abstracted from the underlying networks
elements the signals traverse: in direct signaling, the DOTS client or network elements the signals traverse: in direct signaling, the
and server are logically adjacent. DOTS client and server are logically 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 DOTS 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 DOTS sessions with clients has been reached; o Maximum number of DOTS sessions with clients has been reached;
o Mitigation capacity exhaustion in the mitigator with which the o Mitigation capacity exhaustion in the mitigator with which the
skipping to change at page 20, line 9 skipping to change at page 20, line 9
mitigation on a mitigator with which the server has an established mitigation on a mitigator with which the server has an established
service relationship. The operator of the mitigator may in turn service relationship. The operator of the mitigator may in turn
monitor mitigation performance and capacity, as the attack being monitor mitigation performance and capacity, as the attack being
mitigated may grow in severity beyond the mitigating domain's mitigated may grow in severity beyond the mitigating domain's
capabilities. capabilities.
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 only encourages attack
attack escalation. In the case where the mitigating domain is the escalation. In the case where the mitigating domain is the upstream
upstream service provider for the attack target, this may mean the service provider for the attack target, this may mean the mitigating
mitigating domain and its other services and users continue to suffer domain and its other services and users continue to suffer the
the incidental effects of the attack. 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 "End-customer with a
upstream transit provider DDoS mitigation service" described in single upstream transit provider offering DDoS mitigation services"
[I-D.ietf-dots-use-cases], a domain operating a DOTS server and described in [I-D.ietf-dots-use-cases], a domain operating a DOTS
mitigator also operates a DOTS client. This DOTS client has an server and mitigator also operates a DOTS client. This DOTS client
established DOTS session with a DOTS server belonging to a separate has an established DOTS session with a DOTS server belonging to a
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
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
skipping to change at page 24, line 11 skipping to change at page 24, line 11
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.
However, considering selected possible mitigation triggers from an However, considering selected possible mitigation triggers from an
architectural perspective offers a model for alternative or architectural perspective offers a model for alternative or
unanticipated triggers for DOTS deployments. In all cases, what unanticipated triggers for DOTS deployments. In all cases, what
network conditions merit a mitigation request are at the discretion network conditions merit a mitigation request are at the discretion
of the DOTS client operator. of the DOTS client operator.
The interfaces required to trigger the mitigation request in the The mitigation request itself is defined by DOTS, however the
interfaces required to trigger the mitigation request in the
following scenarios are implementation-specific. following scenarios are implementation-specific.
3.3.1. Manual Mitigation Request 3.3.1. Manual Mitigation Request
A DOTS client operator may manually prepare a request for mitigation, A DOTS client operator may manually prepare a request for mitigation,
including scope and duration, and manually instruct the DOTS client including scope and duration, and manually instruct the DOTS client
to send the mitigation request to the DOTS server. In context, a to send the mitigation request to the DOTS server. In context, a
manual request is a request directly issued by the operator without manual request is a request directly issued by the operator without
automated decision-making performed by a device interacting with the automated decision-making performed by a device interacting with the
DOTS client. Modes of manual mitigation requests include an operator DOTS client. Modes of manual mitigation requests include an operator
entering a command into a text interface, or directly interacting entering a command into a text interface, or directly interacting
with a graphical interface to send the request. with a graphical interface to send the request.
An operator might do this, for example, in response to notice of an An operator might do this, for example, in response to notice of an
attack delivered by attack detection equipment or software, and the attack delivered by attack detection equipment or software, and the
alerting detector lacks interfaces or is not configured to use alerting detector lacks interfaces or is not configured to use
available interfaces to translate the alert to a mitigation request available interfaces to translate the alert to a mitigation request
automatically. automatically.
In a variation of the above scenario, the operator may have In a variation of the above scenario, the operator may have
preconfigured on the DOTS client mitigation request for various preconfigured on the DOTS client mitigation requests for various
resources in the operator's domain. When notified of an attack, the resources in the operator's domain. When notified of an attack, the
DOTS client operator manually instructs the DOTS client to send the DOTS client operator manually instructs the DOTS client to send the
preconfigured mitigation request for the resources under attack. relevant preconfigured mitigation request for the resources under
attack.
A further variant involves recursive signaling, as described in A further variant involves recursive signaling, as described in
Section 3.2.3. The DOTS client in this case is the second half of a Section 3.2.3. The DOTS client in this case is the second half of a
DOTS gateway (back-to-back DOTS server and client). As in the DOTS gateway (back-to-back DOTS server and client). As in the
previous scenario, the scope and duration of the mitigation request previous scenario, the scope and duration of the mitigation request
are pre-existing, but in this case are derived from the mitigation are pre-existing, but in this case are derived from the mitigation
request received from a downstream DOTS client by the DOTS server. request received from a downstream DOTS client by the DOTS server.
Assuming the preconditions required by Section 3.2.3 are in place, Assuming the preconditions required by Section 3.2.3 are in place,
the DOTS gateway operator may at any time manually request mitigation the DOTS gateway operator may at any time manually request mitigation
from an upstream DOTS server, sending a mitigation request derived from an upstream DOTS server, sending a mitigation request derived
skipping to change at page 26, line 17 skipping to change at page 26, line 19
To maintain a DOTS 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 signal channel. exchange regular but infrequent messages across the signal channel.
In the absence of an attack, the probability of message loss in the In the absence of an attack, the probability of message loss in the
signaling channel should be extremely low. Under attack conditions, signaling channel should be extremely low. Under attack conditions,
however, some signal loss may be anticipated as attack traffic however, some signal loss may be anticipated as attack 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 operator may configure the
configure the DOTS session to trigger mitigation when the DOTS server DOTS session to trigger mitigation when the DOTS server ceases
ceases receiving DOTS client signals (or vice versa) beyond the miss receiving DOTS client signals (or vice versa) beyond the miss count
count or period permitted by the protocol. 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
This section describes identified security considerations for the This section describes identified security considerations for the
DOTS architecture. DOTS architecture.
DOTS is at risk from three primary attack vectors: agent DOTS is at risk from three primary attack vectors: agent
impersonation, traffic injection and signal blocking. These vectors impersonation, traffic injection and signal blocking. These vectors
may be exploited individually or in concert by an attacker to may be exploited individually or in concert by an attacker to
confuse, disable, take information from, or otherwise inhibit DOTS confuse, disable, take information from, or otherwise inhibit DOTS
agents. agents.
Any attacker with the ability to impersonate a legitimate client or Any attacker with the ability to impersonate a legitimate DOTS client
server or, indeed, inject false messages into the stream may or server or, indeed, inject false messages into the stream may
potentially trigger/withdraw traffic redirection, trigger/cancel potentially trigger/withdraw traffic redirection, trigger/cancel
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.
skipping to change at page 27, line 30 skipping to change at page 27, line 32
Mohamed Boucadair Mohamed Boucadair
Orange Orange
mohamed.boucadair@orange.com mohamed.boucadair@orange.com
6. Acknowledgments 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.
7. Change Log 7. References
2016-03-18 Initial revision
8. References
8.1. Normative References 7.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>. <https://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References 7.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-05 (work in Requirements", draft-ietf-dots-requirements-06 (work in
progress), June 2017. progress), July 2017.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Fouant, S., Migault, D., Moskowitz, R., Dobbins, R., Migault, D., Fouant, S., 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", draft-ietf-dots-use-cases-07 (work
draft-ietf-dots-use-cases-05 (work in progress), May 2017. in progress), July 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>. <https://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>. <https://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,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <https://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>. <https://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,
<https://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>. <https://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>. <https://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, <https://www.rfc-editor.org/info/rfc4786>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <https://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>. <https://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>. <https://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>. <https://www.rfc-editor.org/info/rfc7094>.
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. 50 change blocks. 
124 lines changed or deleted 128 lines changed or added

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