draft-ietf-dots-architecture-01.txt   draft-ietf-dots-architecture-02.txt 
DOTS A. Mortensen DOTS A. Mortensen
Internet-Draft Arbor Networks, Inc. Internet-Draft Arbor Networks, Inc.
Intended status: Informational F. Andreasen Intended status: Informational F. Andreasen
Expires: May 4, 2017 T. Reddy Expires: November 2, 2017 T. Reddy
Cisco Systems, Inc. Cisco Systems, Inc.
C. Gray C. Gray
Comcast, Inc. Comcast, Inc.
R. Compton R. Compton
Charter Communications, Inc. Charter Communications, Inc.
N. Teague N. Teague
Verisign, Inc. Verisign, Inc.
October 31, 2016 May 01, 2017
Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture
draft-ietf-dots-architecture-01 draft-ietf-dots-architecture-02
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2017. This Internet-Draft will expire on November 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
1.1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Definition of Terms . . . . . . . . . . . . . . . . . 3 1.1.2. Definition of Terms . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. DOTS Operations . . . . . . . . . . . . . . . . . . . . . 8 2.1. DOTS Operations . . . . . . . . . . . . . . . . . . . . . 8
2.2. Components . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Components . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. DOTS Client . . . . . . . . . . . . . . . . . . . . . 9 2.2.1. DOTS Client . . . . . . . . . . . . . . . . . . . . . 9
2.2.2. DOTS Server . . . . . . . . . . . . . . . . . . . . . 10 2.2.2. DOTS Server . . . . . . . . . . . . . . . . . . . . . 10
2.2.3. DOTS Gateway . . . . . . . . . . . . . . . . . . . . 11 2.2.3. DOTS Gateway . . . . . . . . . . . . . . . . . . . . 11
2.3. DOTS Agent Relationships . . . . . . . . . . . . . . . . 12 2.3. DOTS Agent Relationships . . . . . . . . . . . . . . . . 11
2.3.1. Gatewayed signaling . . . . . . . . . . . . . . . . . 13 2.3.1. Gatewayed signaling . . . . . . . . . . . . . . . . . 13
3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Signaling Sessions . . . . . . . . . . . . . . . . . . . 15 3.1. Signaling Sessions . . . . . . . . . . . . . . . . . . . 15
3.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 16 3.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 16
3.1.2. Establishing the Signaling Session . . . . . . . . . 16 3.1.2. Establishing the Signaling Session . . . . . . . . . 16
3.1.3. Maintaining the Signaling Session . . . . . . . . . . 17 3.1.3. Maintaining the Signaling Session . . . . . . . . . . 17
3.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 17 3.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 17
3.2.1. Direct Signaling . . . . . . . . . . . . . . . . . . 17 3.2.1. Direct Signaling . . . . . . . . . . . . . . . . . . 17
3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 18 3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 18
3.2.3. Recursive Signaling . . . . . . . . . . . . . . . . . 19 3.2.3. Recursive Signaling . . . . . . . . . . . . . . . . . 19
3.2.4. Anycast Signaling . . . . . . . . . . . . . . . . . . 21 3.2.4. Anycast Signaling . . . . . . . . . . . . . . . . . . 21
3.3. Triggering Requests for Mitigation . . . . . . . . . . . 23 3.3. Triggering Requests for Mitigation . . . . . . . . . . . 23
3.3.1. Manual Mitigation Request . . . . . . . . . . . . . . 23 3.3.1. Manual Mitigation Request . . . . . . . . . . . . . . 23
3.3.2. Automated Conditional Mitigation Request . . . . . . 24 3.3.2. Automated Conditional Mitigation Request . . . . . . 24
3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 25 3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 25
4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 4. Security Considerations . . . . . . . . . . . . . . . . . . . 25
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 26 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Normative References . . . . . . . . . . . . . . . . . . 27 7.1. Normative References . . . . . . . . . . . . . . . . . . 26
7.2. Informative References . . . . . . . . . . . . . . . . . 27 7.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 3, line 35 skipping to change at page 3, line 35
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.1.2. Definition of Terms 1.1.2. Definition of Terms
This document uses the terms defined in [I-D.ietf-dots-requirements]. This document uses the terms defined in [I-D.ietf-dots-requirements].
1.2. Scope 1.2. Scope
In this architecture, DOTS clients and servers communicate using the In this architecture, DOTS clients and servers communicate using DOTS
DOTS signaling. As a result of signals from a DOTS client, the DOTS signaling. As a result of signals from a DOTS client, the DOTS
server may modify the forwarding path of traffic destined for the server may modify the forwarding path of traffic destined for the
attack target(s), for example by diverting traffic to a mitigator or attack target(s), for example by diverting traffic to a mitigator or
pool of mitigators, where policy may be applied to distinguish and pool of mitigators, where policy may be applied to distinguish and
discard attack traffic. Any such policy is deployment-specific. discard attack traffic. Any such policy is deployment-specific.
The DOTS architecture presented here is applicable across network The DOTS architecture presented here is applicable across network
administrative domains - for example, between an enterprise domain administrative domains - for example, between an enterprise domain
and the domain of a third-party attack mitigation service - as well and the domain of a third-party attack mitigation service - as well
as to a single administrative domain. DOTS is generally assumed to as to a single administrative domain. DOTS is generally assumed to
be most effective when aiding coordination of attack response between be most effective when aiding coordination of attack response between
two or more participating network domains, but single domain two or more participating network domains, but single domain
scenarios are valuable in their own right, as when aggregating intra- scenarios are valuable in their own right, as when aggregating intra-
domain DOTS client signals for inter-domain coordinated attack domain DOTS client signals for inter-domain coordinated attack
response. response.
This document does not address any administrative or business This document does not address any administrative or business
agreements that may be established between involved DOTS parties. agreements that may be established between involved DOTS parties.
Those considerations are out of scope. Regardless, this document Those considerations are out of scope. Regardless, this document
assumes necessary authentication and authorization mechanism 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.
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.
skipping to change at page 6, line 29 skipping to change at page 6, line 29
+---------------+ +---------------+ +---------------+ +---------------+
Figure 2: DOTS Interfaces Figure 2: DOTS Interfaces
The DOTS client may be provided with a list of DOTS servers, each The DOTS client may be provided with a list of DOTS servers, each
associated with one or more IP addresses. These addresses may or may associated with one or more IP addresses. These addresses may or may
not be of the same address family. The DOTS client establishes one not be of the same address family. The DOTS client establishes one
or more signaling sessions by connecting to the provided DOTS server or more signaling sessions by connecting to the provided DOTS server
addresses. addresses.
[[EDITOR'S NOTE: We request feedback from the working group about the
mechanism of server discovery.]]
The primary purpose of the signal channel is for a DOTS client to ask The primary purpose of the signal channel is for a DOTS client to ask
a DOTS server for help in mitigating an attack, and for the DOTS a DOTS server for help in mitigating an attack, and for the DOTS
server to inform the DOTS client about the status of such mitigation. server to inform the DOTS client about the status of such mitigation.
The DOTS client does this by sending a client signal, which contains The DOTS client does this by sending a client signal, which contains
information about the attack target or targets. The client signal information about the attack target or targets. The client signal
may also include telemetry information about the attack, if the DOTS may also include telemetry information about the attack, if the DOTS
client has such information available. The DOTS server in turn sends client has such information available. The DOTS server in turn sends
a server signal to inform the DOTS client of whether it will honor a server signal to inform the DOTS client of whether it will honor
the mitigation request. Assuming it will, the DOTS server initiates the mitigation request. Assuming it will, the DOTS server initiates
attack mitigation (by means outside of DOTS), and periodically attack mitigation (by means outside of DOTS), and periodically
skipping to change at page 7, line 49 skipping to change at page 7, line 47
DOTS server about sources from which traffic should always be DOTS server about sources from which traffic should always be
accepted. accepted.
o Filter management, which enables a DOTS client to install or o Filter management, which enables a DOTS client to install or
remove traffic filters dropping or rate-limiting unwanted traffic. remove traffic filters dropping or rate-limiting unwanted traffic.
o DOTS client provisioning. o DOTS client provisioning.
Note that while it is possible to exchange the above information Note that while it is possible to exchange the above information
before, during or after a DDoS attack, DOTS requires reliable before, during or after a DDoS attack, DOTS requires reliable
delivery of the this information and does not provide any special delivery of this information and does not provide any special means
means for ensuring timely delivery of it during an attack. In for ensuring timely delivery of it during an attack. In practice,
practice, this means that DOTS deployments SHOULD NOT rely on such this means that DOTS deployments SHOULD NOT rely on such information
information being exchanged during a DDoS attack. being exchanged during a DDoS attack.
2.1. DOTS Operations 2.1. DOTS Operations
The scope of DOTS is focused on the signaling and data exchange The scope of DOTS is focused on the signaling and data exchange
between the DOTS client and DOTS server. DOTS does not prescribe any between the DOTS client and DOTS server. DOTS does not prescribe any
specific deployment models, however DOTS is designed with some specific deployment models, however DOTS is designed with some
specific requirements around the different DOTS agents and their specific requirements around the different DOTS agents and their
relationships. relationships.
First of all, a DOTS agent belongs to an domain, and that domain has First of all, a DOTS agent belongs to an domain, and that domain has
skipping to change at page 19, line 20 skipping to change at page 19, line 20
3. If the DOTS client does not already have a separate signaling 3. If the DOTS client does not already have a separate signaling
session with the redirection target, the DOTS client initiates session with the redirection target, the DOTS client initiates
and establishes a signaling session with DOTS server B as and establishes a signaling session with DOTS server B as
described above. described above.
4. Having redirected the DOTS client, DOTS server A ceases sending 4. Having redirected the DOTS client, DOTS server A ceases sending
server signals. The DOTS client likewise stops sending client server signals. The DOTS client likewise stops sending client
signals to DOTS server A. Signal session 1 is terminated. signals to DOTS server A. Signal session 1 is terminated.
[[EDITOR'S NOTE: we request working group feedback and discussion of
the need for redirected signaling.]]
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
mitigation on a mitigator with which the server has an established mitigation on a mitigator with which the server has an established
skipping to change at page 23, line 7 skipping to change at page 23, line 5
Anycast signaling deployments similarly must also take into account Anycast signaling deployments similarly must also take into account
active mitigations. Active mitigations initiated through a signaling active mitigations. Active mitigations initiated through a signaling
session may involve diverting traffic to a scrubbing center. If the session may involve diverting traffic to a scrubbing center. If the
signaling session flaps due to anycast changes as described above, signaling session flaps due to anycast changes as described above,
mitigation may also flap as the DOTS servers sharing the anycast DOTS mitigation may also flap as the DOTS servers sharing the anycast DOTS
service address toggles mitigation on detecting signaling session service address toggles mitigation on detecting signaling session
loss, depending on whether the client has configured mitigation on loss, depending on whether the client has configured mitigation on
loss of signal. loss of signal.
[[EDITOR'S NOTE: We request feedback from the working group regarding
the complexities inherent in an anycast DOTS deployment. Outside of
using anycast for service discovery, significant challenges need to
be overcome, particularly when dealing with security and mitigation
state, and the resulting operational complexity may outweigh the
expected benefits.]]
3.3. Triggering Requests for Mitigation 3.3. Triggering Requests for Mitigation
[I-D.ietf-dots-requirements] places no limitation on the [I-D.ietf-dots-requirements] places no limitation on the
circumstances in which a DOTS client operator may request mitigation, circumstances in which a DOTS client operator may request mitigation,
nor does it demand justification for any mitigation request, thereby nor does it demand justification for any mitigation request, thereby
reserving operational control over DDoS defense for the domain reserving operational control over DDoS defense for the domain
requesting mitigation. This architecture likewise does not prescribe requesting mitigation. This architecture likewise does not prescribe
the network conditions and mechanisms triggering a mitigation request the network conditions and mechanisms triggering a mitigation request
from a DOTS client. from a DOTS client.
skipping to change at page 27, line 19 skipping to change at page 27, line 8
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
7.2. Informative References 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-02 (work in Requirements", draft-ietf-dots-requirements-04 (work in
progress), July 2016. progress), March 2017.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Fouant, S., Migault, D., Moskowitz, R., Dobbins, R., Fouant, S., Migault, D., Moskowitz, R.,
Teague, N., and L. Xia, "Use cases for DDoS Open Threat Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
Signaling", draft-ietf-dots-use-cases-01 (work in Open Threat Signaling", draft-ietf-dots-use-cases-04 (work
progress), March 2016. in progress), March 2017.
[I-D.ietf-dprive-dnsodtls] [I-D.ietf-dprive-dnsodtls]
Reddy, T., Wing, D., and P. Patil, "Specification for DNS Reddy, T., Wing, D., and P. Patil, "Specification for DNS
over Datagram Transport Layer Security (DTLS)", draft- over Datagram Transport Layer Security (DTLS)", draft-
ietf-dprive-dnsodtls-12 (work in progress), September ietf-dprive-dnsodtls-15 (work in progress), December 2016.
2016.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-18 (work in progress), Version 1.3", draft-ietf-tls-tls13-20 (work in progress),
October 2016. April 2017.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>. <http://www.rfc-editor.org/info/rfc768>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>. <http://www.rfc-editor.org/info/rfc793>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
 End of changes. 18 change blocks. 
39 lines changed or deleted 25 lines changed or added

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