< draft-ietf-dots-data-channel-29.txt   draft-ietf-dots-data-channel-30.txt >
DOTS M. Boucadair, Ed. DOTS M. Boucadair, Ed.
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track T. Reddy, Ed. Intended status: Standards Track T. Reddy, Ed.
Expires: November 10, 2019 McAfee Expires: January 4, 2020 McAfee
May 09, 2019 July 03, 2019
Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel
Specification Specification
draft-ietf-dots-data-channel-29 draft-ietf-dots-data-channel-30
Abstract Abstract
The document specifies a Distributed Denial-of-Service Open Threat The document specifies a Distributed Denial-of-Service Open Threat
Signaling (DOTS) data channel used for bulk exchange of data that Signaling (DOTS) data channel used for bulk exchange of data that
cannot easily or appropriately communicated through the DOTS signal cannot easily or appropriately communicated through the DOTS signal
channel under attack conditions. channel under attack conditions.
This is a companion document to the DOTS signal channel This is a companion document to the DOTS signal channel
specification. specification.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 November 10, 2019. This Internet-Draft will expire on January 4, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 3, line 10 skipping to change at page 3, line 10
7.3. Retrieve Installed Filtering Rules . . . . . . . . . . . 52 7.3. Retrieve Installed Filtering Rules . . . . . . . . . . . 52
7.4. Remove Filtering Rules . . . . . . . . . . . . . . . . . 59 7.4. Remove Filtering Rules . . . . . . . . . . . . . . . . . 59
8. Operational Considerations . . . . . . . . . . . . . . . . . 60 8. Operational Considerations . . . . . . . . . . . . . . . . . 60
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
10. Security Considerations . . . . . . . . . . . . . . . . . . . 61 10. Security Considerations . . . . . . . . . . . . . . . . . . . 61
11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 63 11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 63
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 64 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 64
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 65
14.1. Normative References . . . . . . . . . . . . . . . . . . 65 14.1. Normative References . . . . . . . . . . . . . . . . . . 65
14.2. Informative References . . . . . . . . . . . . . . . . . 67 14.2. Informative References . . . . . . . . . . . . . . . . . 66
Appendix A. Sample Examples: Filtering Fragments . . . . . . . . 68 Appendix A. Sample Examples: Filtering Fragments . . . . . . . . 68
Appendix B. Sample Examples: Filtering TCP Messages . . . . . . 71 Appendix B. Sample Examples: Filtering TCP Messages . . . . . . 71
B.1. Discard TCP Null Attack . . . . . . . . . . . . . . . . . 71 B.1. Discard TCP Null Attack . . . . . . . . . . . . . . . . . 71
B.2. Rate-Limit SYN Flooding . . . . . . . . . . . . . . . . . 72 B.2. Rate-Limit SYN Flooding . . . . . . . . . . . . . . . . . 72
B.3. Rate-Limit ACK Flooding . . . . . . . . . . . . . . . . . 73 B.3. Rate-Limit ACK Flooding . . . . . . . . . . . . . . . . . 73
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74
1. Introduction 1. Introduction
A distributed denial-of-service (DDoS) attack is an attempt to make A distributed denial-of-service (DDoS) attack is an attempt to make
machines or network resources unavailable to their intended users. machines or network resources unavailable to their intended users.
In most cases, sufficient scale can be achieved by compromising In most cases, sufficient scale can be achieved by compromising
enough end-hosts and using those infected hosts to perpetrate and enough end-hosts and using those infected hosts to perpetrate and
amplify the attack. The victim of such attack can be an application amplify the attack. The victim of such attack can be an application
server, a router, a firewall, an entire network, etc. server, a router, a firewall, an entire network, etc.
As discussed in [I-D.ietf-dots-requirements], the lack of a common As discussed in [RFC8612], the lack of a common method to coordinate
method to coordinate a real-time response among involved actors and a real-time response among involved actors and network domains
network domains inhibits the speed and effectiveness of DDoS attack inhibits the speed and effectiveness of DDoS attack mitigation. From
mitigation. From that standpoint, DDoS Open Threat Signaling (DOTS) that standpoint, DDoS Open Threat Signaling (DOTS) defines an
defines an architecture that allows a DOTS client to send requests to architecture that allows a DOTS client to send requests to a DOTS
a DOTS server for DDoS attack mitigation server for DDoS attack mitigation [I-D.ietf-dots-architecture]. The
[I-D.ietf-dots-architecture]. The DOTS approach is thus meant to DOTS approach is thus meant to minimize the impact of DDoS attacks,
minimize the impact of DDoS attacks, thereby contributing to the thereby contributing to the enforcement of more efficient defensive
enforcement of more efficient defensive if not proactive security if not proactive security strategies. To that aim, DOTS defines two
strategies. To that aim, DOTS defines two channels: the signal and channels: the signal and the data channels (Figure 1).
the data channels (Figure 1).
+---------------+ +---------------+ +---------------+ +---------------+
| | <------- Signal Channel ------> | | | | <------- Signal Channel ------> | |
| DOTS Client | | DOTS Server | | DOTS Client | | DOTS Server |
| | <======= Data Channel ======> | | | | <======= Data Channel ======> | |
+---------------+ +---------------+ +---------------+ +---------------+
Figure 1: DOTS Channels Figure 1: DOTS Channels
The DOTS signal channel is used to carry information about a device The DOTS signal channel is used to carry information about a device
skipping to change at page 5, line 18 skipping to change at page 5, line 13
Refer to Section 7 for more details. Refer to Section 7 for more details.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119] [RFC8174] when, and only when, they appear in all capitals, [RFC2119] [RFC8174] when, and only when, they appear in all capitals,
as shown here. as shown here.
The reader should be familiar with the terms defined in The reader should be familiar with the terms defined in [RFC8612].
[I-D.ietf-dots-requirements].
The terminology for describing YANG modules is defined in [RFC7950]. The terminology for describing YANG modules is defined in [RFC7950].
The meaning of the symbols in the tree diagrams is defined in The meaning of the symbols in the tree diagrams is defined in
[RFC8340]. [RFC8340].
This document generalizes the notion of Access Control List (ACL) so This document generalizes the notion of Access Control List (ACL) so
that it is not device-specific [RFC8519]. As such, this document that it is not device-specific [RFC8519]. As such, this document
defines an ACL as an ordered set of rules that is used to filter defines an ACL as an ordered set of rules that is used to filter
traffic. Each rule is represented by an Access Control Entry (ACE). traffic. Each rule is represented by an Access Control Entry (ACE).
ACLs communicated via the DOTS data channel are not bound to a device ACLs communicated via the DOTS data channel are not bound to a device
skipping to change at page 5, line 49 skipping to change at page 5, line 43
and the leading whitespace of the next line. and the leading whitespace of the next line.
3. DOTS Data Channel 3. DOTS Data Channel
3.1. Design Overview 3.1. Design Overview
Unlike the DOTS signal channel, which must remain operational even Unlike the DOTS signal channel, which must remain operational even
when confronted with signal degradation due to packets loss, the DOTS when confronted with signal degradation due to packets loss, the DOTS
data channel is not expected to be fully operational at all times, data channel is not expected to be fully operational at all times,
especially when a DDoS attack is underway. The requirements for a especially when a DDoS attack is underway. The requirements for a
DOTS data channel protocol are documented in DOTS data channel protocol are documented in [RFC8612].
[I-D.ietf-dots-requirements].
This specification does not require an order of DOTS signal and data This specification does not require an order of DOTS signal and data
channel creations nor mandates a time interval between them. These channel creations nor mandates a time interval between them. These
considerations are implementation- and deployment-specific. considerations are implementation- and deployment-specific.
As the primary function of the data channel is data exchange, a As the primary function of the data channel is data exchange, a
reliable transport mode is required in order for DOTS agents to reliable transport mode is required in order for DOTS agents to
detect data delivery success or failure. This document uses RESTCONF detect data delivery success or failure. This document uses RESTCONF
[RFC8040] over TLS over TCP as the DOTS data channel protocol. The [RFC8040] over TLS over TCP as the DOTS data channel protocol. The
abstract layering of DOTS data channel is shown in Figure 2. abstract layering of DOTS data channel is shown in Figure 2.
+-------------------+ +-------------------+
| DOTS Data Channel | | DOTS Data Channel |
+-------------------+ +-------------------+
| RESTCONF | | RESTCONF |
+-------------------+ +-------------------+
| TLS | | TLS |
+-------------------+ +-------------------+
skipping to change at page 7, line 17 skipping to change at page 7, line 10
(Section 4) as JSON text. (Section 4) as JSON text.
A DOTS client registers itself to its DOTS server(s) in order to set A DOTS client registers itself to its DOTS server(s) in order to set
up DOTS data channel-related configuration data and receive state up DOTS data channel-related configuration data and receive state
data (i.e., non-configuration data) from the DOTS server(s) data (i.e., non-configuration data) from the DOTS server(s)
(Section 5). Mutual authentication considerations are specified in (Section 5). Mutual authentication considerations are specified in
Section 8 of [I-D.ietf-dots-signal-channel]. The coupling of signal Section 8 of [I-D.ietf-dots-signal-channel]. The coupling of signal
and data channels is discussed in Section 4.4.1 of and data channels is discussed in Section 4.4.1 of
[I-D.ietf-dots-signal-channel]. [I-D.ietf-dots-signal-channel].
A DOTS client can either maintain a persistent connection or periodic
connections with its DOTS server(s). If the DOTS client needs to
frequently update the drop-list or accept-list filtering rules or
aliases, it maintains a persistent connection with the DOTS server.
For example, CAPTCHA and cryptographic puzzles can be used by the
mitigation service in the DOTS client domain to determine whether the
IP address is used for legitimate purpose or not, and the DOTS client
can frequently update the drop-list filtering rules. A persistent
connection is also useful if the DOTS client subscribes to event
notifications (Section 6.3 of [RFC8040]).
A single DOTS data channel between DOTS agents can be used to A single DOTS data channel between DOTS agents can be used to
exchange multiple requests and multiple responses. To reduce DOTS exchange multiple requests and multiple responses. To reduce DOTS
client and DOTS server workload, DOTS clients SHOULD re-use the same client and DOTS server workload, DOTS clients SHOULD re-use the same
TLS session. While the communication to the DOTS server is TLS session. While the communication to the DOTS server is
quiescent, the DOTS client MAY probe the server to ensure it has quiescent, the DOTS client MAY probe the server to ensure it has
maintained cryptographic state. Such probes can also keep alive maintained cryptographic state. Such probes can also keep alive
firewall and/or NAT bindings. A TLS heartbeat [RFC6520] verifies firewall and/or NAT bindings. A TLS heartbeat [RFC6520] verifies
that the DOTS server still has TLS state by returning a TLS message. that the DOTS server still has TLS state by returning a TLS message.
A DOTS server may detect conflicting filtering requests from distinct A DOTS server may detect conflicting filtering requests from distinct
skipping to change at page 34, line 42 skipping to change at page 34, line 42
leaf fragment { leaf fragment {
type boolean; type boolean;
description description
"Indicates the capability of a DOTS server to "Indicates the capability of a DOTS server to
enforce filters on IPv6 fragments."; enforce filters on IPv6 fragments.";
} }
} }
container tcp { container tcp {
description description
"Set of TCP fields that are supported by the DOTS server "Set of TCP fields that are supported by the DOTS server
to enfoce filters."; to enforce filters.";
leaf sequence-number { leaf sequence-number {
type boolean; type boolean;
description description
"Support of filtering based on the TCP sequence number."; "Support of filtering based on the TCP sequence number.";
} }
leaf acknowledgement-number { leaf acknowledgement-number {
type boolean; type boolean;
description description
"Support of filtering based on the TCP acknowledgement "Support of filtering based on the TCP acknowledgement
number."; number.";
skipping to change at page 64, line 35 skipping to change at page 64, line 35
Andrew Mortensen Andrew Mortensen
Arbor Networks, Inc. Arbor Networks, Inc.
2727 S. State St 2727 S. State St
Ann Arbor, MI 48104 Ann Arbor, MI 48104
United States United States
Email: andrew.mortensen@netscout.com Email: andrew.mortensen@netscout.com
Nik Teague Nik Teague
Verisign, Inc. Iron Mountain Data Centers
United States United Kingdom
Email: nteague@verisign.com Email: nteague@ironmountain.co.uk
12. Contributors 12. Contributors
The following individuals have contributed to this document: The following individuals have contributed to this document:
o Dan Wing, Email: dwing-ietf@fuggles.com o Dan Wing, Email: dwing-ietf@fuggles.com
o Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.com o Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.com
13. Acknowledgements 13. Acknowledgements
skipping to change at page 65, line 31 skipping to change at page 65, line 31
Kuehlewind, and Warren Kumari for the review. Kuehlewind, and Warren Kumari for the review.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-dots-signal-channel] [I-D.ietf-dots-signal-channel]
K, R., Boucadair, M., Patil, P., Mortensen, A., and N. K, R., Boucadair, M., Patil, P., Mortensen, A., and N.
Teague, "Distributed Denial-of-Service Open Threat Teague, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification", draft- Signaling (DOTS) Signal Channel Specification", draft-
ietf-dots-signal-channel-31 (work in progress), March ietf-dots-signal-channel-34 (work in progress), May 2019.
2019.
[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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 67, line 11 skipping to change at page 66, line 52
"YANG Data Model for Network Access Control Lists (ACLs)", "YANG Data Model for Network Access Control Lists (ACLs)",
RFC 8519, DOI 10.17487/RFC8519, March 2019, RFC 8519, DOI 10.17487/RFC8519, March 2019,
<https://www.rfc-editor.org/info/rfc8519>. <https://www.rfc-editor.org/info/rfc8519>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-dots-architecture] [I-D.ietf-dots-architecture]
Mortensen, A., K, R., Andreasen, F., Teague, N., and R. Mortensen, A., K, R., Andreasen, F., Teague, N., and R.
Compton, "Distributed-Denial-of-Service Open Threat Compton, "Distributed-Denial-of-Service Open Threat
Signaling (DOTS) Architecture", draft-ietf-dots- Signaling (DOTS) Architecture", draft-ietf-dots-
architecture-13 (work in progress), April 2019. architecture-14 (work in progress), May 2019.
[I-D.ietf-dots-requirements]
Mortensen, A., K, R., and R. Moskowitz, "Distributed
Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-22 (work in
progress), March 2019.
[I-D.ietf-dots-server-discovery] [I-D.ietf-dots-server-discovery]
Boucadair, M., K, R., and P. Patil, "Distributed-Denial- Boucadair, M. and R. K, "Distributed-Denial-of-Service
of-Service Open Threat Signaling (DOTS) Server Discovery", Open Threat Signaling (DOTS) Server Discovery", draft-
draft-ietf-dots-server-discovery-02 (work in progress), ietf-dots-server-discovery-04 (work in progress), June
May 2019. 2019.
[proto_numbers] [proto_numbers]
"IANA, "Protocol Numbers"", 2011, "IANA, "Protocol Numbers"", 2011,
<http://www.iana.org/assignments/protocol-numbers>. <http://www.iana.org/assignments/protocol-numbers>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
skipping to change at page 68, line 37 skipping to change at page 68, line 22
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
Threat Signaling (DOTS) Requirements", RFC 8612,
DOI 10.17487/RFC8612, May 2019,
<https://www.rfc-editor.org/info/rfc8612>.
Appendix A. Sample Examples: Filtering Fragments Appendix A. Sample Examples: Filtering Fragments
This specification strongly recommends the use of "fragment" for This specification strongly recommends the use of "fragment" for
handling fragments. handling fragments.
Figure 34 shows the content of the POST request to be issued by a Figure 34 shows the content of the POST request to be issued by a
DOTS client to its DOTS server to allow the traffic destined to DOTS client to its DOTS server to allow the traffic destined to
198.51.100.0/24 and UDP port number 53, but to drop all fragmented 198.51.100.0/24 and UDP port number 53, but to drop all fragmented
packets. The following ACEs are defined (in this order): packets. The following ACEs are defined (in this order):
 End of changes. 16 change blocks. 
37 lines changed or deleted 44 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/