< draft-ietf-dots-rfc8782-bis-07.txt   draft-ietf-dots-rfc8782-bis-08.txt >
DOTS M. Boucadair, Ed. DOTS M. Boucadair, Ed.
Internet-Draft Orange Internet-Draft Orange
Obsoletes: 8782 (if approved) J. Shallow Obsoletes: 8782 (if approved) J. Shallow
Intended status: Standards Track Intended status: Standards Track
Expires: November 28, 2021 T. Reddy.K Expires: December 5, 2021 T. Reddy.K
McAfee McAfee
May 27, 2021 June 3, 2021
Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel Specification Channel Specification
draft-ietf-dots-rfc8782-bis-07 draft-ietf-dots-rfc8782-bis-08
Abstract Abstract
This document specifies the Distributed Denial-of-Service Open Threat This document specifies the Distributed Denial-of-Service Open Threat
Signaling (DOTS) signal channel, a protocol for signaling the need Signaling (DOTS) signal channel, a protocol for signaling the need
for protection against Distributed Denial-of-Service (DDoS) attacks for protection against Distributed Denial-of-Service (DDoS) attacks
to a server capable of enabling network traffic mitigation on behalf to a server capable of enabling network traffic mitigation on behalf
of the requesting client. of the requesting client.
A companion document defines the DOTS data channel, a separate A companion document defines the DOTS data channel, a separate
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 28, 2021. This Internet-Draft will expire on December 5, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Backward Compatibility Considerations . . . . . . . . . . 9 3.1. Backward Compatibility Considerations . . . . . . . . . . 9
4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 10 4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 10
4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 10 4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 10
4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 10 4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 11
4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 13 4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 13
4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 13 4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 14
4.4.1.1. Building Mitigation Requests . . . . . . . . . . 13 4.4.1.1. Building Mitigation Requests . . . . . . . . . . 14
4.4.1.2. Server-domain DOTS Gateways . . . . . . . . . . . 21 4.4.1.2. Server-domain DOTS Gateways . . . . . . . . . . . 22
4.4.1.3. Processing Mitigation Requests . . . . . . . . . 23 4.4.1.3. Processing Mitigation Requests . . . . . . . . . 24
4.4.2. Retrieve Information Related to a Mitigation . . . . 29 4.4.2. Retrieve Information Related to a Mitigation . . . . 30
4.4.2.1. DOTS Servers Sending Mitigation Status . . . . . 35 4.4.2.1. DOTS Servers Sending Mitigation Status . . . . . 36
4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 37 4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 38
4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 38 4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 39
4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 40 4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 41
4.5. DOTS Signal Channel Session Configuration . . . . . . . . 41 4.5. DOTS Signal Channel Session Configuration . . . . . . . . 42
4.5.1. Discover Configuration Parameters . . . . . . . . . . 43 4.5.1. Discover Configuration Parameters . . . . . . . . . . 44
4.5.2. Convey DOTS Signal Channel Session Configuration . . 47 4.5.2. Convey DOTS Signal Channel Session Configuration . . 48
4.5.3. Configuration Freshness and Notifications . . . . . . 53 4.5.3. Configuration Freshness and Notifications . . . . . . 54
4.5.4. Delete DOTS Signal Channel Session Configuration . . 54 4.5.4. Delete DOTS Signal Channel Session Configuration . . 55
4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 55 4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 56
4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 57 4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 58
5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 60 5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 61
5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 60 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 61
5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 63 5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 64
5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 67 5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 68
6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 80 6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 81
7. (D)TLS Protocol Profile and Performance Considerations . . . 84 7. (D)TLS Protocol Profile and Performance Considerations . . . 85
7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 84 7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 85
7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 86 7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 87
7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 87 7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 89
8. Mutual Authentication of DOTS Agents & Authorization of DOTS 8. Mutual Authentication of DOTS Agents & Authorization of DOTS
Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 90 9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 91
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92
10.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . 91 10.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . 92
10.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . 92 10.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . 93
10.3. Media Type Registration . . . . . . . . . . . . . . . . 92 10.3. Media Type Registration . . . . . . . . . . . . . . . . 93
10.4. CoAP Content-Formats Registration . . . . . . . . . . . 93 10.4. CoAP Content-Formats Registration . . . . . . . . . . . 94
10.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . 94 10.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . 95
10.6. DOTS Signal Channel Protocol Registry . . . . . . . . . 94 10.6. DOTS Signal Channel Protocol Registry . . . . . . . . . 95
10.6.1. DOTS Signal Channel CBOR Key Values Subregistry . . 94 10.6.1. DOTS Signal Channel CBOR Key Values Subregistry . . 95
10.6.1.1. Registration Template . . . . . . . . . . . . . 94 10.6.1.1. Registration Template . . . . . . . . . . . . . 95
10.6.1.2. Update Subregistry Content . . . . . . . . . . . 96 10.6.1.2. Update Subregistry Content . . . . . . . . . . . 97
10.6.2. Status Codes Subregistry . . . . . . . . . . . . . . 96 10.6.2. Status Codes Subregistry . . . . . . . . . . . . . . 97
10.6.3. Conflict Status Codes Subregistry . . . . . . . . . 98 10.6.3. Conflict Status Codes Subregistry . . . . . . . . . 99
10.6.4. Conflict Cause Codes Subregistry . . . . . . . . . . 99 10.6.4. Conflict Cause Codes Subregistry . . . . . . . . . . 100
10.6.5. Attack Status Codes Subregistry . . . . . . . . . . 100 10.6.5. Attack Status Codes Subregistry . . . . . . . . . . 101
10.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 101 10.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 102
11. Security Considerations . . . . . . . . . . . . . . . . . . . 103 11. Security Considerations . . . . . . . . . . . . . . . . . . . 104
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 105 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 106
12.1. Normative References . . . . . . . . . . . . . . . . . . 105 12.1. Normative References . . . . . . . . . . . . . . . . . . 106
12.2. Informative References . . . . . . . . . . . . . . . . . 108 12.2. Informative References . . . . . . . . . . . . . . . . . 109
Appendix A. Summary of Changes From RFC8782 . . . . . . . . . . 113 Appendix A. Summary of Changes From RFC8782 . . . . . . . . . . 114
Appendix B. CUID Generation . . . . . . . . . . . . . . . . . . 114 Appendix B. CUID Generation . . . . . . . . . . . . . . . . . . 115
Appendix C. Summary of Protocol Recommended/Default Values . . . 114 Appendix C. Summary of Protocol Recommended/Default Values . . . 115
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 115 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 116
D.1. Acknowledgements from RFC8782 . . . . . . . . . . . . . . 115 D.1. Acknowledgements from RFC8782 . . . . . . . . . . . . . . 116
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 115 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 116
E.1. Authors of RFC8782 . . . . . . . . . . . . . . . . . . . 115 E.1. Authors of RFC8782 . . . . . . . . . . . . . . . . . . . 116
E.2. Contributors to RFC8782 . . . . . . . . . . . . . . . . . 116 E.2. Contributors to RFC8782 . . . . . . . . . . . . . . . . . 117
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 118
1. Introduction 1. Introduction
A Distributed Denial-of-Service (DDoS) attack is a distributed A Distributed Denial-of-Service (DDoS) attack is a distributed
attempt to make machines or network resources unavailable to their attempt to make machines or network resources unavailable to their
intended users. In most cases, sufficient scale for an effective intended users. In most cases, sufficient scale for an effective
attack can be achieved by compromising enough end hosts and using attack can be achieved by compromising enough end hosts and using
those infected hosts to perpetrate and amplify the attack. The those infected hosts to perpetrate and amplify the attack. The
victim in this attack can be an application server, a host, a router, victim in this attack can be an application server, a host, a router,
a firewall, or an entire network. a firewall, or an entire network.
skipping to change at page 4, line 41 skipping to change at page 4, line 41
[RFC8612]. [RFC8612].
In typical deployments, the DOTS client belongs to a different In typical deployments, the DOTS client belongs to a different
administrative domain than the DOTS server. For example, the DOTS administrative domain than the DOTS server. For example, the DOTS
client is embedded in a firewall protected services owned and client is embedded in a firewall protected services owned and
operated by a customer, while the DOTS server is owned and operated operated by a customer, while the DOTS server is owned and operated
by a different administrative entity (service provider, typically) by a different administrative entity (service provider, typically)
providing DDoS mitigation services. The latter might or might not providing DDoS mitigation services. The latter might or might not
provide connectivity services to the network hosting the DOTS client. provide connectivity services to the network hosting the DOTS client.
The DOTS server may or may not not be co-located with the DOTS The DOTS server may or may not be co-located with the DOTS mitigator.
mitigator. In typical deployments, the DOTS server belongs to the In typical deployments, the DOTS server belongs to the same
same administrative domain as the mitigator. The DOTS client can administrative domain as the mitigator. The DOTS client can
communicate directly with a DOTS server or indirectly via a DOTS communicate directly with a DOTS server or indirectly via a DOTS
gateway. gateway.
An example of a network diagram that illustrates a deployment of DOTS An example of a network diagram that illustrates a deployment of DOTS
agents is shown in Figure 1. In this example, a DOTS server is agents is shown in Figure 1. In this example, a DOTS server is
operating on the access network. A DOTS client is located on the LAN operating on the access network. A DOTS client is located on the LAN
(Local Area Network), while a DOTS gateway is embedded in the CPE (Local Area Network), while a DOTS gateway is embedded in the CPE
(Customer Premises Equipment). (Customer Premises Equipment).
Network Network
Resource CPE Router Access Network __________ Resource CPE Router Access Network __________
+-----------+ +--------------+ +-------------+ / \ +-------------+ +--------------+ +-------------+ / \
| |___| |____| |___ | Internet | | | | | | | | Internet |
|DOTS Client| | DOTS Gateway | | DOTS Server | | | | DOTS Client +---+ DOTS Gateway +---+ DOTS Server +----+ |
| | | | | | | | | | | | | | | |
+-----------+ +--------------+ +-------------+ \__________/ +-------------+ +--------------+ +-------------+ \__________/
Figure 1: Sample DOTS Deployment (1) Figure 1: Sample DOTS Deployment (1)
DOTS servers can also be reachable over the Internet, as depicted in DOTS servers can also be reachable over the Internet, as depicted in
Figure 2. Figure 2.
Network DDoS Mitigation Network DDoS Mitigation
Resource CPE Router __________ Service Resource CPE Router _________ Service
+-----------+ +--------------+ / \ +-------------+ +-------------+ +--------------+ / \ +-------------+
| |___| |____| |___ | | | | | | | | | |
|DOTS Client| | DOTS Gateway | | Internet | | DOTS Server | | DOTS Client +---+ DOTS Gateway +---+ Internet +---+ DOTS Server |
| | | | | | | | | | | | | | | |
+-----------+ +--------------+ \__________/ +-------------+ +-------------+ +--------------+ \_________/ +-------------+
Figure 2: Sample DOTS Deployment (2) Figure 2: Sample DOTS Deployment (2)
This document adheres to the DOTS architecture [RFC8811]. The This document adheres to the DOTS architecture [RFC8811]. The
requirements for DOTS signal channel protocol are documented in requirements for DOTS signal channel protocol are documented in
[RFC8612]. This document satisfies all the use cases discussed in [RFC8612]. This document satisfies all the use cases discussed in
[I-D.ietf-dots-use-cases]. [RFC8903].
This document focuses on the DOTS signal channel. This is a This document focuses on the DOTS signal channel. This is a
companion document of the DOTS data channel specification [RFC8783] companion document of the DOTS data channel specification [RFC8783]
that defines a configuration and a bulk data exchange mechanism that defines a configuration and a bulk data exchange mechanism
supporting the DOTS signal channel. supporting the DOTS signal channel.
Backward compatibility (including upgrade) considerations are Backward compatibility (including upgrade) considerations are
discussed in Section 3.1. discussed in Section 3.1.
2. Terminology 2. Terminology
skipping to change at page 9, line 37 skipping to change at page 9, line 37
server. server.
o A DOTS gateway may be co-located with the translator. The DOTS o A DOTS gateway may be co-located with the translator. The DOTS
gateway will need to update the DOTS messages based upon the local gateway will need to update the DOTS messages based upon the local
translator's binding table. translator's binding table.
3.1. Backward Compatibility Considerations 3.1. Backward Compatibility Considerations
The main changes to [RFC8782] are listed in Appendix A. These The main changes to [RFC8782] are listed in Appendix A. These
modifications are made with the constraint to avoid changes to the modifications are made with the constraint to avoid changes to the
mapping table defined in Table 5 of [RFC8782] (see also Section 6). mapping table defined in Table 5 of [RFC8782] (see also Section 6 of
For both legacy and implementations that follow the present the present document).
For both legacy [RFC8782] and implementations that follow the present
specification, a DOTS signal channel attribute will thus have the specification, a DOTS signal channel attribute will thus have the
same CBOR key value and CBOR major type. The only upgrade that is same CBOR key value and CBOR major type. The only upgrade that is
required to [RFC8782] implementations is to handle the CBOR key value required to [RFC8782] implementations is to handle the CBOR key value
range "128-255" as comprehension-optional instead of comprehension- range "128-255" as comprehension-optional instead of comprehension-
required. Note that this range is anticipated to be used by the DOTS required. Note that this range is anticipated to be used by the DOTS
telemetry [I-D.ietf-dots-telemetry] in which the following means are telemetry [I-D.ietf-dots-telemetry] in which the following means are
used to prevent message processing failure of a DOTS signal channel used to prevent message processing failure of a DOTS signal channel
message enriched with telemetry data: (1) DOTS agents use dedicated message enriched with telemetry data: (1) DOTS agents use dedicated
(new) path suffixes (Section 5 of [I-D.ietf-dots-telemetry]) and (2) (new) path suffixes (Section 5 of [I-D.ietf-dots-telemetry]) and (2)
a DOTS server won't include telemetry attributes in its responses a DOTS server won't include telemetry attributes in its responses
skipping to change at page 13, line 43 skipping to change at page 13, line 47
NOT send more than one Non-confirmable request every 3 seconds, and NOT send more than one Non-confirmable request every 3 seconds, and
SHOULD use an even less aggressive rate whenever possible (case 2 in SHOULD use an even less aggressive rate whenever possible (case 2 in
Section 3.1.3 of [RFC8085]). Mitigation requests MUST NOT be delayed Section 3.1.3 of [RFC8085]). Mitigation requests MUST NOT be delayed
because of checks on probing rate (Section 4.7 of [RFC7252]). because of checks on probing rate (Section 4.7 of [RFC7252]).
JSON encoding of YANG modeled data [RFC7951] is used to illustrate JSON encoding of YANG modeled data [RFC7951] is used to illustrate
the various methods defined in the following subsections. Also, the the various methods defined in the following subsections. Also, the
examples use the Labels defined in Sections 10.6.2, 10.6.3, 10.6.4, examples use the Labels defined in Sections 10.6.2, 10.6.3, 10.6.4,
and 10.6.5. and 10.6.5.
The DOTS client MUST authenticate itself to the DOTS server
(Section 8). The DOTS server MAY use the algorithm presented in
Section 7 of [RFC7589] to derive the DOTS client identity or username
from the client certificate. The DOTS client identity allows the
DOTS server to accept mitigation requests with scopes that the DOTS
client is authorized to manage.
4.4.1. Request Mitigation 4.4.1. Request Mitigation
4.4.1.1. Building Mitigation Requests 4.4.1.1. Building Mitigation Requests
When a DOTS client requires mitigation for some reason, the DOTS When a DOTS client requires mitigation for some reason, the DOTS
client uses the CoAP PUT method to send a mitigation request to its client uses the CoAP PUT method to send a mitigation request to its
DOTS server(s) (Figures 5 and 6). DOTS server(s) (Figures 5 and 6).
If a DOTS client is entitled to solicit the DOTS service, the DOTS If a DOTS client is entitled to solicit the DOTS service, the DOTS
server enables mitigation on behalf of the DOTS client by server enables mitigation on behalf of the DOTS client by
skipping to change at page 14, line 33 skipping to change at page 14, line 44
resource. In particular, 'mid' MUST follow 'cuid'. resource. In particular, 'mid' MUST follow 'cuid'.
The additional Uri-Path parameters to those defined in Section 4.2 The additional Uri-Path parameters to those defined in Section 4.2
are as follows: are as follows:
cuid: Stands for Client Unique Identifier. A globally unique cuid: Stands for Client Unique Identifier. A globally unique
identifier that is meant to prevent collisions among DOTS identifier that is meant to prevent collisions among DOTS
clients, especially those from the same domain. It MUST be clients, especially those from the same domain. It MUST be
generated by DOTS clients. generated by DOTS clients.
For the reasons discussed in Appendix A, implementations SHOULD For the reasons discussed in Appendix B, implementations SHOULD
set 'cuid' using the following procedure: first, the DOTS set 'cuid' using the following procedure: first, the DOTS
client inputs one of the following into the SHA-256 [RFC6234] client inputs one of the following into the SHA-256 [RFC6234]
cryptographic hash: the DER-encoded ASN.1 representation of the cryptographic hash: the DER-encoded ASN.1 representation of the
Subject Public Key Info (SPKI) of its X.509 certificate Subject Public Key Info (SPKI) of its X.509 certificate
[RFC5280], its raw public key [RFC7250], the "Pre-Shared Key [RFC5280], its raw public key [RFC7250], the "Pre-Shared Key
(PSK) identity" it uses in the TLS 1.2 ClientKeyExchange (PSK) identity" it uses in the TLS 1.2 ClientKeyExchange
message, or the "identity" it uses in the "pre_shared_key" TLS message, or the "identity" it uses in the "pre_shared_key" TLS
1.3 extension. Then, the output of the cryptographic hash 1.3 extension. Then, the output of the cryptographic hash
algorithm is truncated to 16 bytes; truncation is done by algorithm is truncated to 16 bytes; truncation is done by
stripping off the final 16 bytes. The truncated output is stripping off the final 16 bytes. The truncated output is
skipping to change at page 17, line 43 skipping to change at page 18, line 4
This is an optional attribute. This is an optional attribute.
target-fqdn: A list of Fully Qualified Domain Names (FQDNs) target-fqdn: A list of Fully Qualified Domain Names (FQDNs)
identifying resources under attack [RFC8499]. identifying resources under attack [RFC8499].
How a name is passed to an underlying name resolution library is How a name is passed to an underlying name resolution library is
implementation and deployment specific. Nevertheless, once the implementation and deployment specific. Nevertheless, once the
name is resolved into one or multiple IP addresses, DOTS servers name is resolved into one or multiple IP addresses, DOTS servers
MUST apply the same validation checks as those for 'target- MUST apply the same validation checks as those for 'target-
prefix'. prefix'. These validation checks are reiterated by DOTS servers
each time a name is passed to an underlying name resolution
library (e.g., upon expiry of DNS TTL).
The use of FQDNs may be suboptimal because: The use of FQDNs may be suboptimal because:
* It induces both an extra load and increased delays on the DOTS * It induces both an extra load and increased delays on the DOTS
server to handle and manage DNS resolution requests. server to handle and manage DNS resolution requests.
* It does not guarantee that the DOTS server will resolve a name * It does not guarantee that the DOTS server will resolve a name
to the same IP addresses that the DOTS client does. to the same IP addresses that the DOTS client does.
This is an optional attribute. This is an optional attribute.
skipping to change at page 18, line 30 skipping to change at page 18, line 41
more efficiently to the resources under attack. more efficiently to the resources under attack.
This is an optional attribute. This is an optional attribute.
lifetime: Lifetime of the mitigation request in seconds. The lifetime: Lifetime of the mitigation request in seconds. The
RECOMMENDED lifetime of a mitigation request is 3600 seconds: this RECOMMENDED lifetime of a mitigation request is 3600 seconds: this
value was chosen to be long enough so that refreshing is not value was chosen to be long enough so that refreshing is not
typically a burden on the DOTS client, while still making the typically a burden on the DOTS client, while still making the
request expire in a timely manner when the client has unexpectedly request expire in a timely manner when the client has unexpectedly
quit. DOTS clients MUST include this parameter in their quit. DOTS clients MUST include this parameter in their
mitigation requests. Upon the expiry of this lifetime, and if the mitigation requests.
request is not refreshed, the mitigation request is removed. The
request can be refreshed by sending the same request again.
A lifetime of '0' in a mitigation request is an invalid value. A lifetime of '0' in a mitigation request is an invalid value.
A lifetime of negative one (-1) indicates indefinite lifetime for A lifetime of negative one (-1) indicates indefinite lifetime for
the mitigation request. The DOTS server MAY refuse an indefinite the mitigation request. The DOTS server MAY refuse an indefinite
lifetime, for policy reasons; the granted lifetime value is lifetime, for policy reasons; the granted lifetime value is
returned in the response. DOTS clients MUST be prepared to not be returned in the response. DOTS clients MUST be prepared to not be
granted mitigations with indefinite lifetimes. granted mitigations with indefinite lifetimes.
The DOTS server MUST always indicate the actual lifetime in the The DOTS server MUST always indicate the actual lifetime in the
response and the remaining lifetime in status messages sent to the response and the remaining lifetime in status messages sent to the
DOTS client. DOTS client.
Upon the expiry of the negotiated lifetime (i.e., the remaining
lifetime reaches '0'), and if the request is not refreshed by the
DOTS client, the mitigation request is removed by the DOTS server.
The request can be refreshed by sending the same request again.
This is a mandatory attribute. This is a mandatory attribute.
trigger-mitigation: If the parameter value is set to 'false', DDoS trigger-mitigation: If the parameter value is set to 'false', DDoS
mitigation will not be triggered for the mitigation request unless mitigation will not be triggered for the mitigation request unless
the DOTS signal channel session is lost. the DOTS signal channel session is lost.
If the DOTS client ceases to respond to heartbeat messages, the If the DOTS client ceases to respond to heartbeat messages, the
DOTS server can detect that the DOTS signal channel session is DOTS server can detect that the DOTS signal channel session is
lost. More details are discussed in Section 4.7. lost. More details are discussed in Section 4.7.
skipping to change at page 21, line 36 skipping to change at page 22, line 36
08 # unsigned(8) 08 # unsigned(8)
19 1F90 # unsigned(8080) 19 1F90 # unsigned(8080)
0A # unsigned(10) 0A # unsigned(10)
81 # array(1) 81 # array(1)
06 # unsigned(6) 06 # unsigned(6)
0E # unsigned(14) 0E # unsigned(14)
19 0E10 # unsigned(3600) 19 0E10 # unsigned(3600)
Figure 8: PUT for DOTS Mitigation Request (CBOR) Figure 8: PUT for DOTS Mitigation Request (CBOR)
In both DOTS signal and data channel sessions, the DOTS client MUST
authenticate itself to the DOTS server (Section 8). The DOTS server
MAY use the algorithm presented in Section 7 of [RFC7589] to derive
the DOTS client identity or username from the client certificate.
The DOTS client identity allows the DOTS server to accept mitigation
requests with scopes that the DOTS client is authorized to manage.
4.4.1.2. Server-domain DOTS Gateways 4.4.1.2. Server-domain DOTS Gateways
In deployments where server-domain DOTS gateways are enabled, In deployments where server-domain DOTS gateways are enabled,
identity information about the origin source client domain ('cdid') identity information about the origin source client domain ('cdid')
SHOULD be propagated to the DOTS server. That information is meant SHOULD be propagated to the DOTS server. That information is meant
to assist the DOTS server in enforcing some policies such as grouping to assist the DOTS server in enforcing some policies such as grouping
DOTS clients that belong to the same DOTS domain, limiting the number DOTS clients that belong to the same DOTS domain, limiting the number
of DOTS requests, and identifying the mitigation scope. These of DOTS requests, and identifying the mitigation scope. These
policies can be enforced per client, per client domain, or both. policies can be enforced per client, per client domain, or both.
Also, the identity information may be used for auditing and debugging Also, the identity information may be used for auditing and debugging
purposes. purposes.
Figure 9 shows an example of a request relayed by a server-domain Figure 9 shows an example of a request relayed by a server-domain
DOTS gateway. DOTS gateway.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
skipping to change at page 24, line 7 skipping to change at page 24, line 51
detect duplicate mitigation requests. If the mitigation request detect duplicate mitigation requests. If the mitigation request
contains the 'alias-name' and other parameters identifying the target contains the 'alias-name' and other parameters identifying the target
resources (such as 'target-prefix', 'target-port-range', 'target- resources (such as 'target-prefix', 'target-port-range', 'target-
fqdn', or 'target-uri'), the DOTS server appends the parameter values fqdn', or 'target-uri'), the DOTS server appends the parameter values
associated with the 'alias-name' with the corresponding parameter associated with the 'alias-name' with the corresponding parameter
values in 'target-prefix', 'target-port-range', 'target-fqdn', or values in 'target-prefix', 'target-port-range', 'target-fqdn', or
'target-uri'. 'target-uri'.
The DOTS server indicates the result of processing the PUT request The DOTS server indicates the result of processing the PUT request
using CoAP Response Codes. CoAP 2.xx codes are success. CoAP 4.xx using CoAP Response Codes. CoAP 2.xx codes are success. CoAP 4.xx
codes are some sort of invalid requests (client errors). COAP 5.xx codes are some sort of invalid requests (client errors). CoAP 5.xx
codes are returned if the DOTS server is in an error state or is codes are returned if the DOTS server is in an error state or is
currently unavailable to provide mitigation in response to the currently unavailable to provide mitigation in response to the
mitigation request from the DOTS client. mitigation request from the DOTS client.
Figure 10 shows an example response to a PUT request that is Figure 10 shows an example response to a PUT request that is
successfully processed by a DOTS server (i.e., CoAP 2.xx Response successfully processed by a DOTS server (i.e., CoAP 2.xx Response
Codes). This version of the specification forbids 'cuid' and 'cdid' Codes). This version of the specification forbids 'cuid' and 'cdid'
(if used) to be returned in a response message body. (if used) to be returned in a response message body.
{ {
skipping to change at page 28, line 5 skipping to change at page 29, line 5
If the DOTS server decides to maintain a state for the If the DOTS server decides to maintain a state for the
deactivated mitigation request, the DOTS server updates the deactivated mitigation request, the DOTS server updates the
lifetime of the deactivated mitigation request to 'retry-timer lifetime of the deactivated mitigation request to 'retry-timer
+ 45 seconds' (that is, this mitigation request remains + 45 seconds' (that is, this mitigation request remains
deactivated for the entire duration of 'retry-timer + 45 deactivated for the entire duration of 'retry-timer + 45
seconds') so that the DOTS client can refresh the deactivated seconds') so that the DOTS client can refresh the deactivated
mitigation request after 'retry-timer' seconds, but before the mitigation request after 'retry-timer' seconds, but before the
expiry of the lifetime, and check if the conflict is resolved. expiry of the lifetime, and check if the conflict is resolved.
(1) Request with a conflicting 'cuid'
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=7eeaf349529eb55ed50113" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=12" Uri-Path: "mid=12"
(1) Request with a conflicting 'cuid' (2) Message body of the 4.09 (Conflict) response
from the DOTS server
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"conflict-information": { "conflict-information": {
"conflict-cause": "cuid-collision" "conflict-cause": "cuid-collision"
} }
} }
] ]
} }
} }
(2) Message body of the 4.09 (Conflict) response (3) Request with a new 'cuid'
from the DOTS server
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=f30d281ce6b64fc5a0b91e" Uri-Path: "cuid=f30d281ce6b64fc5a0b91e"
Uri-Path: "mid=12" Uri-Path: "mid=12"
(3) Request with a new 'cuid'
Figure 11: Example of Generating a New 'cuid' Figure 11: Example of Generating a New 'cuid'
As an active attack evolves, DOTS clients can adjust the scope of As an active attack evolves, DOTS clients can adjust the scope of
requested mitigation as necessary, by refining the scope of resources requested mitigation as necessary, by refining the scope of resources
requiring mitigation. This can be achieved by sending a PUT request requiring mitigation. This can be achieved by sending a PUT request
with a new 'mid' value that will override the existing one with with a new 'mid' value that will override the existing one with
overlapping mitigation scopes. overlapping mitigation scopes.
For a mitigation request to continue beyond the initial negotiated For a mitigation request to continue beyond the initial negotiated
lifetime, the DOTS client has to refresh the current mitigation lifetime, the DOTS client has to refresh the current mitigation
request by sending a new PUT request. This PUT request MUST use the request by sending a new PUT request. This PUT request MUST use the
same 'mid' value, and it MUST repeat all the other parameters as sent same 'mid' value, and it MUST repeat all the other parameters as sent
in the original mitigation request apart from a possible change to in the original mitigation request apart from a possible change to
the 'lifetime' parameter value. In such a case, the DOTS server MAY the 'lifetime' parameter value. In such a case, the DOTS server MAY
update the mitigation request, and a 2.04 (Changed) response is update the mitigation request by setting the remaining lifetime to
the newly negotiated lifetime, and a 2.04 (Changed) response is
returned to indicate a successful update of the mitigation request. returned to indicate a successful update of the mitigation request.
If this is not the case, the DOTS server MUST reject the request with If this is not the case, the DOTS server MUST reject the request with
a 4.00 (Bad Request). a 4.00 (Bad Request).
4.4.2. Retrieve Information Related to a Mitigation 4.4.2. Retrieve Information Related to a Mitigation
A GET request is used by a DOTS client to retrieve information A GET request is used by a DOTS client to retrieve information
(including status) of DOTS mitigations from a DOTS server. (including status) of DOTS mitigations from a DOTS server.
'cuid' is a mandatory Uri-Path parameter for GET requests. 'cuid' is a mandatory Uri-Path parameter for GET requests.
skipping to change at page 35, line 26 skipping to change at page 36, line 26
request to receive asynchronous notifications of attack mitigation request to receive asynchronous notifications of attack mitigation
status from the DOTS server. status from the DOTS server.
Unidirectional mitigation notifications within the bidirectional Unidirectional mitigation notifications within the bidirectional
signal channel enables asynchronous notifications between the agents. signal channel enables asynchronous notifications between the agents.
[RFC7641] indicates that (1) a notification can be sent in a [RFC7641] indicates that (1) a notification can be sent in a
Confirmable or a Non-confirmable message, and (2) the message type Confirmable or a Non-confirmable message, and (2) the message type
used is typically application dependent and may be determined by the used is typically application dependent and may be determined by the
server for each notification individually. For the DOTS server server for each notification individually. For the DOTS server
application, the message type MUST always be set to Non-confirmable application, the message type MUST always be set to Non-confirmable
even if the underlying COAP library elects a notification to be sent even if the underlying CoAP library elects a notification to be sent
in a Confirmable message. This overrides the behavior defined in in a Confirmable message. This overrides the behavior defined in
Section 4.5 of [RFC7641] to send a Confirmable message instead of a Section 4.5 of [RFC7641] to send a Confirmable message instead of a
Non-confirmable message at least every 24 hours for the following Non-confirmable message at least every 24 hours for the following
reasons: First, the DOTS signal channel uses a heartbeat mechanism to reasons: First, the DOTS signal channel uses a heartbeat mechanism to
determine if the DOTS client is alive. Second, Confirmable messages determine if the DOTS client is alive. Second, Confirmable messages
are not suitable during an attack. are not suitable during an attack.
Due to the higher likelihood of packet loss during a DDoS attack, the Due to the higher likelihood of packet loss during a DDoS attack, the
DOTS server periodically sends attack mitigation status to the DOTS DOTS server periodically sends attack mitigation status to the DOTS
client and also notifies the DOTS client whenever the status of the client and also notifies the DOTS client whenever the status of the
skipping to change at page 45, line 30 skipping to change at page 46, line 30
'0' is used to disable the heartbeat mechanism. '0' is used to disable the heartbeat mechanism.
This is an optional attribute. This is an optional attribute.
missing-hb-allowed: Maximum number of consecutive heartbeat missing-hb-allowed: Maximum number of consecutive heartbeat
messages for which the DOTS agent did not receive a response messages for which the DOTS agent did not receive a response
before concluding that the session is disconnected. before concluding that the session is disconnected.
This is an optional attribute. This is an optional attribute.
probing-rate: The average data rate that must not be exceeded by probing-rate: The average data rate, in bytes/second, that must
a DOTS agent in sending to a peer DOTS agent that does not not be exceeded by a DOTS agent in sending to a peer DOTS agent
respond (referred to as PROBING_RATE parameter in CoAP). that does not respond (referred to as PROBING_RATE parameter in
CoAP).
This is an optional attribute. This is an optional attribute.
max-retransmit: Maximum number of retransmissions for a message max-retransmit: Maximum number of retransmissions for a message
(referred to as MAX_RETRANSMIT parameter in CoAP). (referred to as MAX_RETRANSMIT parameter in CoAP).
This is an optional attribute. This is an optional attribute.
ack-timeout: Timeout value in seconds used to calculate the ack-timeout: Timeout value in seconds used to calculate the
initial retransmission timeout value (referred to as initial retransmission timeout value (referred to as
skipping to change at page 69, line 24 skipping to change at page 70, line 24
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2021-03-02 { revision 2021-03-02 {
description description
"Updated revision to comply with RFC8791."; "Updated revision to comply with RFC8791.
This version is not backward compatible with the version
published in RFC 8782.";
reference reference
"RFC XXXX: Distributed Denial-of-Service Open Threat "RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
} }
revision 2020-05-28 { revision 2020-05-28 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 8782: Distributed Denial-of-Service Open Threat "RFC 8782: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
skipping to change at page 73, line 12 skipping to change at page 74, line 15
type yang:zero-based-counter64; type yang:zero-based-counter64;
units "bytes"; units "bytes";
description description
"The total dropped byte count for the mitigation "The total dropped byte count for the mitigation
request since the attack mitigation was triggered. request since the attack mitigation was triggered.
The count wraps around when it reaches the maximum value The count wraps around when it reaches the maximum value
of counter64 for dropped bytes."; of counter64 for dropped bytes.";
} }
leaf bps-dropped { leaf bps-dropped {
type yang:gauge64; type yang:gauge64;
units "bytes per second";
description description
"The average number of dropped bits per second for "The average number of dropped bytes per second for
the mitigation request since the attack the mitigation request since the attack
mitigation was triggered. This should be over mitigation was triggered. This should be over
five-minute intervals (that is, measuring bytes five-minute intervals (that is, measuring bytes
into five-minute buckets and then averaging these into five-minute buckets and then averaging these
buckets over the time since the mitigation was buckets over the time since the mitigation was
triggered)."; triggered).";
} }
leaf pkts-dropped { leaf pkts-dropped {
type yang:zero-based-counter64; type yang:zero-based-counter64;
description description
"The total number of dropped packet count for the "The total number of dropped packet count for the
mitigation request since the attack mitigation was mitigation request since the attack mitigation was
triggered. The count wraps around when it reaches triggered. The count wraps around when it reaches
the maximum value of counter64 for dropped packets."; the maximum value of counter64 for dropped packets.";
} }
leaf pps-dropped { leaf pps-dropped {
type yang:gauge64; type yang:gauge64;
units "packets per second";
description description
"The average number of dropped packets per second "The average number of dropped packets per second
for the mitigation request since the attack for the mitigation request since the attack
mitigation was triggered. This should be over mitigation was triggered. This should be over
five-minute intervals (that is, measuring packets five-minute intervals (that is, measuring packets
into five-minute buckets and then averaging these into five-minute buckets and then averaging these
buckets over the time since the mitigation was buckets over the time since the mitigation was
triggered)."; triggered).";
} }
} }
case client-to-server-only { case client-to-server-only {
description description
"These data nodes appear only in a mitigation message "These data nodes appear only in a mitigation message
sent from the client to the server."; sent from the client to the server.";
leaf attack-status { leaf attack-status {
type iana-dots-signal:attack-status; type iana-dots-signal:attack-status;
description description
"Indicates the status of an attack as seen by the "Indicates the status of an attack as seen by the
DOTS client. DOTS client.
Ths is is a mandatory attribute when a client This is a mandatory attribute when a client
performs an efficacy update."; performs an efficacy update.";
} }
} }
} }
} }
} }
grouping config-parameters { grouping config-parameters {
description description
"Subset of DOTS signal channel session configuration."; "Subset of DOTS signal channel session configuration.";
skipping to change at page 79, line 40 skipping to change at page 80, line 46
*/ */
sx:structure dots-signal { sx:structure dots-signal {
description description
"Main structure for DOTS signal message. "Main structure for DOTS signal message.
A DOTS signal message can be a mitigation, a configuration, A DOTS signal message can be a mitigation, a configuration,
a redirected, or a heartbeat signal message."; a redirected, or a heartbeat signal message.";
choice message-type { choice message-type {
description description
"Can be a mitigation, a configuration, or a redirect "Can be a mitigation, a configuration, a redirect, or
message."; a heartbeat message.";
case mitigation-scope { case mitigation-scope {
description description
"Mitigation scope of a mitigation message."; "Mitigation scope of a mitigation message.";
uses mitigation-scope; uses mitigation-scope;
} }
case signal-config { case signal-config {
description description
"Configuration message."; "Configuration message.";
uses signal-config; uses signal-config;
} }
skipping to change at page 91, line 36 skipping to change at page 92, line 39
10.1. DOTS Signal Channel UDP and TCP Port Number 10.1. DOTS Signal Channel UDP and TCP Port Number
IANA has assigned the port number 4646 (the ASCII decimal value for IANA has assigned the port number 4646 (the ASCII decimal value for
".." (DOTS)) to the DOTS signal channel protocol for both UDP and TCP ".." (DOTS)) to the DOTS signal channel protocol for both UDP and TCP
from the "Service Name and Transport Protocol Port Number Registry" from the "Service Name and Transport Protocol Port Number Registry"
available at <https://www.iana.org/assignments/service-names-port- available at <https://www.iana.org/assignments/service-names-port-
numbers/>. numbers/>.
IANA is requested to update these entries with the RFC number to be IANA is requested to update these entries with the RFC number to be
assigned to this docuement: assigned to this document:
Service Name: dots-signal Service Name: dots-signal
Port Number: 4646 Port Number: 4646
Transport Protocol: TCP Transport Protocol: TCP
Description: Distributed Denial-of-Service Open Threat Signaling Description: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel (DOTS) Signal Channel
Assignee: IESG Assignee: IESG
Contact: IETF Chair Contact: IETF Chair
Registration Date: 2020-01-16 Registration Date: 2020-01-16
Reference: [RFCXXXX] Reference: [RFCXXXX]
skipping to change at page 92, line 27 skipping to change at page 93, line 27
Transport Protocol: UDP Transport Protocol: UDP
Description: Distributed Denial-of-Service Open Threat Signaling Description: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel (DOTS) Signal Channel
Assignee: IESG Assignee: IESG
Contact: IETF Chair Contact: IETF Chair
Registration Date: 2020-01-16 Registration Date: 2020-01-16
Reference: [RFCXXXX] Reference: [RFCXXXX]
10.2. Well-Known 'dots' URI 10.2. Well-Known 'dots' URI
IANA is requested to update the the 'dots' well-known URI (Table 6) IANA is requested to update the 'dots' well-known URI (Table 6) entry
entry in the Well- Known URIs registry [URI] as follows: in the Well- Known URIs registry [URI] as follows:
+------------+------------+-----------+-----------+-------------+ +------------+------------+-----------+-----------+-------------+
| URI Suffix | Change | Reference | Status | Related | | URI Suffix | Change | Reference | Status | Related |
| | Controller | | | information | | | Controller | | | information |
+============+============+===========+===========+=============+ +============+============+===========+===========+=============+
| dots | IETF | [RFCXXXX] | permanent | None | | dots | IETF | [RFCXXXX] | permanent | None |
+------------+------------+-----------+-----------+-------------+ +------------+------------+-----------+-----------+-------------+
Table 6: 'dots' Well-Known URI Table 6: 'dots' Well-Known URI
skipping to change at page 109, line 22 skipping to change at page 110, line 22
Deployment Considerations for Distributed-Denial-of- Deployment Considerations for Distributed-Denial-of-
Service Open Threat Signaling (DOTS)", draft-ietf-dots- Service Open Threat Signaling (DOTS)", draft-ietf-dots-
multihoming-05 (work in progress), November 2020. multihoming-05 (work in progress), November 2020.
[I-D.ietf-dots-telemetry] [I-D.ietf-dots-telemetry]
Boucadair, M., Reddy, T., Doron, E., Chen, M., and J. Boucadair, M., Reddy, T., Doron, E., Chen, M., and J.
Shallow, "Distributed Denial-of-Service Open Threat Shallow, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15 Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15
(work in progress), December 2020. (work in progress), December 2020.
[I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
L., and K. Nishizuka, "Use cases for DDoS Open Threat
Signaling", draft-ietf-dots-use-cases-25 (work in
progress), July 2020.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-43 (work in progress), April 1.3", draft-ietf-tls-dtls13-43 (work in progress), April
2021. 2021.
[IANA-CBOR-Tags] [IANA-CBOR-Tags]
IANA, "Concise Binary Object Representation (CBOR) Tags", IANA, "Concise Binary Object Representation (CBOR) Tags",
<http://www.iana.org/assignments/cbor-tags/cbor- <https://www.iana.org/assignments/cbor-tags/cbor-
tags.xhtml>. tags.xhtml>.
[IANA-CoAP-Content-Formats] [IANA-CoAP-Content-Formats]
IANA, "CoAP Content-Formats", IANA, "CoAP Content-Formats",
<http://www.iana.org/assignments/core-parameters/core- <https://www.iana.org/assignments/core-parameters/core-
parameters.xhtml#content-formats>. parameters.xhtml#content-formats>.
[IANA-MediaTypes] [IANA-MediaTypes]
IANA, "Media Types", IANA, "Media Types",
<http://www.iana.org/assignments/media-types>. <https://www.iana.org/assignments/media-types>.
[IANA-Proto] [IANA-Proto]
IANA, "Protocol Numbers", 2011, IANA, "Protocol Numbers", 2011,
<http://www.iana.org/assignments/protocol-numbers>. <https://www.iana.org/assignments/protocol-numbers>.
[REG-DOTS] [REG-DOTS]
IANA, "Distributed Denial-of-Service Open Threat Signaling IANA, "Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel", (DOTS) Signal Channel",
<https://www.iana.org/assignments/dots/dots.xhtml>. <https://www.iana.org/assignments/dots/dots.xhtml>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001, DOI 10.17487/RFC3022, January 2001,
<https://www.rfc-editor.org/info/rfc3022>. <https://www.rfc-editor.org/info/rfc3022>.
skipping to change at page 113, line 10 skipping to change at page 114, line 5
Mortensen, A., and N. Teague, "Distributed Denial-of- Mortensen, A., and N. Teague, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel Service Open Threat Signaling (DOTS) Signal Channel
Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020,
<https://www.rfc-editor.org/info/rfc8782>. <https://www.rfc-editor.org/info/rfc8782>.
[RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., [RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F.,
Teague, N., and R. Compton, "DDoS Open Threat Signaling Teague, N., and R. Compton, "DDoS Open Threat Signaling
(DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811,
August 2020, <https://www.rfc-editor.org/info/rfc8811>. August 2020, <https://www.rfc-editor.org/info/rfc8811>.
[RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
L., and K. Nishizuka, "Use Cases for DDoS Open Threat
Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021,
<https://www.rfc-editor.org/info/rfc8903>.
[RFC8973] Boucadair, M. and T. Reddy.K, "DDoS Open Threat Signaling [RFC8973] Boucadair, M. and T. Reddy.K, "DDoS Open Threat Signaling
(DOTS) Agent Discovery", RFC 8973, DOI 10.17487/RFC8973, (DOTS) Agent Discovery", RFC 8973, DOI 10.17487/RFC8973,
January 2021, <https://www.rfc-editor.org/info/rfc8973>. January 2021, <https://www.rfc-editor.org/info/rfc8973>.
[URI] IANA, "Well-Known URIs", [URI] IANA, "Well-Known URIs",
<https://www.iana.org/assignments/well-known-uris/well- <https://www.iana.org/assignments/well-known-uris/well-
known-uris.xhtml>. known-uris.xhtml>.
Appendix A. Summary of Changes From RFC8782 Appendix A. Summary of Changes From RFC8782
skipping to change at page 114, line 10 skipping to change at page 115, line 10
o Update the IANA section to allocate a new range for comprehension- o Update the IANA section to allocate a new range for comprehension-
optional attributes (Section 10.6.1.1). This modification is optional attributes (Section 10.6.1.1). This modification is
motivated by the need to allow for compact DOTS signal messages motivated by the need to allow for compact DOTS signal messages
that include a long list of comprehension-optional attributes, that include a long list of comprehension-optional attributes,
e.g., DOTS telemetry messages [I-D.ietf-dots-telemetry]. e.g., DOTS telemetry messages [I-D.ietf-dots-telemetry].
o Add Appendix C to list recommended/default values of key DOTS o Add Appendix C to list recommended/default values of key DOTS
signal channel parameters. signal channel parameters.
o Add subsections to Section 4.4.1 for better readability.
Appendix B. CUID Generation Appendix B. CUID Generation
The document recommends the use of SPKI to generate the 'cuid'. This The document recommends the use of SPKI to generate the 'cuid'. This
design choice is motivated by the following reasons: design choice is motivated by the following reasons:
o SPKI is globally unique. o SPKI is globally unique.
o It is deterministic. o It is deterministic.
o It allows the avoidance of extra cycles that may be induced by o It allows the avoidance of extra cycles that may be induced by
skipping to change at page 115, line 17 skipping to change at page 116, line 17
Many thanks to Martin Bjoerklund for the suggestion to use RFC8791. Many thanks to Martin Bjoerklund for the suggestion to use RFC8791.
Thanks to Valery Smyslov for the comments, guidance, and support. Thanks to Valery Smyslov for the comments, guidance, and support.
Thanks to Ebben Aries for the yangdoctors review, Dan Romascanu for Thanks to Ebben Aries for the yangdoctors review, Dan Romascanu for
the opsdir review, Michael Tuexen for the tsv-art review, Dale Worley the opsdir review, Michael Tuexen for the tsv-art review, Dale Worley
for the genart review, and Donald Eastlake for the secdir review. for the genart review, and Donald Eastlake for the secdir review.
Thanks to Benjamin Kaduk for the AD review. Thanks to Benjamin Kaduk for the AD review.
Thanks to Martin Duke, Lars Eggert, Erik Kline, Murray Kucherawy,
Eric Vyncke, and Robert Wilton for the IESG review.
D.1. Acknowledgements from RFC8782 D.1. Acknowledgements from RFC8782
Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, Michael Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, Michael
Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang Xia, Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang Xia,
Gilbert Clark, Xialiang Frank, Jim Schaad, Klaus Hartke, Nesredien Gilbert Clark, Xialiang Frank, Jim Schaad, Klaus Hartke, Nesredien
Suleiman, Stephen Farrell, and Yoshifumi Nishida for the discussion Suleiman, Stephen Farrell, and Yoshifumi Nishida for the discussion
and comments. and comments.
The authors would like to give special thanks to Kaname Nishizuka and The authors would like to give special thanks to Kaname Nishizuka and
Jon Shallow for their efforts in implementing the protocol and Jon Shallow for their efforts in implementing the protocol and
 End of changes. 44 change blocks. 
122 lines changed or deleted 139 lines changed or added

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