draft-ietf-dots-architecture-10.txt   draft-ietf-dots-architecture-11.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 7, 2019 Cisco Expires: August 11, 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
December 04, 2018 February 7, 2019
Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture
draft-ietf-dots-architecture-10 draft-ietf-dots-architecture-11
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 7, 2019. This Internet-Draft will expire on August 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
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 47 skipping to change at page 2, line 47
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 . . . . . . . . . . . . . . . . . 20 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
7.1. Normative References . . . . . . . . . . . . . . . . . . 30 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.2. Informative References . . . . . . . . . . . . . . . . . 30 8.1. Normative References . . . . . . . . . . . . . . . . . . 30
8.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Context and Motivation 1. Context and Motivation
Signaling the need for help defending against an active distributed Signaling the need for help defending against an active distributed
denial of service (DDoS) attack requires a common understanding of denial of service (DDoS) attack requires a common understanding of
mechanisms and roles among the parties coordinating defensive mechanisms and roles among the parties coordinating defensive
response. The signaling layer and supplementary messaging is the response. The signaling layer and supplementary messaging is the
focus of DDoS Open Threat Signaling (DOTS). DOTS defines a method of focus of DDoS Open Threat Signaling (DOTS). DOTS defines a method of
coordinating defensive measures among willing peers to mitigate coordinating defensive measures among willing peers to mitigate
attacks quickly and efficiently, enabling hybrid attack responses attacks quickly and efficiently, enabling hybrid attack responses
skipping to change at page 23, line 21 skipping to change at page 23, line 21
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
may not have the security state of the existing session, forcing the may not have the security state of the existing session, forcing the
DOTS client to initialize a new DOTS session. This challenge might DOTS client to initialize a new DOTS session. This challenge might
in part be mitigated by use of pre-shared keys and session resumption in part be mitigated by use of resumption via a PSK in TLS 1.3
[RFC5246][RFC6347], but keying material must be available to all DOTS [RFC8446] and DTLS 1.3 [I-D.ietf-tls-dtls13] (session resumption in
servers sharing the anycast Service Address in that case. TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347]), but keying material must
be available to all DOTS servers sharing the anycast Service Address
in that case.
While the DOTS client will try to establish a new DOTS session with While the DOTS client will try to establish a new DOTS session with
the DOTS server now acting as the anycast DOTS Service Address, the the DOTS server now acting as the anycast DOTS Service Address, the
link between DOTS client and server may be congested with attack link between DOTS client and server may be congested with attack
traffic, making signal session establishment difficult. In such a traffic, making signal session establishment difficult. In such a
scenario, anycast Service Address instability becomes a sort of scenario, anycast Service Address instability becomes a sort of
signal session flapping, with obvious negative consequences for the signal session flapping, with obvious negative consequences for the
DOTS deployment. DOTS deployment.
Anycast signaling deployments similarly must also take into account Anycast signaling deployments similarly must also take into account
skipping to change at page 24, line 25 skipping to change at page 24, line 27
directly provisioning the mappings of external addresses to internal directly provisioning the mappings of external addresses to internal
protected resources on the DOTS client. When the operator requests protected resources on the DOTS client. When the operator requests
mitigation scoped for internal addresses, directly or through mitigation scoped for internal addresses, directly or through
automated means, the DOTS client looks up the matching external automated means, the DOTS client looks up the matching external
addresses or prefixes, and issues a mitigation request scoped to that addresses or prefixes, and issues a mitigation request scoped to that
externally routable information. externally routable information.
When directly provisioning the address mappings, operators must When directly provisioning the address mappings, operators must
ensure the mappings remain up to date, or risk losing the ability to ensure the mappings remain up to date, or risk losing the ability to
request accurate mitigation scopes. To that aim, the DOTS client can request accurate mitigation scopes. To that aim, the DOTS client can
rely on mechanisms, such as [I-D.ietf-opsawg-nat-yang] to retrieve rely on mechanisms, such as [RFC8512] to retrieve static explicit
static explicit mappings. This document does not prescribe the mappings. This document does not prescribe the method by which
method by which mappings are maintained once they are provisioned on mappings are maintained once they are provisioned on the DOTS client.
the DOTS client.
3.2.5.2. Resolving Public Mitigation Scope with Port Control Protocol 3.2.5.2. Resolving Public Mitigation Scope with Port Control Protocol
(PCP) (PCP)
Port Control Protocol (PCP) [RFC6887] may be used to retrieve the Port Control Protocol (PCP) [RFC6887] may be used to retrieve the
external addresses/prefixes and/or port numbers if the NAT function external addresses/prefixes and/or port numbers if the NAT function
embeds a PCP server. embeds a PCP server.
A DOTS client can use the information retrieved by means of PCP to A DOTS client can use the information retrieved by means of PCP to
feed the DOTS protocol(s) messages that will be sent to a DOTS feed the DOTS protocol(s) messages that will be sent to a DOTS
skipping to change at page 29, line 9 skipping to change at page 29, line 9
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
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. IANA Considerations
This document has no actions for IANA.
5. 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.
skipping to change at page 29, line 45 skipping to change at page 30, line 5
client may negatively influence network traffic by requesting and client may negatively influence network traffic by requesting and
withdrawing requests for mitigation for particular prefixes, leading withdrawing requests for mitigation for particular prefixes, leading
to route or DNS flapping. to route or DNS flapping.
Any attack targeting the availability of DOTS servers may disrupt the Any attack targeting the availability of DOTS servers may disrupt the
ability of the system to receive and process DOTS signals resulting ability of the system to receive and process DOTS signals resulting
in failure to fulfill a mitigation request. DOTS agents SHOULD be in failure to fulfill a mitigation request. DOTS agents SHOULD be
given adequate protections, again in accordance with best current given adequate protections, again in accordance with best current
practices for network and host security. practices for network and host security.
5. Contributors 6. Contributors
Mohamed Boucadair Mohamed Boucadair
Orange Orange
mohamed.boucadair@orange.com mohamed.boucadair@orange.com
6. Acknowledgments 7. Acknowledgments
Thanks to Matt Richardson and Mohamed Boucadair for their comments Thanks to Matt Richardson, Roman Danyliw, Frank Xialiang, Roland
and suggestions. Dobbins, Wei Pan, Kaname Nishizuka, Jon Shallow and Mohamed Boucadair
for their comments and suggestions.
7. References 8. References
7.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 8.2. Informative References
[I-D.ietf-dots-requirements] [I-D.ietf-dots-requirements]
Mortensen, A., Moskowitz, R., and R. K, "Distributed Mortensen, A., K, R., and R. Moskowitz, "Distributed
Denial of Service (DDoS) Open Threat Signaling Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-16 (work in Requirements", draft-ietf-dots-requirements-18 (work in
progress), October 2018. progress), February 2019.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Fouant, S., 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", draft-ietf-dots-use-cases-16 (work Open Threat Signaling", draft-ietf-dots-use-cases-17 (work
in progress), July 2018. in progress), January 2019.
[I-D.ietf-opsawg-nat-yang] [I-D.ietf-tls-dtls13]
Boucadair, M., Sivakumar, S., Jacquenet, C., Vinapamula, Rescorla, E., Tschofenig, H., and N. Modadugu, "The
S., and Q. Wu, "A YANG Module for Network Address Datagram Transport Layer Security (DTLS) Protocol Version
Translation (NAT) and Network Prefix Translation (NPT)", 1.3", draft-ietf-tls-dtls13-30 (work in progress),
draft-ietf-opsawg-nat-yang-17 (work in progress), November 2018.
September 2018.
[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,
<https://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,
<https://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
skipping to change at page 32, line 47 skipping to change at page 33, line 9
[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
Layer Security (DTLS) as Transport for Session Traversal Layer Security (DTLS) as Transport for Session Traversal
Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350,
August 2014, <https://www.rfc-editor.org/info/rfc7350>. August 2014, <https://www.rfc-editor.org/info/rfc7350>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C.,
Vinapamula, S., and Q. Wu, "A YANG Module for Network
Address Translation (NAT) and Network Prefix Translation
(NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019,
<https://www.rfc-editor.org/info/rfc8512>.
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: andrewmortensen@gmail.com EMail: andrewmortensen@gmail.com
Flemming Andreasen Flemming Andreasen
Cisco Cisco
 End of changes. 21 change blocks. 
39 lines changed or deleted 55 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/