draft-ietf-dots-architecture-08.txt   draft-ietf-dots-architecture-09.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: May 31, 2019 Cisco Expires: June 1, 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 27, 2018 November 28, 2018
Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture
draft-ietf-dots-architecture-08 draft-ietf-dots-architecture-09
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 May 31, 2019. This Internet-Draft will expire on June 1, 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 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. DOTS Architecture . . . . . . . . . . . . . . . . . . . . . . 5 2. DOTS Architecture . . . . . . . . . . . . . . . . . . . . . . 5
2.1. DOTS Operations . . . . . . . . . . . . . . . . . . . . . 8 2.1. DOTS Operations . . . . . . . . . . . . . . . . . . . . . 8
2.2. Components . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Components . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. DOTS Client . . . . . . . . . . . . . . . . . . . . . 9 2.2.1. DOTS Client . . . . . . . . . . . . . . . . . . . . . 9
2.2.2. DOTS Server . . . . . . . . . . . . . . . . . . . . . 10 2.2.2. DOTS Server . . . . . . . . . . . . . . . . . . . . . 10
2.2.3. DOTS Gateway . . . . . . . . . . . . . . . . . . . . 11 2.2.3. DOTS Gateway . . . . . . . . . . . . . . . . . . . . 11
2.3. DOTS Agent Relationships . . . . . . . . . . . . . . . . 11 2.3. DOTS Agent Relationships . . . . . . . . . . . . . . . . 12
2.3.1. Gatewayed Signaling . . . . . . . . . . . . . . . . . 13 2.3.1. Gatewayed Signaling . . . . . . . . . . . . . . . . . 14
3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. DOTS Sessions . . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . 16
3.1.3. Maintaining the DOTS Session . . . . . . . . . . . . 17 3.1.3. Maintaining the DOTS Session . . . . . . . . . . . . 17
3.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 18 3.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 18
3.2.1. Direct Signaling . . . . . . . . . . . . . . . . . . 18 3.2.1. Direct Signaling . . . . . . . . . . . . . . . . . . 18
3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 18 3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 18
3.2.3. Recursive Signaling . . . . . . . . . . . . . . . . . 19 3.2.3. Recursive Signaling . . . . . . . . . . . . . . . . . 19
3.2.4. Anycast Signaling . . . . . . . . . . . . . . . . . . 22 3.2.4. Anycast Signaling . . . . . . . . . . . . . . . . . . 22
3.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 . . . . . . . . . . . . . . . . . . . . . . . 29 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1. Normative References . . . . . . . . . . . . . . . . . . 30 7.1. Normative References . . . . . . . . . . . . . . . . . . 30
7.2. Informative References . . . . . . . . . . . . . . . . . 30 7.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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
skipping to change at page 3, line 30 skipping to change at page 3, line 30
This document describes an architecture used in establishing, This document describes an architecture used in establishing,
maintaining or terminating a DOTS relationship within a domain or maintaining or terminating a DOTS relationship within a domain or
between domains. between domains.
1.1. Terminology 1.1. Terminology
1.1.1. Key Words 1.1.1. Key Words
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 BCP14 [RFC2119]
[RFC8174], when, and only when, they appear in all capitals.
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 DOTS In this architecture, DOTS clients and servers communicate using 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
skipping to change at page 7, line 38 skipping to change at page 7, line 41
], ],
"proxies": [ "proxies": [
"203.0.113.3:3128", "203.0.113.3:3128",
"[2001:db8:ac10::1]:3128" "[2001:db8:ac10::1]:3128"
], ],
"api_urls": "https://apiserver.example.com/api/v1", "api_urls": "https://apiserver.example.com/api/v1",
} }
Figure 3: Protected resource identifiers Figure 3: Protected resource identifiers
o Black-list management, which enables a DOTS client to inform the o Drop-list management, which enables a DOTS client to inform the
DOTS server about sources to suppress. DOTS server about sources to suppress.
o White-list management, which enables a DOTS client to inform the o Accept-list management, which enables a DOTS client to inform the
DOTS server about sources from which traffic is always accepted. DOTS server about sources from which traffic is always 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 this information and does not provide any special means delivery of this information and does not provide any special means
skipping to change at page 17, line 30 skipping to change at page 17, line 38
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 manage aliases, manage black- and client may use the data channel to manage aliases, manage drop- and
white-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,
[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
skipping to change at page 25, line 23 skipping to change at page 25, line 23
to the DOTS client, thereby enabling the DOTS client to request to the DOTS client, thereby enabling the DOTS client to request
mitigation with the correct external scope, as depicted in Figure 14. mitigation with the correct external scope, as depicted in Figure 14.
The mechanism for providing the DOTS client with the reflexive The mechanism for providing the DOTS client with the reflexive
transport address and internal transport address is unspecified in transport address and internal transport address is unspecified in
this document. this document.
In order to prevent an attacker from modifying the STUN messages in In order to prevent an attacker from modifying the STUN messages in
transit, the STUN client and server MUST use the message-integrity transit, the STUN client and server MUST use the message-integrity
mechanism discussed in Section 10 of [RFC5389] or use STUN over DTLS mechanism discussed in Section 10 of [RFC5389] or use STUN over DTLS
[RFC7350] or use STUN over TLS. If the STUN client is behind a NAT [RFC7350] or use STUN over TLS. If the STUN client is behind a NAT
that performs Endpoint-Dependent Mapping, the internal service cannot that performs Endpoint-Dependent Mapping [RFC5128], the internal
provide the DOTS client with the reflexive transport address service cannot provide the DOTS client with the reflexive transport
discovered using STUN. The behavior of a NAT between the STUN client address discovered using STUN. The behavior of a NAT between the
and the STUN server could be discovered using the techniques STUN client and the STUN server could be discovered using the
discussed in [RFC5780]. experimental techniques discussed in [RFC5780], but note that there
is currently no standardized way for a STUN client to reliably
determine if it is behind a NAT that performs Endpoint-Dependent
Mapping.
Binding Binding Binding Binding
+--------+ request +---+ request +--------+ +--------+ request +---+ request +--------+
| STUN |<----------| N |<----------| STUN | | STUN |<----------| N |<----------| STUN |
| server | | A | | client | | server | | A | | client |
| |---------->| T |---------->| | | |---------->| T |---------->| |
+--------+ Binding +---+ Binding +--------+ +--------+ Binding +---+ Binding +--------+
response response | response response |
| reflexive transport address | reflexive transport address
| & internal transport address | & internal transport address
skipping to change at page 29, line 19 skipping to change at page 29, line 23
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 DOTS client Any attacker with the ability to impersonate a legitimate DOTS client
or 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 drop-/accept-lists. From an
architectural standpoint, operators SHOULD ensure best current architectural standpoint, operators SHOULD ensure best current
practices for secure communication are observed for data and signal practices for secure communication are observed for data and signal
channel confidentiality, integrity and authenticity. Care must be channel confidentiality, integrity and authenticity. Care must be
taken to ensure transmission is protected by appropriately secure taken to ensure transmission is protected by appropriately secure
means, reducing attack surface by exposing only the minimal required means, reducing attack surface by exposing only the minimal required
services or interfaces. Similarly, received data at rest SHOULD be services or interfaces. Similarly, received data at rest SHOULD be
stored with a satisfactory degree of security. stored with a satisfactory degree of security.
As many mitigation systems employ diversion to scrub attack traffic, As many mitigation systems employ diversion to scrub attack traffic,
operators of DOTS agents SHOULD ensure DOTS sessions are resistant to operators of DOTS agents SHOULD ensure DOTS sessions are resistant to
skipping to change at page 29, line 50 skipping to change at page 30, line 7
5. Contributors 5. Contributors
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 Mohamed Boucadair for their comments
suggestions. and suggestions.
7. References 7. References
7.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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-dots-requirements] [I-D.ietf-dots-requirements]
Mortensen, A., Moskowitz, R., and R. K, "Distributed Mortensen, A., Moskowitz, R., and R. K, "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-16 (work in
progress), October 2018. progress), October 2018.
[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.,
skipping to change at page 31, line 35 skipping to change at page 31, line 44
[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,
<https://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, <https://www.rfc-editor.org/info/rfc4786>. December 2006, <https://www.rfc-editor.org/info/rfc4786>.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Peer (P2P) Communication across Network Address
Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March
2008, <https://www.rfc-editor.org/info/rfc5128>.
[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,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/info/rfc5389>. <https://www.rfc-editor.org/info/rfc5389>.
skipping to change at page 32, line 34 skipping to change at page 33, line 4
[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>.
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: andrewmortensen@gmail.com
Flemming Andreasen Flemming Andreasen
Cisco Cisco
United States United States
EMail: fandreas@cisco.com EMail: fandreas@cisco.com
Tirumaleswar Reddy Tirumaleswar Reddy
McAfee, Inc. McAfee, Inc.
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore, Karnataka 560071 Bangalore, Karnataka 560071
India India
EMail: kondtir@gmail.com EMail: kondtir@gmail.com
Nik Teague Nik Teague
Verisign Verisign
 End of changes. 18 change blocks. 
24 lines changed or deleted 37 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/