< draft-ietf-dots-signal-channel-34.txt   draft-ietf-dots-signal-channel-35.txt >
DOTS T. Reddy, Ed. DOTS T. Reddy, Ed.
Internet-Draft McAfee Internet-Draft McAfee
Intended status: Standards Track M. Boucadair, Ed. Intended status: Standards Track M. Boucadair, Ed.
Expires: November 17, 2019 Orange Expires: January 4, 2020 Orange
P. Patil P. Patil
Cisco Cisco
A. Mortensen A. Mortensen
Arbor Networks, Inc. Arbor Networks, Inc.
N. Teague N. Teague
Iron Mountain Data Centers Iron Mountain Data Centers
May 16, 2019 July 3, 2019
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-signal-channel-34 draft-ietf-dots-signal-channel-35
Abstract Abstract
This document specifies the DOTS signal channel, a protocol for This document specifies the DOTS signal channel, a protocol for
signaling the need for protection against Distributed Denial-of- signaling the need for protection against Distributed Denial-of-
Service (DDoS) attacks to a server capable of enabling network Service (DDoS) attacks to a server capable of enabling network
traffic mitigation on behalf of the requesting client. traffic mitigation on behalf of the requesting client.
A companion document defines the DOTS data channel, a separate A companion document defines the DOTS data channel, a separate
reliable communication layer for DOTS management and configuration reliable communication layer for DOTS management and configuration
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 17, 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 2, line 49 skipping to change at page 2, line 49
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6
4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 9 4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 9
4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 9 4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 9
4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 10 4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 10
4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 12 4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 12
4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 13 4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 13
4.4.2. Retrieve Information Related to a Mitigation . . . . 29 4.4.2. Retrieve Information Related to a Mitigation . . . . 29
4.4.2.1. DOTS Servers Sending Mitigation Status . . . . . 34 4.4.2.1. DOTS Servers Sending Mitigation Status . . . . . 34
4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 37 4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 37
4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 38 4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 38
4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 40 4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 40
4.5. DOTS Signal Channel Session Configuration . . . . . . . . 41 4.5. DOTS Signal Channel Session Configuration . . . . . . . . 41
4.5.1. Discover Configuration Parameters . . . . . . . . . . 43 4.5.1. Discover Configuration Parameters . . . . . . . . . . 43
skipping to change at page 3, line 26 skipping to change at page 3, line 26
5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 57 5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 57
5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 58 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 58
5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 60 5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 60
5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 64 5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 64
6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 74 6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 74
7. (D)TLS Protocol Profile and Performance Considerations . . . 76 7. (D)TLS Protocol Profile and Performance Considerations . . . 76
7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 76 7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 76
7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 78 7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 78
7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 80 7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 80
8. Mutual Authentication of DOTS Agents & Authorization of DOTS 8. Mutual Authentication of DOTS Agents & Authorization of DOTS
Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83
9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 82 9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 83
9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 82 9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 83
9.3. Media Type Registration . . . . . . . . . . . . . . . . . 82 9.3. Media Type Registration . . . . . . . . . . . . . . . . . 83
9.4. CoAP Content-Formats Registration . . . . . . . . . . . . 83 9.4. CoAP Content-Formats Registration . . . . . . . . . . . . 84
9.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 83 9.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 84
9.6. DOTS Signal Channel Protocol Registry . . . . . . . . . . 84 9.6. DOTS Signal Channel Protocol Registry . . . . . . . . . . 85
9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry . . 84 9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry . . 85
9.6.1.1. Registration Template . . . . . . . . . . . . . . 84 9.6.1.1. Registration Template . . . . . . . . . . . . . . 85
9.6.1.2. Initial Sub-Registry Content . . . . . . . . . . 85 9.6.1.2. Initial Sub-Registry Content . . . . . . . . . . 86
9.6.2. Status Codes Sub-Registry . . . . . . . . . . . . . . 87 9.6.2. Status Codes Sub-Registry . . . . . . . . . . . . . . 88
9.6.3. Conflict Status Codes Sub-Registry . . . . . . . . . 88 9.6.3. Conflict Status Codes Sub-Registry . . . . . . . . . 89
9.6.4. Conflict Cause Codes Sub-Registry . . . . . . . . . . 90 9.6.4. Conflict Cause Codes Sub-Registry . . . . . . . . . . 91
9.6.5. Attack Status Codes Sub-Registry . . . . . . . . . . 90 9.6.5. Attack Status Codes Sub-Registry . . . . . . . . . . 91
9.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 91 9.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 92
10. Security Considerations . . . . . . . . . . . . . . . . . . . 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 93
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 94 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 95
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 95 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 96
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 95 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 96
13.1. Normative References . . . . . . . . . . . . . . . . . . 95 13.1. Normative References . . . . . . . . . . . . . . . . . . 96
13.2. Informative References . . . . . . . . . . . . . . . . . 98 13.2. Informative References . . . . . . . . . . . . . . . . . 99
Appendix A. CUID Generation . . . . . . . . . . . . . . . . . . 103 Appendix A. CUID Generation . . . . . . . . . . . . . . . . . . 104
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 104
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 45 skipping to change at page 4, line 45
In many cases, it may not be possible for network administrators to In many cases, it may not be possible for network administrators to
determine the cause(s) of an attack. They may instead just realize determine the cause(s) of an attack. They may instead just realize
that certain resources seem to be under attack. This document that certain resources seem to be under attack. This document
defines a lightweight protocol that allows a DOTS client to request defines a lightweight protocol that allows a DOTS client to request
mitigation from one or more DOTS servers for protection against mitigation from one or more DOTS servers for protection against
detected, suspected, or anticipated attacks. This protocol enables detected, suspected, or anticipated attacks. This protocol enables
cooperation between DOTS agents to permit a highly-automated network cooperation between DOTS agents to permit a highly-automated network
defense that is robust, reliable, and secure. Note that "secure" defense that is robust, reliable, and secure. Note that "secure"
means the support of the features defined in Section 2.4 of means the support of the features defined in Section 2.4 of
[I-D.ietf-dots-requirements]. [RFC8612].
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 __________
+-----------+ +--------------+ +-------------+ / \ +-----------+ +--------------+ +-------------+ / \
skipping to change at page 5, line 44 skipping to change at page 5, line 44
provide connectivity services to the network hosting the DOTS client. provide connectivity services to the network hosting the DOTS client.
The DOTS server may (not) be co-located with the DOTS mitigator. In The DOTS server may (not) be co-located with the DOTS mitigator. In
typical deployments, the DOTS server belongs to the same typical deployments, the DOTS server belongs to the 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.
The document adheres to the DOTS architecture The document adheres to the DOTS architecture
[I-D.ietf-dots-architecture]. The requirements for DOTS signal [I-D.ietf-dots-architecture]. The requirements for DOTS signal
channel protocol are documented in [I-D.ietf-dots-requirements]. channel protocol are documented in [RFC8612]. This document
This document satisfies all the use cases discussed in satisfies all the use cases discussed in [I-D.ietf-dots-use-cases].
[I-D.ietf-dots-use-cases].
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 companion document of the DOTS data channel specification
[I-D.ietf-dots-data-channel] that defines a configuration and a bulk [I-D.ietf-dots-data-channel] that defines a configuration and a bulk
data exchange mechanism supporting the DOTS signal channel. data exchange mechanism supporting the DOTS signal channel.
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 BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
(D)TLS is used for statements that apply to both Transport Layer (D)TLS is used for statements that apply to both Transport Layer
Security [RFC5246][RFC8446] and Datagram Transport Layer Security Security [RFC5246][RFC8446] and Datagram Transport Layer Security
[RFC6347]. Specific terms are used for any statement that applies to [RFC6347]. Specific terms are used for any statement that applies to
either protocol alone. either protocol alone.
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 meaning of the symbols in YANG tree diagrams is defined in The meaning of the symbols in YANG tree diagrams is defined in
[RFC8340]. [RFC8340].
3. Design Overview 3. Design Overview
The DOTS signal channel is built on top of the Constrained The DOTS signal channel is built on top of the Constrained
Application Protocol (CoAP) [RFC7252], a lightweight protocol Application Protocol (CoAP) [RFC7252], a lightweight protocol
originally designed for constrained devices and networks. The many originally designed for constrained devices and networks. The many
features of CoAP (expectation of packet loss, support for features of CoAP (expectation of packet loss, support for
skipping to change at page 7, line 12 skipping to change at page 7, line 9
Figure 3: Abstract Layering of DOTS Signal Channel over CoAP over Figure 3: Abstract Layering of DOTS Signal Channel over CoAP over
(D)TLS (D)TLS
In some cases, a DOTS client and server may have mutual agreement to In some cases, a DOTS client and server may have mutual agreement to
use a specific port number, such as by explicit configuration or use a specific port number, such as by explicit configuration or
dynamic discovery [I-D.ietf-dots-server-discovery]. Absent such dynamic discovery [I-D.ietf-dots-server-discovery]. Absent such
mutual agreement, the DOTS signal channel MUST run over port number mutual agreement, the DOTS signal channel MUST run over port number
TBD as defined in Section 9.1, for both UDP and TCP. In order to use TBD as defined in Section 9.1, for both UDP and TCP. In order to use
a distinct port number (as opposed to TBD), DOTS clients and servers a distinct port number (as opposed to TBD), DOTS clients and servers
SHOULD support a configurable parameter to supply the port number to SHOULD support a configurable parameter to supply the port number to
use. The rationale for not using the default port number 5684 use.
((D)TLS CoAP) is to allow for differentiated behaviors in
environments where both a DOTS gateway and an IoT gateway (e.g., Note: The rationale for not using the default port number 5684
Figure 3 of [RFC7452]) are present. ((D)TLS CoAP) is to avoid the discovery of services and resources
discussed in [RFC7252] and allow for differentiated behaviors in
environments where both a DOTS gateway and an IoT gateway (e.g.,
Figure 3 of [RFC7452]) are co-located.
Particularly, the use of a default port number is meant to
simplify DOTS deployment in scenarios where no explicit IP address
configuration is required. For example, the use of the default
router as DOTS server aims to ease DOTS deployment within LANs (in
which, CPEs embed a DOTS gateway as illustrated in Figures 1 and
2) without requiring a sophisticated discovery method and
configuration tasks within the LAN. The use of anycast is meant
to simplify DOTS client configuration, including service
discovery. In such anycast-based scenario, a DOTS client
initiating a DOTS session to the DOTS server anycast address may,
for example, be (1) redirected to the DOTS server unicast address
to be used by the DOTS client following the procedure discussed in
Section 4.6 or (2) relayed to a unicast DOTS server.
The signal channel uses the "coaps" URI scheme defined in Section 6 The signal channel uses the "coaps" URI scheme defined in Section 6
of [RFC7252] and the "coaps+tcp" URI scheme defined in Section 8.2 of of [RFC7252] and the "coaps+tcp" URI scheme defined in Section 8.2 of
[RFC8323] to identify DOTS server resources accessible using CoAP [RFC8323] to identify DOTS server resources accessible using CoAP
over UDP secured with DTLS and CoAP over TCP secured with TLS, over UDP secured with DTLS and CoAP over TCP secured with TLS,
respectively. respectively.
The DOTS signal channel can be established between two DOTS agents The DOTS signal channel can be established between two DOTS agents
prior or during an attack. The DOTS signal channel is initiated by prior or during an attack. The DOTS signal channel is initiated by
the DOTS client. The DOTS client can then negotiate, configure, and the DOTS client. The DOTS client can then negotiate, configure, and
retrieve the DOTS signal channel session behavior with its DOTS peer retrieve the DOTS signal channel session behavior with its DOTS peer
(Section 4.5). Once the signal channel is established, the DOTS (Section 4.5). Once the signal channel is established, the DOTS
agents periodically send heartbeats to keep the channel active agents may periodically send heartbeats to keep the channel active
(Section 4.7). At any time, the DOTS client may send a mitigation (Section 4.7). At any time, the DOTS client may send a mitigation
request message (Section 4.4) to a DOTS server over the active signal request message (Section 4.4) to a DOTS server over the active signal
channel. While mitigation is active (because of the higher channel. While mitigation is active (because of the higher
likelihood of packet loss during a DDoS attack), the DOTS server likelihood of packet loss during a DDoS attack), the DOTS server
periodically sends status messages to the client, including basic periodically sends status messages to the client, including basic
mitigation feedback details. Mitigation remains active until the mitigation feedback details. Mitigation remains active until the
DOTS client explicitly terminates mitigation, or the mitigation DOTS client explicitly terminates mitigation, or the mitigation
lifetime expires. Also, the DOTS server may rely on the signal lifetime expires. Also, the DOTS server may rely on the signal
channel session loss to trigger mitigation for pre-configured channel session loss to trigger mitigation for pre-configured
mitigation requests (if any). mitigation requests (if any).
skipping to change at page 10, line 17 skipping to change at page 10, line 26
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
| Mitigation | /mitigate | Section 4.4 | | Mitigation | /mitigate | Section 4.4 |
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
| Session configuration | /config | Section 4.5 | | Session configuration | /config | Section 4.5 |
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
Table 1: Operations and their Corresponding URIs Table 1: Operations and their Corresponding URIs
4.3. Happy Eyeballs for DOTS Signal Channel 4.3. Happy Eyeballs for DOTS Signal Channel
[I-D.ietf-dots-requirements] mentions that DOTS agents will have to [RFC8612] mentions that DOTS agents will have to support both
support both connectionless and connection-oriented protocols. As connectionless and connection-oriented protocols. As such, the DOTS
such, the DOTS signal channel is designed to operate with DTLS over signal channel is designed to operate with DTLS over UDP and TLS over
UDP and TLS over TCP. Further, a DOTS client may acquire a list of TCP. Further, a DOTS client may acquire a list of IPv4 and IPv6
IPv4 and IPv6 addresses (Section 4.1), each of which can be used to addresses (Section 4.1), each of which can be used to contact the
contact the DOTS server using UDP and TCP. The following specifies DOTS server using UDP and TCP. If no list of IPv4 and IPv6 addresses
the procedure to follow to select the address family and the to contact the DOTS server is configured (or discovered), the DOTS
transport protocol for sending DOTS signal channel messages. client adds the IPv4/IPv6 addresses of its default router to the
candidate list to contact the DOTS server.
The following specifies the procedure to follow to select the address
family and the transport protocol for sending DOTS signal channel
messages.
Such procedure is needed to avoid experiencing long connection Such procedure is needed to avoid experiencing long connection
delays. For example, if an IPv4 path to reach a DOTS server is delays. For example, if an IPv4 path to reach a DOTS server is
functional, but the DOTS server's IPv6 path is non-functional, a functional, but the DOTS server's IPv6 path is non-functional, a
dual-stack DOTS client may experience a significant connection delay dual-stack DOTS client may experience a significant connection delay
compared to an IPv4-only DOTS client, in the same network conditions. compared to an IPv4-only DOTS client, in the same network conditions.
The other problem is that if a middlebox between the DOTS client and The other problem is that if a middlebox between the DOTS client and
DOTS server is configured to block UDP traffic, the DOTS client will DOTS server is configured to block UDP traffic, the DOTS client will
fail to establish a DTLS association with the DOTS server and, as a fail to establish a DTLS association with the DOTS server and, as a
consequence, will have to fall back to TLS over TCP, thereby consequence, will have to fall back to TLS over TCP, thereby
skipping to change at page 11, line 4 skipping to change at page 11, line 18
it has to select an address family and transport to contact its DOTS it has to select an address family and transport to contact its DOTS
server. The results of the Happy Eyeballs procedure are used by the server. The results of the Happy Eyeballs procedure are used by the
DOTS client for sending its subsequent messages to the DOTS server. DOTS client for sending its subsequent messages to the DOTS server.
The difference in behavior with respect to the Happy Eyeballs The difference in behavior with respect to the Happy Eyeballs
mechanism [RFC8305] are listed below: mechanism [RFC8305] are listed below:
o The order of preference of the DOTS signal channel address family o The order of preference of the DOTS signal channel address family
and transport protocol (most preferred first) is: UDP over IPv6, and transport protocol (most preferred first) is: UDP over IPv6,
UDP over IPv4, TCP over IPv6, and finally TCP over IPv4. This UDP over IPv4, TCP over IPv6, and finally TCP over IPv4. This
order adheres to the address preference order specified in order adheres to the address preference order specified in
[RFC6724] and the DOTS signal channel preference which privileges [RFC6724] and the DOTS signal channel preference which privileges
the use of UDP over TCP (to avoid TCP's head of line blocking). the use of UDP over TCP (to avoid TCP's head of line blocking).
o The DOTS client after successfully establishing a connection MUST o The DOTS client after successfully establishing a connection MUST
cache information regarding the outcome of each connection attempt cache information regarding the outcome of each connection attempt
for a specific time period, and it uses that information to avoid for a specific time period, and it uses that information to avoid
thrashing the network with subsequent attempts. The cached thrashing the network with subsequent attempts. The cached
information is flushed when its age exceeds a specific time period information is flushed when its age exceeds a specific time period
on the order of few minutes (e.g., 10 mn). Typically, if the DOTS on the order of few minutes (e.g., 10 min). Typically, if the
client has to re-establish the connection with the same DOTS DOTS client has to re-establish the connection with the same DOTS
server within few seconds after the Happy Eyeballs mechanism is server within few seconds after the Happy Eyeballs mechanism is
completed, caching avoids trashing the network especially in the completed, caching avoids trashing the network especially in the
presence of DDoS attack traffic. presence of DDoS attack traffic.
o If DOTS signal channel session is established with TLS (but DTLS o If DOTS signal channel session is established with TLS (but DTLS
failed), the DOTS client periodically repeats the mechanism to failed), the DOTS client periodically repeats the mechanism to
discover whether DOTS signal channel messages with DTLS over UDP discover whether DOTS signal channel messages with DTLS over UDP
becomes available from the DOTS server, so the DOTS client can becomes available from the DOTS server, so the DOTS client can
migrate the DOTS signal channel from TCP to UDP. Such probing migrate the DOTS signal channel from TCP to UDP. Such probing
SHOULD NOT be done more frequently than every 24 hours and MUST SHOULD NOT be done more frequently than every 24 hours and MUST
skipping to change at page 12, line 49 skipping to change at page 12, line 49
GET: DOTS clients may use the GET method to subscribe to DOTS GET: DOTS clients may use the GET method to subscribe to DOTS
server status messages, or to retrieve the list of its server status messages, or to retrieve the list of its
mitigations maintained by a DOTS server (Section 4.4.2). mitigations maintained by a DOTS server (Section 4.4.2).
DELETE: DOTS clients use the DELETE method to withdraw a request for DELETE: DOTS clients use the DELETE method to withdraw a request for
mitigation from a DOTS server (Section 4.4.4). mitigation from a DOTS server (Section 4.4.4).
Mitigation request and response messages are marked as Non- Mitigation request and response messages are marked as Non-
confirmable messages (Section 2.2 of [RFC7252]). confirmable messages (Section 2.2 of [RFC7252]).
DOTS agents MUST follow the data transmission guidelines discussed in DOTS agents MUST NOT send more than one UDP datagram per round-trip
Section 3.1.3 of [RFC8085] and control transmission behavior by not time (RTT) to the peer DOTS agent on average following the data
sending more than one UDP datagram per round-trip time (RTT) to the transmission guidelines discussed in Section 3.1.3 of [RFC8085].
peer DOTS agent on average.
Requests marked by the DOTS client as Non-confirmable messages are Requests marked by the DOTS client as Non-confirmable messages are
sent at regular intervals until a response is received from the DOTS sent at regular intervals until a response is received from the DOTS
server. If the DOTS client cannot maintain an RTT estimate, it MUST server. If the DOTS client cannot maintain an RTT estimate, it MUST
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]). Section 3.1.3 of [RFC8085]).
JSON encoding of YANG modelled data [RFC7951] is used to illustrate JSON encoding of YANG modelled data [RFC7951] is used to illustrate
the various methods defined in the following sub-sections. Also, the the various methods defined in the following sub-sections. Also, the
skipping to change at page 14, line 6 skipping to change at page 14, line 6
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 A, implementations SHOULD
set 'cuid' to the output of a cryptographic hash algorithm set 'cuid' using the following procedure: first, the
whose input is the Distinguished Encoding Rules (DER)-encoded Distinguished Encoding Rules (DER)-encoded Abstract Syntax
Abstract Syntax Notation One (ASN.1) representation of the Notation One (ASN.1) representation of the Subject Public Key
Subject Public Key Info (SPKI) of the DOTS client X.509 Info (SPKI) of the DOTS client X.509 certificate [RFC5280], the
certificate [RFC5280], the DOTS client raw public key DOTS client raw public key [RFC7250], or the "Pre-Shared Key
[RFC7250], or the "Pre-Shared Key (PSK) identity" used by the (PSK) identity" used by the DOTS client in the TLS
DOTS client in the TLS ClientKeyExchange message. In this ClientKeyExchange message is input to the SHA-256 [RFC6234]
version of the specification, the cryptographic hash algorithm cryptographic hash. Then, the output of the cryptographic hash
used is SHA-256 [RFC6234]. The output of the cryptographic algorithm is truncated to 16 bytes; truncation is done by
hash 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
base64url encoded (Section 5 of [RFC4648]) with the trailing base64url encoded (Section 5 of [RFC4648]) with the trailing
"=" removed from the encoding. "=" removed from the encoding, and the resulting value used as
the 'cuid'.
The 'cuid' is intended to be stable when communicating with a The 'cuid' is intended to be stable when communicating with a
given DOTS server, i.e., the 'cuid' used by a DOTS client given DOTS server, i.e., the 'cuid' used by a DOTS client
SHOULD NOT change over time. Distinct 'cuid' values MAY be SHOULD NOT change over time. Distinct 'cuid' values MAY be
used by a single DOTS client per DOTS server. used by a single DOTS client per DOTS server.
If a DOTS client has to change its 'cuid' for some reason, it If a DOTS client has to change its 'cuid' for some reason, it
MUST NOT do so when mitigations are still active for the old MUST NOT do so when mitigations are still active for the old
'cuid'. The 'cuid' SHOULD be 22 characters to avoid DOTS 'cuid'. The 'cuid' SHOULD be 22 characters to avoid DOTS
signal message fragmentation over UDP. Furthermore, if that signal message fragmentation over UDP. Furthermore, if that
skipping to change at page 26, line 9 skipping to change at page 26, line 9
mitigation' set to false. Particularly, if the mitigation request mitigation' set to false. Particularly, if the mitigation request
with 'trigger-mitigation' set to false is active, the DOTS server with 'trigger-mitigation' set to false is active, the DOTS server
withdraws the mitigation request (i.e., status code is set to '7' as withdraws the mitigation request (i.e., status code is set to '7' as
defined in Table 2) and transitions the status of the mitigation defined in Table 2) and transitions the status of the mitigation
request to '8'. request to '8'.
Upon DOTS signal channel session loss with a peer DOTS client, the Upon DOTS signal channel session loss with a peer DOTS client, the
DOTS server SHOULD withdraw (absent explicit policy/configuration DOTS server SHOULD withdraw (absent explicit policy/configuration
otherwise) any active mitigation requests overlapping with mitigation otherwise) any active mitigation requests overlapping with mitigation
requests having 'trigger-mitigation' set to false from that DOTS requests having 'trigger-mitigation' set to false from that DOTS
client, as the loss of the session implictily activates these client, as the loss of the session implicitly activates these
preconfigured mitigation requests and they take precedence. Note preconfigured mitigation requests and they take precedence. Note
that active-but-terminating period is not observed for mitigations that active-but-terminating period is not observed for mitigations
withdrawn at the initiative of the DOTS server. withdrawn at the initiative of the DOTS server.
DOTS clients may adopt various strategies for setting the scopes of DOTS clients may adopt various strategies for setting the scopes of
immediate and pre-configured mitigation requests to avoid potential immediate and pre-configured mitigation requests to avoid potential
conflicts. For example, a DOTS client may tweak pre-configured conflicts. For example, a DOTS client may tweak pre-configured
scopes so that the scope of any overlapping immediate mitigation scopes so that the scope of any overlapping immediate mitigation
request will be a subset of the pre-configured scopes. Also, if an request will be a subset of the pre-configured scopes. Also, if an
immediate mitigation request overlaps with any of the pre-configured immediate mitigation request overlaps with any of the pre-configured
skipping to change at page 27, line 49 skipping to change at page 27, line 49
request is deactivated. Any retransmission of the same request is deactivated. Any retransmission of the same
mitigation request before the expiry of this timer is likely to mitigation request before the expiry of this timer is likely to
be rejected by the DOTS server for the same reasons. be rejected by the DOTS server for the same reasons.
The retry-timer SHOULD be equal to the lifetime of the active The retry-timer SHOULD be equal to the lifetime of the active
mitigation request resulting in the deactivation of the mitigation request resulting in the deactivation of the
conflicting mitigation request. conflicting mitigation request.
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) so that the DOTS client can refresh the + 45 seconds' (that is, this mitigation request remains
deactivated mitigation request after 'retry-timer' seconds, but deactivated for the entire duration of 'retry-timer + 45
before the expiry of the lifetime, and check if the conflict is seconds') so that the DOTS client can refresh the deactivated
resolved. mitigation request after 'retry-timer' seconds, but before the
expiry of the lifetime, and check if the conflict is resolved.
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=7eeaf349529eb55ed50113"
Uri-Path: "mid=12" Uri-Path: "mid=12"
(1) Request with a conflicting 'cuid' (1) Request with a conflicting 'cuid'
skipping to change at page 35, line 21 skipping to change at page 35, line 21
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 DOTS server server for each notification individually. For 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. in a Confirmable message. This overrides the behavior defined in
Section 4.5 of [RFC7641] to send a Confirmable message instead of a
Non-confirmable message at least every 24 hour for the following
reasons: First, the DOTS signal channel uses a heartbeat mechanism to
determine if the DOTS client is alive. Second, Confirmable messages
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
attack mitigation changes. If the DOTS server cannot maintain an RTT attack mitigation changes. If the DOTS server cannot maintain an RTT
estimate, it MUST NOT send more than one asynchronous notification estimate, it MUST NOT send more than one asynchronous notification
every 3 seconds, and SHOULD use an even less aggressive rate whenever every 3 seconds, and SHOULD use an even less aggressive rate whenever
possible (case 2 in Section 3.1.3 of [RFC8085]). possible (case 2 in Section 3.1.3 of [RFC8085]).
When conflicting requests are detected, the DOTS server enforces the When conflicting requests are detected, the DOTS server enforces the
skipping to change at page 37, line 42 skipping to change at page 37, line 42
... ...
Figure 15: Notifications of Attack Mitigation Status Figure 15: Notifications of Attack Mitigation Status
4.4.2.2. DOTS Clients Polling for Mitigation Status 4.4.2.2. DOTS Clients Polling for Mitigation Status
The DOTS client can send the GET request at frequent intervals The DOTS client can send the GET request at frequent intervals
without the Observe Option to retrieve the configuration data of the without the Observe Option to retrieve the configuration data of the
mitigation request and non-configuration data (i.e., the attack mitigation request and non-configuration data (i.e., the attack
status). DOTS clients MAY be configured with a policy indicating the status). DOTS clients MAY be configured with a policy indicating the
frequency of polling DOTS servers to get the mitigation status. frequency of polling DOTS servers to get the mitigation status. This
Absent such policy, the frequency of polling the DOTS server to get frequency MUST NOT be more than one UDP datagram per RTT as discussed
the mitigation status SHOULD follow the transmission guidelines in in Section 3.1.3 of [RFC8085].
Section 3.1.3 of [RFC8085].
If the DOTS server has been able to mitigate the attack and the If the DOTS server has been able to mitigate the attack and the
attack has stopped, the DOTS server indicates as such in the status. attack has stopped, the DOTS server indicates as such in the status.
In such case, the DOTS client recalls the mitigation request by In such case, the DOTS client recalls the mitigation request by
issuing a DELETE request for this mitigation request (Section 4.4.4). issuing a DELETE request for this mitigation request (Section 4.4.4).
A DOTS client SHOULD react to the status of the attack as per the A DOTS client SHOULD react to the status of the attack as per the
information sent by the DOTS server rather than performing its own information sent by the DOTS server rather than performing its own
detection that the attack has been mitigated. This ensures that the detection that the attack has been mitigated. This ensures that the
DOTS client does not recall a mitigation request prematurely because DOTS client does not recall a mitigation request prematurely because
skipping to change at page 47, line 22 skipping to change at page 47, line 22
parameters for the signal channel (e.g., heartbeat interval, maximum parameters for the signal channel (e.g., heartbeat interval, maximum
retransmissions). Message transmission parameters for CoAP are retransmissions). Message transmission parameters for CoAP are
defined in Section 4.8 of [RFC7252]. The RECOMMENDED values of defined in Section 4.8 of [RFC7252]. The RECOMMENDED values of
transmission parameter values are ack-timeout (2 seconds), max- transmission parameter values are ack-timeout (2 seconds), max-
retransmit (3), ack-random-factor (1.5). In addition to those retransmit (3), ack-random-factor (1.5). In addition to those
parameters, the RECOMMENDED specific DOTS transmission parameter parameters, the RECOMMENDED specific DOTS transmission parameter
values are 'heartbeat-interval' (30 seconds) and 'missing-hb-allowed' values are 'heartbeat-interval' (30 seconds) and 'missing-hb-allowed'
(5). (5).
Note: heartbeat-interval should be tweaked to also assist DOTS Note: heartbeat-interval should be tweaked to also assist DOTS
messages for NAT traversal (SIG-011 of messages for NAT traversal (SIG-011 of [RFC8612]). According to
[I-D.ietf-dots-requirements]). According to [RFC8085], keepalive [RFC8085], keepalive messages must not be sent more frequently
messages must not be sent more frequently than once every 15 than once every 15 seconds and should use longer intervals when
seconds and should use longer intervals when possible. possible. Furthermore, [RFC4787] recommends NATs to use a state
Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 timeout of 2 minutes or longer, but experience shows that sending
minutes or longer, but experience shows that sending packets every packets every 15 to 30 seconds is necessary to prevent the
15 to 30 seconds is necessary to prevent the majority of majority of middleboxes from losing state for UDP flows. From
middleboxes from losing state for UDP flows. From that that standpoint, the RECOMMENDED minimum heartbeat-interval is 15
standpoint, the RECOMMENDED minimum heartbeat-interval is 15
seconds and the RECOMMENDED maximum heartbeat-interval is 240 seconds and the RECOMMENDED maximum heartbeat-interval is 240
seconds. The recommended value of 30 seconds is selected to seconds. The recommended value of 30 seconds is selected to
anticipate the expiry of NAT state. anticipate the expiry of NAT state.
A heartbeat-interval of 30 seconds may be considered as too chatty A heartbeat-interval of 30 seconds may be considered as too chatty
in some deployments. For such deployments, DOTS agents may in some deployments. For such deployments, DOTS agents may
negotiate longer heartbeat-interval values to prevent any network negotiate longer heartbeat-interval values to prevent any network
overload with too frequent keepalives. overload with too frequent keepalives.
Different heartbeat intervals can be defined for 'mitigating- Different heartbeat intervals can be defined for 'mitigating-
skipping to change at page 74, line 29 skipping to change at page 74, line 29
<CODE ENDS> <CODE ENDS>
6. YANG/JSON Mapping Parameters to CBOR 6. YANG/JSON Mapping Parameters to CBOR
All parameters in the payload of the DOTS signal channel MUST be All parameters in the payload of the DOTS signal channel MUST be
mapped to CBOR types as shown in Table 4 and are assigned an integer mapped to CBOR types as shown in Table 4 and are assigned an integer
key to save space. key to save space.
o Note: Implementers must check that the mapping output provided by o Note: Implementers must check that the mapping output provided by
their YANG-to-CBOR encoding schemes is aligned with the content of their YANG-to-CBOR encoding schemes is aligned with the content of
Table 4. Table 4. For example, some CBOR and JSON types for enumerations
and the 64-bit quantities can differ depending on the encoder
used.
The CBOR key values are divided into two types: comprehension- The CBOR key values are divided into two types: comprehension-
required and comprehension-optional. DOTS agents can safely ignore required and comprehension-optional. DOTS agents can safely ignore
comprehension-optional values they don't understand, but cannot comprehension-optional values they don't understand, but cannot
successfully process a request if it contains comprehension-required successfully process a request if it contains comprehension-required
values that are not understood. The 4.00 response SHOULD include a values that are not understood. The 4.00 response SHOULD include a
diagnostic payload describing the unknown comprehension-required CBOR diagnostic payload describing the unknown comprehension-required CBOR
key values. The initial set of CBOR key values defined in this key values. The initial set of CBOR key values defined in this
specification are of type comprehension-required. specification are of type comprehension-required.
skipping to change at page 80, line 9 skipping to change at page 80, line 29
() Indicates messages protected 0-RTT keys () Indicates messages protected 0-RTT keys
{} Indicates messages protected using handshake keys {} Indicates messages protected using handshake keys
[] Indicates messages protected using 1-RTT keys [] Indicates messages protected using 1-RTT keys
Figure 27: A Simplified TLS 1.3 Handshake with 0-RTT Figure 27: A Simplified TLS 1.3 Handshake with 0-RTT
7.3. DTLS MTU and Fragmentation 7.3. DTLS MTU and Fragmentation
To avoid DOTS signal message fragmentation and the subsequent To avoid DOTS signal message fragmentation and the subsequent
decreased probability of message delivery, DOTS agents MUST ensure decreased probability of message delivery, DOTS agents MUST ensure
that the DTLS record fit within a single datagram. If the PMTU that the DTLS record fit within a single datagram. As a reminder,
cannot be discovered, DOTS agents MUST assume a PMTU of 1280 bytes, DTLS handles fragmentation and reassembly only for handshake messages
as IPv6 requires that every link in the Internet have an MTU of 1280 and not for the application data (Section 4.1.1 of [RFC6347]). If
octets or greater as specified in [RFC8200]. If IPv4 support on the PMTU cannot be discovered, DOTS agents MUST assume a PMTU of 1280
legacy or otherwise unusual networks is a consideration and the PMTU bytes, as IPv6 requires that every link in the Internet have an MTU
is unknown, DOTS implementations MAY assume on a PMTU of 576 bytes of 1280 octets or greater as specified in [RFC8200]. If IPv4 support
for IPv4 datagrams, as every IPv4 host must be capable of receiving a on legacy or otherwise unusual networks is a consideration and the
packet whose length is equal to 576 bytes as discussed in [RFC0791] PMTU is unknown, DOTS implementations MAY assume on a PMTU of 576
and [RFC1122]. bytes for IPv4 datagrams, as every IPv4 host must be capable of
receiving a packet whose length is equal to 576 bytes as discussed in
[RFC0791] and [RFC1122].
The DOTS client must consider the amount of record expansion expected The DOTS client must consider the amount of record expansion expected
by the DTLS processing when calculating the size of CoAP message that by the DTLS processing when calculating the size of CoAP message that
fits within the path MTU. Path MTU MUST be greater than or equal to fits within the path MTU. Path MTU MUST be greater than or equal to
[CoAP message size + DTLS 1.2 overhead of 13 octets + authentication [CoAP message size + DTLS 1.2 overhead of 13 octets + authentication
overhead of the negotiated DTLS cipher suite + block padding] overhead of the negotiated DTLS cipher suite + block padding]
(Section 4.1.1.1 of [RFC6347]). If the total request size exceeds (Section 4.1.1.1 of [RFC6347]). If the total request size exceeds
the path MTU then the DOTS client MUST split the DOTS signal into the path MTU then the DOTS client MUST split the DOTS signal into
separate messages; for example, the list of addresses in the 'target- separate messages; for example, the list of addresses in the 'target-
prefix' parameter could be split into multiple lists and each list prefix' parameter could be split into multiple lists and each list
skipping to change at page 92, line 46 skipping to change at page 93, line 46
IANA is requested to add this note to "DOTS Status Codes", "DOTS IANA is requested to add this note to "DOTS Status Codes", "DOTS
Conflict Status Codes", "DOTS Conflict Cause Codes", and "DOTS Attack Conflict Status Codes", "DOTS Conflict Cause Codes", and "DOTS Attack
Status Codes" registries: Status Codes" registries:
When this registry is modified, the YANG module iana-dots-signal- When this registry is modified, the YANG module iana-dots-signal-
channel must be updated as defined in [RFCXXXX]. channel must be updated as defined in [RFCXXXX].
10. Security Considerations 10. Security Considerations
High-level DOTS security considerations are documented in High-level DOTS security considerations are documented in [RFC8612]
[I-D.ietf-dots-requirements] and [I-D.ietf-dots-architecture]. and [I-D.ietf-dots-architecture].
Authenticated encryption MUST be used for data confidentiality and Authenticated encryption MUST be used for data confidentiality and
message integrity. The interaction between the DOTS agents requires message integrity. The interaction between the DOTS agents requires
Datagram Transport Layer Security (DTLS) or Transport Layer Security Datagram Transport Layer Security (DTLS) or Transport Layer Security
(TLS) with a cipher suite offering confidentiality protection, and (TLS) with a cipher suite offering confidentiality protection, and
the guidance given in [RFC7525] MUST be followed to avoid attacks on the guidance given in [RFC7525] MUST be followed to avoid attacks on
(D)TLS. The (D)TLS protocol profile used for the DOTS signal channel (D)TLS. The (D)TLS protocol profile used for the DOTS signal channel
is specified in Section 7. is specified in Section 7.
If TCP is used between DOTS agents, an attacker may be able to inject If TCP is used between DOTS agents, an attacker may be able to inject
skipping to change at page 98, line 28 skipping to change at page 99, line 28
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets", Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018, RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>. <https://www.rfc-editor.org/info/rfc8323>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
13.2. Informative References 13.2. Informative References
[I-D.boucadair-dots-earlydata] [I-D.boucadair-dots-earlydata]
Boucadair, M. and R. K, "Using Early Data in DOTS", draft- Boucadair, M. and R. K, "Using Early Data in DOTS", draft-
boucadair-dots-earlydata-00 (work in progress), January boucadair-dots-earlydata-00 (work in progress), January
2019. 2019.
[I-D.ietf-core-comi] [I-D.ietf-core-comi]
Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP
Management Interface", draft-ietf-core-comi-04 (work in Management Interface", draft-ietf-core-comi-05 (work in
progress), November 2018. progress), May 2019.
[I-D.ietf-core-yang-cbor] [I-D.ietf-core-yang-cbor]
Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of
Data Modeled with YANG", draft-ietf-core-yang-cbor-10 Data Modeled with YANG", draft-ietf-core-yang-cbor-10
(work in progress), April 2019. (work in progress), April 2019.
[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-data-channel] [I-D.ietf-dots-data-channel]
Boucadair, M. and R. K, "Distributed Denial-of-Service Boucadair, M. and R. K, "Distributed Denial-of-Service
Open Threat Signaling (DOTS) Data Channel Specification", Open Threat Signaling (DOTS) Data Channel Specification",
draft-ietf-dots-data-channel-28 (work in progress), March draft-ietf-dots-data-channel-29 (work in progress), May
2019. 2019.
[I-D.ietf-dots-multihoming] [I-D.ietf-dots-multihoming]
Boucadair, M. and R. K, "Multi-homing Deployment Boucadair, M. and R. K, "Multi-homing Deployment
Considerations for Distributed-Denial-of-Service Open Considerations for Distributed-Denial-of-Service Open
Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01 Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01
(work in progress), January 2019. (work in progress), January 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.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
Open Threat Signaling", draft-ietf-dots-use-cases-17 (work Open Threat Signaling", draft-ietf-dots-use-cases-17 (work
in progress), January 2019. in progress), January 2019.
[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
skipping to change at page 102, line 44 skipping to change at page 103, line 44
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016, RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>. <https://www.rfc-editor.org/info/rfc7951>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<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. CUID Generation Appendix A. 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 to avoid extra cycles that may be induced by 'cuid' o It allows to avoid extra cycles that may be induced by 'cuid'
 End of changes. 33 change blocks. 
117 lines changed or deleted 142 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/