draft-ietf-dots-architecture-09.txt   draft-ietf-dots-architecture-10.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: June 1, 2019 Cisco Expires: June 7, 2019 Cisco
T. Reddy T. Reddy
McAfee, Inc. McAfee, Inc.
N. Teague N. Teague
Verisign Verisign
R. Compton R. Compton
Charter Charter
C. Gray C. Gray
November 28, 2018 December 04, 2018
Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture
draft-ietf-dots-architecture-09 draft-ietf-dots-architecture-10
Abstract Abstract
This document describes an architecture for establishing and This document describes an architecture for establishing and
maintaining Distributed Denial of Service (DDoS) Open Threat maintaining Distributed Denial of Service (DDoS) Open Threat
Signaling (DOTS) within and between domains. The document does not Signaling (DOTS) within and between domains. The document does not
specify protocols or protocol extensions, instead focusing on specify protocols or protocol extensions, instead focusing on
defining architectural relationships, components and concepts used in defining architectural relationships, components and concepts used in
a DOTS deployment. a DOTS deployment.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 https://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 June 1, 2019. This Internet-Draft will expire on June 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
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. DOTS Sessions . . . . . . . . . . . . . . . . . . . . . . 16 3.1. DOTS Sessions . . . . . . . . . . . . . . . . . . . . . . 16
3.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 16 3.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 16
3.1.2. Establishing the DOTS Session . . . . . . . . . . . . 16 3.1.2. Establishing the DOTS Session . . . . . . . . . . . . 17
3.1.3. Maintaining the DOTS Session . . . . . . . . . . . . 17 3.1.3. Maintaining the DOTS Session . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . 20
3.2.4. Anycast Signaling . . . . . . . . . . . . . . . . . . 22 3.2.4. Anycast Signaling . . . . . . . . . . . . . . . . . . 22
3.2.5. Signaling Considerations for Network Address 3.2.5. Signaling Considerations for Network Address
Translation . . . . . . . . . . . . . . . . . . . . . 23 Translation . . . . . . . . . . . . . . . . . . . . . 23
3.3. Triggering Requests for Mitigation . . . . . . . . . . . 26 3.3. Triggering Requests for Mitigation . . . . . . . . . . . 26
3.3.1. Manual Mitigation Request . . . . . . . . . . . . . . 26 3.3.1. Manual Mitigation Request . . . . . . . . . . . . . . 26
3.3.2. Automated Conditional Mitigation Request . . . . . . 27 3.3.2. Automated Conditional Mitigation Request . . . . . . 27
3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 28 3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 28
4. Security Considerations . . . . . . . . . . . . . . . . . . . 29 4. Security Considerations . . . . . . . . . . . . . . . . . . . 29
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
skipping to change at page 9, line 39 skipping to change at page 9, line 39
response to an active, ongoing attack against a target in the DOTS response to an active, ongoing attack against a target in the DOTS
client's domain, but no active attack is required for a DOTS client client's domain, but no active attack is required for a DOTS client
to request help. Operators may wish to have upstream mitigators in to request help. Operators may wish to have upstream mitigators in
the network path for an indefinite period, and are restricted only by the network path for an indefinite period, and are restricted only by
business relationships when it comes to duration and scope of business relationships when it comes to duration and scope of
requested mitigation. requested mitigation.
The DOTS client requests attack response coordination from a DOTS The DOTS client requests attack response coordination from a DOTS
server over the signal channel, including in the request the DOTS server over the signal channel, including in the request the DOTS
client's desired mitigation scoping, as described in client's desired mitigation scoping, as described in
[I-D.ietf-dots-requirements]. The actual mitigation scope and [I-D.ietf-dots-requirements] (SIG-008). The actual mitigation scope
countermeasures used in response to the attack are up to the DOTS and countermeasures used in response to the attack are up to the DOTS
server and mitigator operators, as the DOTS client may have a narrow 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
mitigation feedback (e.g., mitigation efficacy) at the direction of mitigation feedback (e.g., mitigation efficacy) at the direction of
its local administrator. Such direction may involve manual or its local administrator. Such direction may involve manual or
automated adjustments in response to updates from the DOTS server. automated adjustments in response to updates from the DOTS server.
skipping to change at page 16, line 20 skipping to change at page 16, line 20
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 to support bilateral exchange of data A DOTS session is established to support bilateral exchange of data
between an associated DOTS client and a DOTS server. In the DOTS between an associated DOTS client and a DOTS server. In the DOTS
architecture, data is exchanged between DOTS agents over signal and architecture, data is exchanged between DOTS agents over signal and
data channels. Regardless, a DOTS session is characterized by the data channels. As such, a DOTS session can be a DOTS signal channel
presence of an established signal channel. A data channel may be session, a DOTS data channel session, or both.
established as well, however it is not a prerequisite. Conversely, a
DOTS session cannot exist without an established signal channel: when A DOTS agent can maintain one or more DOTS sessions.
an established signal channel is terminated for any reason, the DOTS
session is also said to be terminated. A DOTS signal channel session is associated with a single transport
connection (TCP or UDP session) and an ephemeral security association
(a TLS or DTLS session). Similarly, a DOTS data channel session is
associated with a single TCP connection and an ephemeral TLS security
association.
Mitigation requests created using DOTS signal channel are not bound
to the DOTS signal channel session. Instead, mitigation requests are
associated with a DOTS client and can be managed using different DOTS
signal channel sessions.
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
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 (SEC-002) 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 DOTS session by contacting its DOTS server(s) over the
signal channel and (possibly) the data channel. To allow for DOTS signal channel and (possibly) the data channel. To allow for DOTS
service flexibility, neither the order of contact nor the time service flexibility, neither the order of contact nor the time
interval between channel creations is specified. A DOTS client MAY interval between channel creations is specified. A DOTS client MAY
establish 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 (SEC-001) in [I-D.ietf-dots-requirements],
symmetric or asymmetric keys, usernames and passwords, etc. All such as symmetric or asymmetric keys, usernames and passwords, etc.
configuration and authentication information in this scenario is All 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.
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 (if used) data messages with the DOTS server over both signal and (if used) data
channel as soon as possible to confirm that both channels are channel as soon as possible to confirm that both channels are
operational. operational.
As described in [I-D.ietf-dots-requirements], the DOTS client can As described in [I-D.ietf-dots-requirements] (DM-008), the DOTS
configure preferred values for acceptable signal loss, mitigation client can configure preferred values for acceptable signal loss,
lifetime, and heartbeat intervals when establishing the DOTS session. mitigation lifetime, and heartbeat intervals when establishing the
A DOTS session is not active until DOTS agents have agreed on the DOTS signal channel session. A DOTS signal channel session is not
values for these DOTS session parameters, a process defined by the active until DOTS agents have agreed on the values for these DOTS
protocol. session parameters, a process defined by the 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 manage aliases, manage drop- and client may use the data channel to manage aliases, manage drop- and
accept-listed prefixes or addresses, leverage vendor-specific accept-listed prefixes or addresses, leverage vendor-specific
extensions, and so on. Note that unlike the signal channel, there is extensions, and so on. Note that unlike the signal channel, there is
no requirement that the data channel remains operational in attack no requirement that the data channel remains operational in attack
conditions (See Data Channel Requirements, conditions (See Data Channel Requirements, Section 2.3 of
[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, discussed in [I-D.ietf-dots-requirements]
[I-D.ietf-dots-requirements]. DOTS agent operators SHOULD configure (SIG-004). DOTS agent operators SHOULD configure the heartbeat
the heartbeat interval such that the frequency does not lead to interval such that the frequency does not lead to accidental denials
accidental denials of service due to the overwhelming number of of service due to the overwhelming number of heartbeats a DOTS agent
heartbeats a DOTS agent must field. must field.
Either DOTS agent may consider a DOTS session terminated in the Either DOTS agent may consider a DOTS signal channel session
extended absence of a heartbeat from its peer agent. The period of terminated in the extended absence of a heartbeat from its peer
that absence will be established in the protocol definition. agent. The period of 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 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.
skipping to change at page 18, line 34 skipping to change at page 18, line 44
In a direct DOTS session, the DOTS client and server are In a direct DOTS session, the DOTS client and server are
communicating directly. Direct signaling may exist inter- or intra- communicating directly. Direct signaling may exist inter- or intra-
domain. The DOTS session is abstracted from the underlying networks domain. The DOTS session is abstracted from the underlying networks
or network elements the signals traverse: in direct signaling, the or network elements the signals traverse: in direct signaling, the
DOTS client 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 signal channel
circumstances include but are not limited to: session. Such circumstances include but are not limited to:
o Maximum number of DOTS sessions with clients has been reached; o Maximum number of DOTS signal channel 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
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 DOTS session resembles the following, as shown in A basic redirected DOTS signal channel session resembles the
Figure 12. following, as shown in Figure 12.
+-------------+ +---------------+ +-------------+ +---------------+
| |<-(1)--- DOTS session 1 --->| | | |<-(1)--- DOTS signal ------>| |
| | | | | | channel session 1 | |
| |<=(2)== redirect to B ======| | | |<=(2)== redirect to B ======| |
| DOTS client | | DOTS server A | | DOTS client | | DOTS server A |
| |X-(4)--- DOTS session 1 ---X| | | |X-(4)--- DOTS signal ------X| |
| | | | | | channel session 1 | |
| | | | | | | |
+-------------+ +---------------+ +-------------+ +---------------+
^ ^
| |
(3) DOTS session 2 (3) DOTS signal channel
| | session 2
v v
+---------------+ +---------------+
| DOTS server B | | DOTS server B |
+---------------+ +---------------+
Figure 12: Redirected Signaling Figure 12: Redirected Signaling
1. Previously established DOTS session 1 exists between a DOTS 1. Previously established DOTS signal channel session 1 exists
client and DOTS server A. between a DOTS 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 DOTS session 3. If the DOTS client does not already have a separate DOTS signal
with the redirection target, the DOTS client initiates and channel session with the redirection target, the DOTS client
establishes DOTS session 2 with DOTS server B. initiates and establishes DOTS signal channel 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. DOTS session 1 is terminated. signals to DOTS server A. DOTS signal channel 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 21, line 50 skipping to change at page 21, line 50
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 SIG-006
[I-D.ietf-dots-requirements]. in [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 SIG-006 of
requirements ([I-D.ietf-dots-requirements]). [I-D.ietf-dots-requirements].
Deployment of recursive signaling may result in traffic redirection, Deployment of recursive signaling may result in traffic redirection,
examination and mitigation extending beyond the initial bilateral examination and mitigation extending beyond the initial bilateral
relationship between DOTS client and DOTS server. As such, client relationship between DOTS client and DOTS server. As such, client
control over the network path of mitigated traffic may be reduced. control over the network path of mitigated traffic may be reduced.
DOTS client operators should be aware of any privacy concerns, and DOTS client operators should be aware of any privacy concerns, and
work with DOTS server operators employing recursive signaling to work with DOTS server operators employing recursive signaling to
ensure shared sensitive material is suitably protected. ensure shared sensitive material is suitably protected.
3.2.4. Anycast Signaling 3.2.4. Anycast Signaling
skipping to change at page 23, line 5 skipping to change at page 23, line 5
potential attack surface, as described in BCP 126 [RFC4786]. potential attack surface, as described in BCP 126 [RFC4786].
3.2.4.1. Anycast Signaling Considerations 3.2.4.1. Anycast Signaling Considerations
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 SIG-001
[I-D.ietf-dots-requirements], the signal channel also requires mutual in [I-D.ietf-dots-requirements], the signal channel also requires
authentication between DOTS agents, with associated security state on mutual authentication between DOTS agents, with associated security
both ends. state on both ends.
Network instability is of particular concern with anycast signaling, Network instability is of particular concern with anycast signaling,
as DOTS signal channels 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
skipping to change at page 28, line 35 skipping to change at page 28, line 35
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 DOTS session, the DOTS client and the DOTS server To maintain a DOTS signal channel session, the DOTS client and the
exchange regular but infrequent messages across the signal channel. DOTS server exchange regular but infrequent messages across the
In the absence of an attack, the probability of message loss in the signal channel. In the absence of an attack, the probability of
signaling channel should be extremely low. Under attack conditions, message loss in the signaling channel should be extremely low. Under
however, some signal loss may be anticipated as attack traffic attack conditions, however, some signal loss may be anticipated as
congests the link, depending on the attack type. attack traffic 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 operator may request one efforts. To handle such scenarios, a DOTS operator may request one
or more mitigations which are triggered only when the DOTS server or more mitigations which are triggered only when the DOTS server
ceases receiving DOTS client heartbeats beyond the miss count or ceases receiving DOTS client heartbeats beyond the miss count or
interval permitted by the protocol. interval 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
 End of changes. 28 change blocks. 
66 lines changed or deleted 79 lines changed or added

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