Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification
RFC 8783
|
Document |
Type |
|
RFC - Proposed Standard
(May 2020; No errata)
|
|
Authors |
|
Mohamed Boucadair
,
Tirumaleswar Reddy.K
|
|
Last updated |
|
2020-05-30
|
|
Replaces |
|
draft-reddy-dots-data-channel
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
xml
pdf
htmlized
bibtex
|
|
Yang Validation |
|
☯
0 errors, 0 warnings.
draft-ietf-dots-data-channel-31.txt:
xym 0.4.8:
Extracting 'ietf-dots-data-channel@2019-05-09.yang'
Removed 0 empty lines
ietf-dots-data-channel@2019-05-09.yang:
pyang 2.2.1: pyang --verbose --ietf -p {libs} {model}:
# module search path: a/www/ietf-ftp/yang/rfcmod/:/a/www/ietf-ftp/yang/draftmod/:/a/www/ietf-ftp/yang/ianamod/:.:/var/lib/wwwrun/yang/modules:/a/www/ietf-datatracker/7.1.0/env/share/yang/modules
# read ietf-dots-data-channel@2019-05-09.yang (CL)
# read /a/www/ietf-datatracker/7.1.0/env/share/yang/modules/ietf/ietf-inet-types.yang
# read /a/www/ietf-ftp/yang/rfcmod/ietf-inet-types@2013-07-15.yang
# read /a/www/ietf-datatracker/7.1.0/env/share/yang/modules/ietf/ietf-access-control-list.yang
# read /a/www/ietf-ftp/yang/rfcmod/ietf-access-control-list@2019-03-04.yang
# read /a/www/ietf-datatracker/7.1.0/env/share/yang/modules/ietf/ietf-yang-types.yang
# read /a/www/ietf-ftp/yang/rfcmod/ietf-yang-types@2013-07-15.yang
# read /a/www/ietf-datatracker/7.1.0/env/share/yang/modules/ietf/ietf-packet-fields.yang
# read /a/www/ietf-ftp/yang/rfcmod/ietf-packet-fields@2019-03-04.yang
# read /a/www/ietf-datatracker/7.1.0/env/share/yang/modules/ietf/ietf-ethertypes.yang
# read /a/www/ietf-ftp/yang/rfcmod/ietf-ethertypes@2019-03-04.yang
# read /a/www/ietf-datatracker/7.1.0/env/share/yang/modules/ietf/ietf-interfaces.yang
# read /a/www/ietf-ftp/yang/rfcmod/ietf-interfaces@2018-02-20.yang
yanglint SO 1.6.7: yanglint --verbose -p {rfclib} -p {draftlib} -p {tmplib} {model} -i:
No validation errors
|
|
Reviews |
|
|
|
Additional Resources |
|
|
Stream |
WG state
|
|
Submitted to IESG for Publication
|
|
Document shepherd |
|
Roman Danyliw
|
|
Shepherd write-up |
|
Show
(last changed 2019-02-27)
|
IESG |
IESG state |
|
RFC 8783 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Yes
|
|
Telechat date |
|
|
|
Responsible AD |
|
Benjamin Kaduk
|
|
Send notices to |
|
Roman Danyliw <rdd@cert.org>
|
IANA |
IANA review state |
|
Version Changed - Review Needed
|
|
IANA action state |
|
RFC-Ed-Ack
|
Internet Engineering Task Force (IETF) M. Boucadair, Ed.
Request for Comments: 8783 Orange
Category: Standards Track T. Reddy.K, Ed.
ISSN: 2070-1721 McAfee
May 2020
Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel
Specification
Abstract
The document specifies a Distributed Denial-of-Service Open Threat
Signaling (DOTS) data channel used for bulk exchange of data that
cannot easily or appropriately communicated through the DOTS signal
channel under attack conditions.
This is a companion document to "Distributed Denial-of-Service Open
Threat Signaling (DOTS) Signal Channel Specification" (RFC 8782).
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8783.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction
2. Terminology
3. DOTS Data Channel
3.1. Design Overview
3.2. DOTS Server(s) Discovery
3.3. DOTS Gateways
3.4. Detecting and Preventing Infinite Loops
3.5. Preventing Stale Entries
4. DOTS Data Channel YANG Module
4.1. Generic Tree Structure
4.2. Filtering Fields
4.3. YANG Module
5. Managing DOTS Clients
5.1. Registering DOTS Clients
5.2. De-registering DOTS Clients
6. Managing DOTS Aliases
6.1. Creating Aliases
6.2. Retrieving Installed Aliases
6.3. Deleting Aliases
7. Managing DOTS Filtering Rules
7.1. Retrieving DOTS Filtering Capabilities
7.2. Installing Filtering Rules
7.3. Retrieving Installed Filtering Rules
7.4. Removing Filtering Rules
8. Operational Considerations
9. IANA Considerations
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Examples: Filtering Fragments
Appendix B. Examples: Filtering TCP Messages
B.1. Discard TCP Null Attack
B.2. Rate-Limit SYN Flooding
B.3. Rate-Limit ACK Flooding
Acknowledgements
Contributors
Authors' Addresses
1. Introduction
A distributed denial-of-service (DDoS) attack is an attempt to make
machines or network resources unavailable to their intended users.
In most cases, sufficient scale can be achieved by compromising
enough end hosts and using those infected hosts to perpetrate and
amplify the attack. The victim of such an attack can be an
application server, a router, a firewall, an entire network, etc.
As discussed in [RFC8612], the lack of a common method to coordinate
a real-time response among involved actors and network domains
inhibits the speed and effectiveness of DDoS attack mitigation. From
that standpoint, DDoS Open Threat Signaling (DOTS) defines an
architecture that allows a DOTS client to send requests to a DOTS
server for DDoS attack mitigation [DOTS-ARCH]. The DOTS approach is
thus meant to minimize the impact of DDoS attacks, thereby
contributing to the enforcement of more efficient defensive if not
proactive security strategies. To that aim, DOTS defines two
channels: the signal channel and the data channel (Figure 1).
+---------------+ +---------------+
| | <------- Signal Channel ------> | |
| DOTS Client | | DOTS Server |
| | <======= Data Channel ======> | |
+---------------+ +---------------+
Figure 1: DOTS Channels
The DOTS signal channel is used to carry information about a device
Show full document text