< draft-ietf-dots-signal-channel-38.txt   draft-ietf-dots-signal-channel-39.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: April 20, 2020 Orange Expires: May 23, 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
October 18, 2019 November 20, 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-38 draft-ietf-dots-signal-channel-39
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 April 20, 2020. This Internet-Draft will expire on May 23, 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 47 skipping to change at page 2, line 47
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . 10
4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . 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 . . . . . 35
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
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 . . . . . . 53
4.5.4. Delete DOTS Signal Channel Session Configuration . . 54 4.5.4. Delete DOTS Signal Channel Session Configuration . . 54
4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 55 4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 55
4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 57 4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 57
5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 58 5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 59
5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 59 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 60
5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 61 5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 62
5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 65 5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 66
6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 75 6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 77
7. (D)TLS Protocol Profile and Performance Considerations . . . 77 7. (D)TLS Protocol Profile and Performance Considerations . . . 79
7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 77 7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 79
7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 79 7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 81
7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 81 7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 83
8. Mutual Authentication of DOTS Agents & Authorization of DOTS 8. Mutual Authentication of DOTS Agents & Authorization of DOTS
Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85
9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 84 9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 85
9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 84 9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 85
9.3. Media Type Registration . . . . . . . . . . . . . . . . . 84 9.3. Media Type Registration . . . . . . . . . . . . . . . . . 85
9.4. CoAP Content-Formats Registration . . . . . . . . . . . . 85 9.4. CoAP Content-Formats Registration . . . . . . . . . . . . 86
9.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 85 9.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 86
9.6. DOTS Signal Channel Protocol Registry . . . . . . . . . . 86 9.6. DOTS Signal Channel Protocol Registry . . . . . . . . . . 87
9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry . . 86 9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry . . 87
9.6.1.1. Registration Template . . . . . . . . . . . . . . 86 9.6.1.1. Registration Template . . . . . . . . . . . . . . 87
9.6.1.2. Initial Sub-Registry Content . . . . . . . . . . 87 9.6.1.2. Initial Sub-Registry Content . . . . . . . . . . 88
9.6.2. Status Codes Sub-Registry . . . . . . . . . . . . . . 89 9.6.2. Status Codes Sub-Registry . . . . . . . . . . . . . . 90
9.6.3. Conflict Status Codes Sub-Registry . . . . . . . . . 90 9.6.3. Conflict Status Codes Sub-Registry . . . . . . . . . 91
9.6.4. Conflict Cause Codes Sub-Registry . . . . . . . . . . 92 9.6.4. Conflict Cause Codes Sub-Registry . . . . . . . . . . 93
9.6.5. Attack Status Codes Sub-Registry . . . . . . . . . . 92 9.6.5. Attack Status Codes Sub-Registry . . . . . . . . . . 93
9.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 93 9.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 94
10. Security Considerations . . . . . . . . . . . . . . . . . . . 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 95
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 96 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 97
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 97 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 98
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 97 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 98
13.1. Normative References . . . . . . . . . . . . . . . . . . 97 13.1. Normative References . . . . . . . . . . . . . . . . . . 98
13.2. Informative References . . . . . . . . . . . . . . . . . 100 13.2. Informative References . . . . . . . . . . . . . . . . . 102
Appendix A. CUID Generation . . . . . . . . . . . . . . . . . . 105 Appendix A. CUID Generation . . . . . . . . . . . . . . . . . . 106
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106
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 6, line 34 skipping to change at page 6, line 34
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
asynchronous Non-confirmable messaging, congestion control, small asynchronous Non-confirmable messaging, congestion control, small
message overhead limiting the need for fragmentation, use of minimal message overhead limiting the need for fragmentation, use of minimal
resources, and support for (D)TLS) makes it a good candidate to build resources, and support for (D)TLS) makes it a good candidate to build
the DOTS signaling mechanism from. the DOTS signaling mechanism from.
DOTS clients and servers behave as CoAP endpoints. By default, a
DOTS client (or server) behaves as a CoAP client (or server).
Nevertheless, a DOTS client (or server) behaves as a CoAP server (or
client) for specific operations such as DOTS heartbeat operations
(Section 4.7).
The DOTS signal channel is layered on existing standards (Figure 3). The DOTS signal channel is layered on existing standards (Figure 3).
+---------------------+ +---------------------+
| DOTS Signal Channel | | DOTS Signal Channel |
+---------------------+ +---------------------+
| CoAP | | CoAP |
+----------+----------+ +----------+----------+
| TLS | DTLS | | TLS | DTLS |
+----------+----------+ +----------+----------+
| TCP | UDP | | TCP | UDP |
skipping to change at page 10, line 21 skipping to change at page 10, line 37
path-prefix to form the URI used with a CoAP request to perform the path-prefix to form the URI used with a CoAP request to perform the
desired DOTS operation. desired DOTS operation.
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
| Operation | Operation Path | Details | | Operation | Operation Path | Details |
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
| Mitigation | /mitigate | Section 4.4 | | Mitigation | /mitigate | Section 4.4 |
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
| Session configuration | /config | Section 4.5 | | Session configuration | /config | Section 4.5 |
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
| Heartbeat | /hb | Section 4.7 |
+-----------------------+----------------+-------------+
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
[RFC8612] mentions that DOTS agents will have to support both [RFC8612] mentions that DOTS agents will have to support both
connectionless and connection-oriented protocols. As such, the DOTS connectionless and connection-oriented protocols. As such, the DOTS
signal channel is designed to operate with DTLS over UDP and TLS over signal channel is designed to operate with DTLS over UDP and TLS over
TCP. Further, a DOTS client may acquire a list of IPv4 and IPv6 TCP. Further, a DOTS client may acquire a list of IPv4 and IPv6
addresses (Section 4.1), each of which can be used to contact the addresses (Section 4.1), each of which can be used to contact the
skipping to change at page 13, line 10 skipping to change at page 13, line 24
DOTS agents MUST NOT send more than one UDP datagram per round-trip DOTS agents MUST NOT send more than one UDP datagram per round-trip
time (RTT) to the peer DOTS agent on average following the data time (RTT) to the peer DOTS agent on average following the data
transmission guidelines discussed in Section 3.1.3 of [RFC8085]. transmission guidelines discussed in Section 3.1.3 of [RFC8085].
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]). Mitigation requests MUST NOT be delayed
because of other congestion control checks. Typically, mitigation
requests must be sent without checks on probing rate (Section 4.7 of
[RFC7252]).
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
examples use the Labels defined in Sections 9.6.2, 9.6.3, 9.6.4, and examples use the Labels defined in Sections 9.6.2, 9.6.3, 9.6.4, and
9.6.5. 9.6.5.
4.4.1. Request Mitigation 4.4.1. Request Mitigation
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
skipping to change at page 34, line 10 skipping to change at page 34, line 10
measuring packets into five-minute buckets and then averaging measuring packets into five-minute buckets and then averaging
these buckets over the time since the mitigation was triggered). these buckets over the time since the mitigation was triggered).
This is an optional attribute. This is an optional attribute.
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Parameter | Description | | Parameter | Description |
| Value | | | Value | |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 1 | Attack mitigation setup is in progress (e.g., | | 1 | Attack mitigation setup is in progress (e.g., |
| | changing the network path to redirect the inbound | | | changing the network path to redirect the |
| | traffic to a DOTS mitigator). | | | inbound traffic to a DOTS mitigator). |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 2 | Attack is being successfully mitigated (e.g., traffic | | 2 | Attack is being successfully mitigated (e.g., traffic |
| | is redirected to a DDoS mitigator and attack traffic | | | is redirected to a DDoS mitigator and |
| | is dropped). | | | attack traffic is dropped). |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 3 | Attack has stopped and the DOTS client can withdraw | | 3 | Attack has stopped and the DOTS client can withdraw |
| | the mitigation request. This status code will be | | | the mitigation request. This status code |
| | transmitted for immediate mitigation requests till | | | will be transmitted for immediate |
| | the mitigation is withdrawn or the lifetime expires. | | | mitigation requests till the mitigation is withdrawn |
| | For mitigation requests with pre-configured scopes | | | or the lifetime expires. For mitigation |
| | requests with pre-configured scopes |
| | (i.e., 'trigger-mitigation' set to 'false'), this | | | (i.e., 'trigger-mitigation' set to 'false'), this |
| | status code will be transmitted 4 times and then | | | status code will be transmitted 4 times |
| | transition to "8". | | | and then transition to "8". |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 4 | Attack has exceeded the mitigation provider | | 4 | Attack has exceeded the mitigation provider |
| | capability. | | | capability. |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 5 | DOTS client has withdrawn the mitigation request and | | 5 | DOTS client has withdrawn the mitigation request and |
| | the mitigation is active but terminating. | | | the mitigation is active but terminating. |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 6 | Attack mitigation is now terminated. | | 6 | Attack mitigation is now terminated. |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 7 | Attack mitigation is withdrawn (by the DOTS server). | | 7 | Attack mitigation is withdrawn (by the DOTS server). |
| | If a mitigation request with 'trigger-mitigation' set | | | If a mitigation request with 'trigger- |
| | to false is withdrawn because it overlaps with an | | | mitigation' set to false is withdrawn |
| | immediate mitigation request, this status code will | | | because it overlaps with an immediate mitigation |
| | be transmitted 4 times and then transition to "8" for | | | request, this status code will be transmitted 4 times |
| | the mitigation request with pre-configured scopes. | | | and then transition to "8" for the |
| | mitigation request with pre-configured |
| | scopes. |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 8 | Attack mitigation will be triggered for the | | 8 | Attack mitigation will be triggered for the |
| | mitigation request only when the DOTS signal channel | | | mitigation request only when the DOTS |
| | session is lost. | | | signal channel session is lost. |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
Table 2: Values of 'status' Parameter Table 2: Values of 'status' Parameter
4.4.2.1. DOTS Servers Sending Mitigation Status 4.4.2.1. DOTS Servers Sending Mitigation Status
The Observe Option defined in [RFC7641] extends the CoAP core The Observe Option defined in [RFC7641] extends the CoAP core
protocol with a mechanism for a CoAP client to "observe" a resource protocol with a mechanism for a CoAP client to "observe" a resource
on a CoAP server: The client retrieves a representation of the on a CoAP server: The client retrieves a representation of the
resource and requests this representation be updated by the server as resource and requests this representation be updated by the server as
skipping to change at page 36, line 24 skipping to change at page 36, line 28
means to alert administrators about mitigation conflicts. means to alert administrators about mitigation conflicts.
A DOTS client that is no longer interested in receiving notifications A DOTS client that is no longer interested in receiving notifications
from the DOTS server can simply "forget" the observation. When the from the DOTS server can simply "forget" the observation. When the
DOTS server sends the next notification, the DOTS client will not DOTS server sends the next notification, the DOTS client will not
recognize the token in the message and thus will return a Reset recognize the token in the message and thus will return a Reset
message. This causes the DOTS server to remove the associated entry. message. This causes the DOTS server to remove the associated entry.
Alternatively, the DOTS client can explicitly deregister itself by Alternatively, the DOTS client can explicitly deregister itself by
issuing a GET request that has the Token field set to the token of issuing a GET request that has the Token field set to the token of
the observation to be cancelled and includes an Observe Option with the observation to be cancelled and includes an Observe Option with
the value set to '1' (deregister). The latter is RECOMMENDED. the value set to '1' (deregister). The latter is more deterministic
and thus is RECOMMENDED.
Figure 15 shows an example of a DOTS client requesting a DOTS server Figure 15 shows an example of a DOTS client requesting a DOTS server
to send notifications related to a mitigation request. Note that for to send notifications related to a mitigation request. Note that for
mitigations with pre-configured scopes (i.e., 'trigger-mitigation' mitigations with pre-configured scopes (i.e., 'trigger-mitigation'
set to 'false'), the state will need to transition from 3 (attack- set to 'false'), the state will need to transition from 3 (attack-
stopped) to 8 (attack-mitigation-signal-loss). stopped) to 8 (attack-mitigation-signal-loss).
+-----------+ +-----------+ +-----------+ +-----------+
|DOTS client| |DOTS server| |DOTS client| |DOTS server|
+-----------+ +-----------+ +-----------+ +-----------+
skipping to change at page 40, line 13 skipping to change at page 40, line 13
in the 'attack-status' parameter are described in Table 3. in the 'attack-status' parameter are described in Table 3.
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Parameter | Description | | Parameter | Description |
| value | | | value | |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 1 | The DOTS client determines that it is still under | | 1 | The DOTS client determines that it is still under |
| | attack. | | | attack. |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 2 | The DOTS client determines that the attack is | | 2 | The DOTS client determines that the attack is |
| | successfully mitigated (e.g., attack traffic is not | | | successfully mitigated (e.g., attack |
| | seen). | | | traffic is not seen). |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
Table 3: Values of 'attack-status' Parameter Table 3: Values of 'attack-status' Parameter
The DOTS server indicates the result of processing a PUT request The DOTS server indicates the result of processing a PUT request
using CoAP response codes. The response code 2.04 (Changed) is using CoAP response codes. The response code 2.04 (Changed) is
returned if the DOTS server has accepted the mitigation efficacy returned if the DOTS server has accepted the mitigation efficacy
update. The error response code 5.03 (Service Unavailable) is update. The error response code 5.03 (Service Unavailable) is
returned if the DOTS server has erred or is incapable of performing returned if the DOTS server has erred or is incapable of performing
the mitigation. As specified in [RFC7252], 5.03 uses Max-Age option the mitigation. As specified in [RFC7252], 5.03 uses Max-Age option
skipping to change at page 42, line 10 skipping to change at page 42, line 10
successfully completed in order to keep the DOTS signal channel successfully completed in order to keep the DOTS signal channel
open. Heartbeat messages are exchanged between DOTS agents every open. Heartbeat messages are exchanged between DOTS agents every
'heartbeat-interval' seconds to detect the current status of the 'heartbeat-interval' seconds to detect the current status of the
DOTS signal channel session. DOTS signal channel session.
b. Missing heartbeats allowed (missing-hb-allowed): This variable b. Missing heartbeats allowed (missing-hb-allowed): This variable
indicates the maximum number of consecutive heartbeat messages indicates the maximum number of consecutive heartbeat messages
for which a DOTS agent did not receive a response before for which a DOTS agent did not receive a response before
concluding that the session is disconnected or defunct. concluding that the session is disconnected or defunct.
c. Acceptable signal loss ratio: Maximum retransmissions, c. Acceptable probing rate (probing-rate): This parameter indicates
the average data rate that must not be exceeded by a DOTS agent
in sending to a peer DOTS agent that does not respond.
d. Acceptable signal loss ratio: Maximum retransmissions,
retransmission timeout value, and other message transmission retransmission timeout value, and other message transmission
parameters for the DOTS signal channel. parameters for Confirmable messages over the DOTS signal channel.
When the DOTS signal channel is established over a reliable transport When the DOTS signal channel is established over a reliable transport
(e.g., TCP), there is no need for the reliability mechanisms provided (e.g., TCP), there is no need for the reliability mechanisms provided
by CoAP over UDP since the underlying TCP connection provides by CoAP over UDP since the underlying TCP connection provides
retransmissions and deduplication [RFC8323]. As a reminder, CoAP retransmissions and deduplication [RFC8323]. As a reminder, CoAP
over reliable transports does not support Confirmable or Non- over reliable transports does not support Confirmable or Non-
confirmable message types. As such, the transmission-related confirmable message types. As such, the transmission-related
parameters (missing-hb-allowed and acceptable signal loss ratio) are parameters (missing-hb-allowed and acceptable signal loss ratio) are
negotiated only for DOTS over unreliable transports. negotiated only for DOTS over unreliable transports.
skipping to change at page 42, line 38 skipping to change at page 42, line 42
mitigation. If distinct configurations are used, DOTS agents MUST mitigation. If distinct configurations are used, DOTS agents MUST
follow the appropriate configuration set as a function of the follow the appropriate configuration set as a function of the
mitigation activity (e.g., if no mitigation request is active (also mitigation activity (e.g., if no mitigation request is active (also
referred to as 'idle' time), 'idle-config'-related values must be referred to as 'idle' time), 'idle-config'-related values must be
followed). Additionally, DOTS agents MUST automatically switch to followed). Additionally, DOTS agents MUST automatically switch to
the other configuration upon a change in the mitigation activity the other configuration upon a change in the mitigation activity
(e.g., if an attack mitigation is launched after an 'idle' time, the (e.g., if an attack mitigation is launched after an 'idle' time, the
DOTS agent switches from 'idle-config' to 'mitigating-config'-related DOTS agent switches from 'idle-config' to 'mitigating-config'-related
values). values).
The specification allows for a flexible retry configuration when an
unreliable transport is in use. For example, a server may be tweaked
to return the following configuration to be used when a mitigation is
active:
o a 'max-retransmit' set to '1' together with a higher 'missing-hb-
allowed' value (e.g., 34) and a default 'ack-timeout' set to 2
seconds. This configuration implies more frequent heartbeats in a
given time span when a loss is encountered.
o a lower 'missing-hb-allowed' (e.g., 7) value but delegate the
retransmission (with exponential back-off) to the underlying CoAP
library by setting 'max-retransmit' to a high value (e.g., 3).
When a loss is encountered, this configuration implies less
frequent heartbeats compared to the previous bullet.
o a higher 'ack-timeout' value (e.g., 10 seconds), a 'max-
retransmit' set to '1', and a 'missing-hb-allowed' value set to 7.
Compared to the previous bullet, this configuration reduces by 50%
the number of required heartbeats from the first transmission of a
heartbeat message to the time when the DOTS agent gives up.
o etc.
CoAP Requests and responses are indicated for reliable delivery by CoAP Requests and responses are indicated for reliable delivery by
marking them as Confirmable messages. DOTS signal channel session marking them as Confirmable messages. DOTS signal channel session
configuration requests and responses are marked as Confirmable configuration requests and responses are marked as Confirmable
messages. As explained in Section 2.1 of [RFC7252], a Confirmable messages. As explained in Section 2.1 of [RFC7252], a Confirmable
message is retransmitted using a default timeout and exponential message is retransmitted using a default timeout and exponential
back-off between retransmissions, until the DOTS server sends an back-off between retransmissions, until the DOTS server sends an
Acknowledgement message (ACK) with the same Message ID conveyed from Acknowledgement message (ACK) with the same Message ID conveyed from
the DOTS client. the DOTS client.
Message transmission parameters are defined in Section 4.8 of Message transmission parameters are defined in Section 4.8 of
[RFC7252]. The DOTS server can either piggyback the response in the [RFC7252]. The DOTS server can either piggyback the response in the
acknowledgement message or, if the DOTS server cannot respond acknowledgement message or, if the DOTS server cannot respond
immediately to a request carried in a Confirmable message, it simply immediately to a request carried in a Confirmable message, it simply
responds with an Empty Acknowledgement message so that the DOTS responds with an Empty Acknowledgement message so that the DOTS
client can stop retransmitting the request. Empty Acknowledgement client can stop retransmitting the request. Empty Acknowledgement
messages are explained in Section 2.2 of [RFC7252]. When the messages are explained in Section 2.2 of [RFC7252]. When the
response is ready, the server sends it in a new Confirmable message response is ready, the server sends it in a new Confirmable message
which in turn needs to be acknowledged by the DOTS client (see which in turn needs to be acknowledged by the DOTS client (see
Sections 5.2.1 and 5.2.2 of [RFC7252]). Requests and responses Sections 5.2.1 and 5.2.2 of [RFC7252]). Requests and responses
exchanged between DOTS agents during 'idle' time are marked as exchanged between DOTS agents during 'idle' time, except heartbeat
Confirmable messages. messages, are marked as Confirmable messages.
Implementation Note: A DOTS client that receives a response in a Implementation Note: A DOTS client that receives a response in a
Confirmable message may want to clean up the message state right Confirmable message may want to clean up the message state right
after sending the ACK. If that ACK is lost and the DOTS server after sending the ACK. If that ACK is lost and the DOTS server
retransmits the Confirmable message, the DOTS client may no longer retransmits the Confirmable message, the DOTS client may no longer
have any state that would help it correlate this response: from have any state that would help it correlate this response: from
the DOTS client's standpoint, the retransmission message is the DOTS client's standpoint, the retransmission message is
unexpected. The DOTS client will send a Reset message so it does unexpected. The DOTS client will send a Reset message so it does
not receive any more retransmissions. This behavior is normal and not receive any more retransmissions. This behavior is normal and
not an indication of an error (see Section 5.3.2 of [RFC7252] for not an indication of an error (see Section 5.3.2 of [RFC7252] for
more details). more details).
4.5.1. Discover Configuration Parameters 4.5.1. Discover Configuration Parameters
A GET request is used to obtain acceptable (e.g., minimum and maximum A GET request is used to obtain acceptable (e.g., minimum and maximum
values) and current configuration parameters on the DOTS server for values) and current configuration parameters on the DOTS server for
DOTS signal channel session configuration. This procedure occurs DOTS signal channel session configuration. This procedure occurs
between a DOTS client and its immediate peer DOTS server. As such, between a DOTS client and its immediate peer DOTS server. As such,
this GET request MUST NOT be relayed by a DOTS gateway. this GET request MUST NOT be relayed by a DOTS gateway.
Figure 18 shows how to obtain acceptable configuration parameters for Figure 18 shows how to obtain configuration parameters that the DOTS
the DOTS server. server will find acceptable.
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "config" Uri-Path: "config"
Figure 18: GET to Retrieve Configuration Figure 18: GET to Retrieve Configuration
The DOTS server in the 2.05 (Content) response conveys the current, The DOTS server in the 2.05 (Content) response conveys the current,
minimum, and maximum attribute values acceptable by the DOTS server minimum, and maximum attribute values acceptable by the DOTS server
skipping to change at page 44, line 32 skipping to change at page 44, line 13
"heartbeat-interval": { "heartbeat-interval": {
"max-value": number, "max-value": number,
"min-value": number, "min-value": number,
"current-value": number "current-value": number
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
"max-value": number, "max-value": number,
"min-value": number, "min-value": number,
"current-value": number "current-value": number
}, },
"probing-rate": {
"max-value": number,
"min-value": number,
"current-value": number
},
"max-retransmit": { "max-retransmit": {
"max-value": number, "max-value": number,
"min-value": number, "min-value": number,
"current-value": number "current-value": number
}, },
"ack-timeout": { "ack-timeout": {
"max-value-decimal": "string", "max-value-decimal": "string",
"min-value-decimal": "string", "min-value-decimal": "string",
"current-value-decimal": "string" "current-value-decimal": "string"
}, },
skipping to change at page 45, line 4 skipping to change at page 44, line 39
"max-value-decimal": "string", "max-value-decimal": "string",
"min-value-decimal": "string", "min-value-decimal": "string",
"current-value-decimal": "string" "current-value-decimal": "string"
} }
}, },
"idle-config": { "idle-config": {
"heartbeat-interval": { "heartbeat-interval": {
"max-value": number, "max-value": number,
"min-value": number, "min-value": number,
"current-value": number "current-value": number
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
"max-value": number, "max-value": number,
"min-value": number, "min-value": number,
"current-value": number "current-value": number
}, },
"probing-rate": {
"max-value": number,
"min-value": number,
"current-value": number
},
"max-retransmit": { "max-retransmit": {
"max-value": number, "max-value": number,
"min-value": number, "min-value": number,
"current-value": number "current-value": number
}, },
"ack-timeout": { "ack-timeout": {
"max-value-decimal": "string", "max-value-decimal": "string",
"min-value-decimal": "string", "min-value-decimal": "string",
"current-value-decimal": "string" "current-value-decimal": "string"
}, },
skipping to change at page 45, line 50 skipping to change at page 45, line 41
'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
a DOTS agent in sending to a peer DOTS agent that does not
respond (referred to as PROBING_RATE parameter in CoAP).
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
ACK_TIMEOUT parameter in CoAP). ACK_TIMEOUT parameter in CoAP).
This is an optional attribute. This is an optional attribute.
skipping to change at page 46, line 37 skipping to change at page 46, line 35
{ {
"ietf-dots-signal-channel:signal-config": { "ietf-dots-signal-channel:signal-config": {
"mitigating-config": { "mitigating-config": {
"heartbeat-interval": { "heartbeat-interval": {
"max-value": 240, "max-value": 240,
"min-value": 15, "min-value": 15,
"current-value": 30 "current-value": 30
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
"max-value": 9, "max-value": 20,
"min-value": 3, "min-value": 3,
"current-value": 5 "current-value": 15
},
"probing-rate": {
"max-value": 20,
"min-value": 5,
"current-value": 15
}, },
"max-retransmit": { "max-retransmit": {
"max-value": 15, "max-value": 15,
"min-value": 2, "min-value": 2,
"current-value": 3 "current-value": 3
}, },
"ack-timeout": { "ack-timeout": {
"max-value-decimal": "30.00", "max-value-decimal": "30.00",
"min-value-decimal": "1.00", "min-value-decimal": "1.00",
"current-value-decimal": "2.00" "current-value-decimal": "2.00"
skipping to change at page 46, line 50 skipping to change at page 47, line 4
}, },
"max-retransmit": { "max-retransmit": {
"max-value": 15, "max-value": 15,
"min-value": 2, "min-value": 2,
"current-value": 3 "current-value": 3
}, },
"ack-timeout": { "ack-timeout": {
"max-value-decimal": "30.00", "max-value-decimal": "30.00",
"min-value-decimal": "1.00", "min-value-decimal": "1.00",
"current-value-decimal": "2.00" "current-value-decimal": "2.00"
}, },
"ack-random-factor": { "ack-random-factor": {
"max-value-decimal": "4.00", "max-value-decimal": "4.00",
"min-value-decimal": "1.10", "min-value-decimal": "1.10",
"current-value-decimal": "1.50" "current-value-decimal": "1.50"
} }
}, },
"idle-config": { "idle-config": {
"heartbeat-interval": { "heartbeat-interval": {
"max-value": 240, "max-value": 240,
"min-value": 15, "min-value": 15,
"current-value": 30 "current-value": 30
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
"max-value": 9, "max-value": 20,
"min-value": 3, "min-value": 3,
"current-value": 5 "current-value": 15
},
"probing-rate": {
"max-value": 20,
"min-value": 5,
"current-value": 15
}, },
"max-retransmit": { "max-retransmit": {
"max-value": 15, "max-value": 15,
"min-value": 2, "min-value": 2,
"current-value": 3 "current-value": 3
}, },
"ack-timeout": { "ack-timeout": {
"max-value-decimal": "30.00", "max-value-decimal": "30.00",
"min-value-decimal": "1.00", "min-value-decimal": "1.00",
"current-value-decimal": "2.00" "current-value-decimal": "2.00"
skipping to change at page 47, line 47 skipping to change at page 48, line 12
Figure 20: Example of a Configuration Response Body Figure 20: Example of a Configuration Response Body
4.5.2. Convey DOTS Signal Channel Session Configuration 4.5.2. Convey DOTS Signal Channel Session Configuration
A PUT request (Figures 21 and 22) is used to convey the configuration A PUT request (Figures 21 and 22) is used to convey the configuration
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), and 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). (15).
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 [RFC8612]). According to messages for NAT traversal (SIG-011 of [RFC8612]). According to
[RFC8085], keepalive messages must not be sent more frequently [RFC8085], heartbeat messages must not be sent more frequently
than once every 15 seconds and should use longer intervals when than once every 15 seconds and should use longer intervals when
possible. Furthermore, [RFC4787] recommends NATs to use a state possible. Furthermore, [RFC4787] recommends NATs to use a state
timeout of 2 minutes or longer, but experience shows that sending timeout of 2 minutes or longer, but experience shows that sending
packets every 15 to 30 seconds is necessary to prevent the packets every 15 to 30 seconds is necessary to prevent the
majority of middleboxes from losing state for UDP flows. From majority of middleboxes from losing state for UDP flows. From
that standpoint, the RECOMMENDED minimum heartbeat-interval is 15 that 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 heartbeats.
Different heartbeat intervals can be defined for 'mitigating- Different heartbeat intervals can be defined for 'mitigating-
config' and 'idle-config' to reduce being too chatty during idle config' and 'idle-config' to reduce being too chatty during idle
times. If there is an on-path translator between the DOTS client times. If there is an on-path translator between the DOTS client
(standalone or part of a DOTS gateway) and the DOTS server, the (standalone or part of a DOTS gateway) and the DOTS server, the
'mitigating-config' heartbeat-interval has to be smaller than the 'mitigating-config' heartbeat-interval has to be smaller than the
translator session timeout. It is recommended that the 'idle- translator session timeout. It is recommended that the 'idle-
config' heartbeat-interval is also smaller than the translator config' heartbeat-interval is also smaller than the translator
session timeout to prevent translator traversal issues, or session timeout to prevent translator traversal issues, or
disabled entirely. Means to discover the lifetime assigned by a disabled entirely. Means to discover the lifetime assigned by a
translator are out of scope. translator are out of scope.
Section 4.2 of [RFC7252] defines a "CoAP Ping" mechanism. Given that the size of the heartbeat request can not exceed
Concretely, the DOTS agent sends an Empty Confirmable message and the (heartbeat-interval * probing-rate) bytes, probing-rate should be
peer DOTS agent will respond by sending a Reset message. set appropriately to avoid slowing down heartbeat exchanges. For
example, probing-rate may be set to 2 * ("size of encrypted DOTS
When a Confirmable "CoAP Ping" is sent, and if there is no response, heartbeat request"/heartbeat-interval) or (("size of encrypted
the "CoAP Ping" is retransmitted max-retransmit number of times by DOTS heartbeat request" + "average size of an encrypted mitigation
the CoAP layer using an initial timeout set to a random duration request")/heartbeat-interval). Absent any explicit configuration
between ack-timeout and (ack-timeout*ack-random-factor) and or inability to dynamically adjust probing-rate values
exponential back-off between retransmissions. By choosing the (Section 4.8.1 of [RFC7252]), DOTS agents use 5 bytes/second as a
recommended transmission parameters, the "CoAP Ping" will timeout default probing-rate value.
after 45 seconds. If the DOTS agent does not receive any response
from the peer DOTS agent for 'missing-hb-allowed' number of
consecutive "CoAP Ping" Confirmable messages, it concludes that the
DOTS signal channel session is disconnected. A DOTS client MUST NOT
transmit a "CoAP Ping" while waiting for the previous "CoAP Ping"
response from the same DOTS server.
If the DOTS agent wishes to change the default values of message If the DOTS agent wishes to change the default values of message
transmission parameters, it SHOULD follow the guidance given in transmission parameters, it SHOULD follow the guidance given in
Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the negotiated Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the negotiated
values for message transmission parameters and default values for values for message transmission parameters and default values for
non-negotiated message transmission parameters. non-negotiated message transmission parameters.
The signal channel session configuration is applicable to a single The signal channel session configuration is applicable to a single
DOTS signal channel session between DOTS agents, so the 'cuid' Uri- DOTS signal channel session between DOTS agents, so the 'cuid' Uri-
Path MUST NOT be used. Path MUST NOT be used.
skipping to change at page 50, line 14 skipping to change at page 50, line 14
{ {
"ietf-dots-signal-channel:signal-config": { "ietf-dots-signal-channel:signal-config": {
"mitigating-config": { "mitigating-config": {
"heartbeat-interval": { "heartbeat-interval": {
"current-value": number "current-value": number
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
"current-value": number "current-value": number
}, },
"probing-rate": {
"current-value": number
},
"max-retransmit": { "max-retransmit": {
"current-value": number "current-value": number
}, },
"ack-timeout": { "ack-timeout": {
"current-value-decimal": "string" "current-value-decimal": "string"
}, },
"ack-random-factor": { "ack-random-factor": {
"current-value-decimal": "string" "current-value-decimal": "string"
} }
}, },
"idle-config": { "idle-config": {
"heartbeat-interval": { "heartbeat-interval": {
"current-value": number "current-value": number
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
"current-value": number "current-value": number
}, },
"probing-rate": {
"current-value": number
},
"max-retransmit": { "max-retransmit": {
"current-value": number "current-value": number
}, },
"ack-timeout": { "ack-timeout": {
"current-value-decimal": "string" "current-value-decimal": "string"
}, },
"ack-random-factor": { "ack-random-factor": {
"current-value-decimal": "string" "current-value-decimal": "string"
} }
} }
} }
} }
Figure 22: PUT to Convey the DOTS Signal Channel Session Figure 22: PUT to Convey the DOTS Signal Channel Session
Configuration Data (Message Body Schema) Configuration Data (Message Body Schema)
The meaning of the parameters in the CBOR body (Figure 22) is defined The meaning of the parameters in the CBOR body (Figure 22) is defined
in Section 4.5.1. in Section 4.5.1.
At least one of the attributes 'heartbeat-interval', 'missing-hb- At least one of the attributes 'heartbeat-interval', 'missing-hb-
allowed', 'max-retransmit', 'ack-timeout', and 'ack-random-factor' allowed', 'probing-rate', 'max-retransmit', 'ack-timeout', and 'ack-
MUST be present in the PUT request. Note that 'heartbeat-interval', random-factor' MUST be present in the PUT request. Note that
'missing-hb-allowed', 'max-retransmit', 'ack-timeout', and 'ack- 'heartbeat-interval', 'missing-hb-allowed', 'probing-rate', 'max-
random-factor', if present, do not need to be provided for both retransmit', 'ack-timeout', and 'ack-random-factor', if present, do
'mitigating-config', and 'idle-config' in a PUT request. not need to be provided for both 'mitigating-config', and 'idle-
config' in a PUT request.
The PUT request with a higher numeric 'sid' value overrides the DOTS The PUT request with a higher numeric 'sid' value overrides the DOTS
signal channel session configuration data installed by a PUT request signal channel session configuration data installed by a PUT request
with a lower numeric 'sid' value. To avoid maintaining a long list with a lower numeric 'sid' value. To avoid maintaining a long list
of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be
automatically deleted and no longer available at the DOTS server. automatically deleted and no longer available at the DOTS server.
Figure 23 shows a PUT request example to convey the configuration Figure 23 shows a PUT request example to convey the configuration
parameters for the DOTS signal channel. In this example, the parameters for the DOTS signal channel. In this example, the
heartbeat mechanism is disabled when no mitigation is active, while heartbeat mechanism is disabled when no mitigation is active, while
the heartbeat interval is set to '91' when a mitigation is active. the heartbeat interval is set to '30' when a mitigation is active.
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: "config" Uri-Path: "config"
Uri-Path: "sid=123" Uri-Path: "sid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:signal-config": { "ietf-dots-signal-channel:signal-config": {
"mitigating-config": { "mitigating-config": {
"heartbeat-interval": { "heartbeat-interval": {
"current-value": 91 "current-value": 30
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
"current-value": 3 "current-value": 15
},
"probing-rate": {
"current-value": 15
}, },
"max-retransmit": { "max-retransmit": {
"current-value": 3 "current-value": 3
}, },
"ack-timeout": { "ack-timeout": {
"current-value-decimal": "2.00" "current-value-decimal": "2.00"
}, },
"ack-random-factor": { "ack-random-factor": {
"current-value-decimal": "1.50" "current-value-decimal": "1.50"
} }
skipping to change at page 53, line 19 skipping to change at page 53, line 22
o If the DOTS server does not find the 'sid' parameter value o If the DOTS server does not find the 'sid' parameter value
conveyed in the PUT request in its configuration data and if the conveyed in the PUT request in its configuration data and if the
DOTS server has accepted the configuration parameters, then a DOTS server has accepted the configuration parameters, then a
response code 2.01 (Created) MUST be returned in the response. response code 2.01 (Created) MUST be returned in the response.
o If the DOTS server finds the 'sid' parameter value conveyed in the o If the DOTS server finds the 'sid' parameter value conveyed in the
PUT request in its configuration data and if the DOTS server has PUT request in its configuration data and if the DOTS server has
accepted the updated configuration parameters, 2.04 (Changed) MUST accepted the updated configuration parameters, 2.04 (Changed) MUST
be returned in the response. be returned in the response.
o If any of the 'heartbeat-interval', 'missing-hb-allowed', 'max- o If any of the 'heartbeat-interval', 'missing-hb-allowed',
retransmit', 'target-protocol', 'ack-timeout', and 'ack-random- 'probing-rate', 'max-retransmit', 'target-protocol', 'ack-
factor' attribute values are not acceptable to the DOTS server, timeout', and 'ack-random-factor' attribute values are not
4.22 (Unprocessable Entity) MUST be returned in the response. acceptable to the DOTS server, 4.22 (Unprocessable Entity) MUST be
Upon receipt of this error code, the DOTS client SHOULD retrieve returned in the response. Upon receipt of this error code, the
the maximum and minimum attribute values acceptable to the DOTS DOTS client SHOULD retrieve the maximum and minimum attribute
server (Section 4.5.1). values acceptable to the DOTS server (Section 4.5.1).
The DOTS client may re-try and send the PUT request with updated The DOTS client may re-try and send the PUT request with updated
attribute values acceptable to the DOTS server. attribute values acceptable to the DOTS server.
A DOTS client may issue a GET message with 'sid' Uri-Path parameter A DOTS client may issue a GET message with 'sid' Uri-Path parameter
to retrieve the negotiated configuration. The response does not need to retrieve the negotiated configuration. The response does not need
to include 'sid' in its message body. to include 'sid' in its message body.
4.5.3. Configuration Freshness and Notifications 4.5.3. Configuration Freshness and Notifications
skipping to change at page 57, line 23 skipping to change at page 57, line 23
Section 6 of [RFC8085]). The DOTS agent similarly expects a Section 6 of [RFC8085]). The DOTS agent similarly expects a
heartbeat from its peer DOTS agent, and may consider a session heartbeat from its peer DOTS agent, and may consider a session
terminated in the prolonged absence of a peer agent heartbeat. terminated in the prolonged absence of a peer agent heartbeat.
Concretely, while the communication between the DOTS agents is Concretely, while the communication between the DOTS agents is
otherwise quiescent, the DOTS client will probe the DOTS server to otherwise quiescent, the DOTS client will probe the DOTS server to
ensure it has maintained cryptographic state and vice versa. Such ensure it has maintained cryptographic state and vice versa. Such
probes can also keep firewalls and/or stateful translators bindings probes can also keep firewalls and/or stateful translators bindings
alive. This probing reduces the frequency of establishing a new alive. This probing reduces the frequency of establishing a new
handshake when a DOTS signal needs to be conveyed to the DOTS server. handshake when a DOTS signal needs to be conveyed to the DOTS server.
Implementation Note: Given that CoAP roles can be multiplexed over
the same session as discussed in [RFC7252] and already supported
by CoAP implementations, both the DOTS client and server can send
DOTS heartbeat requests.
The DOTS Heartbeat mechanism uses non-confirmable PUT requests
(Figure 27) with an expected 2.04 (Changed) Response Code
(Figure 28). This procedure occurs between a DOTS agent and its
immediate peer DOTS agent. As such, this PUT request MUST NOT be
relayed by a DOTS gateway. The PUT request used for DOTS heartbeat
MUST NOT have a 'cuid', 'cdid,' or 'mid' Uri-Path.
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "hb"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:heartbeat": {
"peer-hb-status": true
}
}
Figure 27: PUT to Check Peer DOTS Agent is Responding
The mandatory 'peer-hb-status' attribute is set to 'true' (or
'false') to indicates that a DOTS agent is (or not) receiving
heartbeat messages from its peer in the last (2 * heartbeat-interval)
period. Such information can be used by a peer DOTS agent to detect
or confirm connectivity issues and react accordingly. For example,
if a DOTS client receives 2.04 response for its heartbeat messages
but no server-initiated heartbeat messages, the DOTS client sets
'peer-hb-status' to 'false'. The DOTS server will need then to try
another strategy for sending the heartbeats (e.g., adjust the
heartbeat interval or send a server-initiated heartbeat immediately
after receiving a client-initiated heartbeat message).
Header: (Code=2.04)
Figure 28: Response to a DOTS Heartbeat Request
DOTS servers MAY trigger their heartbeat requests immediately after DOTS servers MAY trigger their heartbeat requests immediately after
receiving heartbeat probes from peer DOTS clients. As a reminder, it receiving heartbeat probes from peer DOTS clients. As a reminder, it
is the responsibility of DOTS clients to ensure that on-path is the responsibility of DOTS clients to ensure that on-path
translators/firewalls are maintaining a binding so that the same translators/firewalls are maintaining a binding so that the same
external IP address and/or port number is retained for the DOTS external IP address and/or port number is retained for the DOTS
signal channel session. signal channel session.
Under normal traffic conditions (i.e., no attack is ongoing), if a
DOTS agent does not receive any response from the peer DOTS agent for
'missing-hb-allowed' number of consecutive heartbeat messages, it
concludes that the DOTS signal channel session is disconnected. The
DOTS client MUST then try to resume the (D)TLS session.
In case of a massive DDoS attack that saturates the incoming link(s) In case of a massive DDoS attack that saturates the incoming link(s)
to the DOTS client, all traffic from the DOTS server to the DOTS to the DOTS client, all traffic from the DOTS server to the DOTS
client will likely be dropped, although the DOTS server receives client will likely be dropped, although the DOTS server receives
heartbeat requests in addition to DOTS messages sent by the DOTS heartbeat requests in addition to DOTS messages sent by the DOTS
client. In this scenario, DOTS clients MUST behave differently to client. In this scenario, DOTS clients MUST behave differently to
handle message transmission and DOTS signal channel session handle message transmission and DOTS signal channel session
liveliness during link saturation: liveliness during link saturation:
The DOTS client MUST NOT consider the DOTS signal channel session The DOTS client MUST NOT consider the DOTS signal channel session
terminated even after a maximum 'missing-hb-allowed' threshold is terminated even after a maximum 'missing-hb-allowed' threshold is
skipping to change at page 58, line 31 skipping to change at page 59, line 31
DOTS client has not detected the attack or, if an attack mitigation DOTS client has not detected the attack or, if an attack mitigation
is in progress, it implies the applied DDoS mitigation actions are is in progress, it implies the applied DDoS mitigation actions are
not yet effective to handle the DDoS attack volume. not yet effective to handle the DDoS attack volume.
If the DOTS server does not receive any traffic from the peer DOTS If the DOTS server does not receive any traffic from the peer DOTS
client during the time span required to exhaust the maximum 'missing- client during the time span required to exhaust the maximum 'missing-
hb-allowed' threshold, the DOTS server concludes the session is hb-allowed' threshold, the DOTS server concludes the session is
disconnected. The DOTS server can then trigger pre-configured disconnected. The DOTS server can then trigger pre-configured
mitigation requests for this DOTS client (if any). mitigation requests for this DOTS client (if any).
In DOTS over UDP, heartbeat messages MUST be exchanged between the In DOTS over TCP, the sender of a DOTS heartbeat message has to allow
DOTS agents using the "CoAP Ping" mechanism defined in Section 4.2 of up to 'heartbeat-interval' seconds when waiting for a heartbeat
[RFC7252]. reply. When a failure is detected by a DOTS client, it proceeds with
the session recovery following the same approach as the one used for
In DOTS over TCP, heartbeat messages MUST be exchanged between the unreliable transports.
DOTS agents using the Ping and Pong messages specified in Section 5.4
of [RFC8323]. That is, the DOTS agent sends a Ping message and the
peer DOTS agent would respond by sending a single Pong message. The
sender of a Ping message has to allow up to 'heartbeat-interval'
seconds when waiting for a Pong reply. When a failure is detected by
a DOTS client, it proceeds with the session recovery following the
same approach as the one used for unreliable transports.
5. DOTS Signal Channel YANG Modules 5. DOTS Signal Channel YANG Modules
This document defines a YANG [RFC7950] module for DOTS mitigation This document defines a YANG [RFC7950] module for DOTS mitigation
scope, DOTS signal channel session configuration data, and DOTS scope, DOTS signal channel session configuration data, and DOTS
redirection signaling. redirection signaling.
This YANG module (ietf-dots-signal-channel) defines the DOTS client This YANG module (ietf-dots-signal-channel) defines the DOTS client
interaction with the DOTS server as seen by the DOTS client. A DOTS interaction with the DOTS server as seen by the DOTS client. A DOTS
server is allowed to update the non-configurable 'ro' entities in the server is allowed to update the non-configurable 'ro' entities in the
skipping to change at page 60, line 27 skipping to change at page 61, line 19
| +--rw sid uint32 | +--rw sid uint32
| +--rw mitigating-config | +--rw mitigating-config
| | +--rw heartbeat-interval | | +--rw heartbeat-interval
| | | +--ro max-value? uint16 | | | +--ro max-value? uint16
| | | +--ro min-value? uint16 | | | +--ro min-value? uint16
| | | +--rw current-value? uint16 | | | +--rw current-value? uint16
| | +--rw missing-hb-allowed | | +--rw missing-hb-allowed
| | | +--ro max-value? uint16 | | | +--ro max-value? uint16
| | | +--ro min-value? uint16 | | | +--ro min-value? uint16
| | | +--rw current-value? uint16 | | | +--rw current-value? uint16
| | +--rw probing-rate
| | | +--ro max-value? uint16
| | | +--ro min-value? uint16
| | | +--rw current-value? uint16
| | +--rw max-retransmit | | +--rw max-retransmit
| | | +--ro max-value? uint16 | | | +--ro max-value? uint16
| | | +--ro min-value? uint16 | | | +--ro min-value? uint16
| | | +--rw current-value? uint16 | | | +--rw current-value? uint16
| | +--rw ack-timeout | | +--rw ack-timeout
| | | +--ro max-value-decimal? decimal64 | | | +--ro max-value-decimal? decimal64
| | | +--ro min-value-decimal? decimal64 | | | +--ro min-value-decimal? decimal64
| | | +--rw current-value-decimal? decimal64 | | | +--rw current-value-decimal? decimal64
| | +--rw ack-random-factor | | +--rw ack-random-factor
| | +--ro max-value-decimal? decimal64 | | +--ro max-value-decimal? decimal64
skipping to change at page 60, line 48 skipping to change at page 61, line 44
| | +--rw current-value-decimal? decimal64 | | +--rw current-value-decimal? decimal64
| +--rw idle-config | +--rw idle-config
| +--rw heartbeat-interval | +--rw heartbeat-interval
| | +--ro max-value? uint16 | | +--ro max-value? uint16
| | +--ro min-value? uint16 | | +--ro min-value? uint16
| | +--rw current-value? uint16 | | +--rw current-value? uint16
| +--rw missing-hb-allowed | +--rw missing-hb-allowed
| | +--ro max-value? uint16 | | +--ro max-value? uint16
| | +--ro min-value? uint16 | | +--ro min-value? uint16
| | +--rw current-value? uint16 | | +--rw current-value? uint16
| +--rw probing-rate
| | +--ro max-value? uint16
| | +--ro min-value? uint16
| | +--rw current-value? uint16
| +--rw max-retransmit | +--rw max-retransmit
| | +--ro max-value? uint16 | | +--ro max-value? uint16
| | +--ro min-value? uint16 | | +--ro min-value? uint16
| | +--rw current-value? uint16 | | +--rw current-value? uint16
| +--rw ack-timeout | +--rw ack-timeout
| | +--ro max-value-decimal? decimal64 | | +--ro max-value-decimal? decimal64
| | +--ro min-value-decimal? decimal64 | | +--ro min-value-decimal? decimal64
| | +--rw current-value-decimal? decimal64 | | +--rw current-value-decimal? decimal64
| +--rw ack-random-factor | +--rw ack-random-factor
| +--ro max-value-decimal? decimal64 | +--ro max-value-decimal? decimal64
| +--ro min-value-decimal? decimal64 | +--ro min-value-decimal? decimal64
| +--rw current-value-decimal? decimal64 | +--rw current-value-decimal? decimal64
+--:(redirected-signal) +--:(redirected-signal)
+--ro alt-server string | +--ro alt-server string
+--ro alt-server-record* inet:ip-address | +--ro alt-server-record* inet:ip-address
+--:(heartbeat)
+--rw peer-hb-status boolean
5.2. IANA DOTS Signal Channel YANG Module 5.2. IANA DOTS Signal Channel YANG Module
<CODE BEGINS> file "iana-dots-signal-channel@2019-01-17.yang" <CODE BEGINS> file "iana-dots-signal-channel@2019-01-17.yang"
module iana-dots-signal-channel { module iana-dots-signal-channel {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-dots-signal-channel"; namespace "urn:ietf:params:xml:ns:yang:iana-dots-signal-channel";
prefix iana-signal; prefix iana-signal;
organization organization
skipping to change at page 65, line 10 skipping to change at page 66, line 11
"Enumeration for attack status codes."; "Enumeration for attack status codes.";
} }
} }
<CODE ENDS> <CODE ENDS>
5.3. IETF DOTS Signal Channel YANG Module 5.3. IETF DOTS Signal Channel YANG Module
This module uses the common YANG types defined in [RFC6991] and types This module uses the common YANG types defined in [RFC6991] and types
defined in [I-D.ietf-dots-data-channel]. defined in [I-D.ietf-dots-data-channel].
<CODE BEGINS> file "ietf-dots-signal-channel@2019-01-17.yang" <CODE BEGINS> file "ietf-dots-signal-channel@2019-11-13.yang"
module ietf-dots-signal-channel { module ietf-dots-signal-channel {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel"; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel";
prefix signal; prefix signal;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference "Section 4 of RFC 6991"; reference "Section 4 of RFC 6991";
} }
import ietf-yang-types { import ietf-yang-types {
skipping to change at page 66, line 22 skipping to change at page 67, line 24
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
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 2019-01-17 { revision 2019-11-13 {
description description
"Initial revision."; "Initial revision.";
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";
} }
/* /*
* Groupings * Groupings
*/ */
skipping to change at page 71, line 46 skipping to change at page 72, line 47
"Maximum acceptable missing-hb-allowed value."; "Maximum acceptable missing-hb-allowed value.";
} }
leaf min-value { leaf min-value {
type uint16; type uint16;
config false; config false;
description description
"Minimum acceptable missing-hb-allowed value."; "Minimum acceptable missing-hb-allowed value.";
} }
leaf current-value { leaf current-value {
type uint16; type uint16;
default "5"; default "15";
description description
"Current missing-hb-allowed value."; "Current missing-hb-allowed value.";
} }
} }
container probing-rate {
description
"The limit for sending non-confirmable messages with
no response.";
leaf max-value {
type uint16;
units "byte/second";
config false;
description
"Maximum acceptable probing-rate value.";
}
leaf min-value {
type uint16;
units "byte/second";
config false;
description
"Minimum acceptable probing-rate value.";
}
leaf current-value {
type uint16;
units "byte/second";
default "5";
description
"Current probing-rate value.";
}
}
container max-retransmit { container max-retransmit {
description description
"Maximum number of retransmissions of a Confirmable "Maximum number of retransmissions of a Confirmable
message."; message.";
leaf max-value { leaf max-value {
type uint16; type uint16;
config false; config false;
description description
"Maximum acceptable max-retransmit value."; "Maximum acceptable max-retransmit value.";
} }
skipping to change at page 75, line 4 skipping to change at page 76, line 32
A DOTS signal message can be a mitigation, a configuration, A DOTS signal message can be a mitigation, a configuration,
or a redirected signal message."; or a redirected 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, or a redirect
message."; 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;
} }
case redirected-signal { case redirected-signal {
description description
"Redirected signaling."; "Redirected signaling.";
uses redirected-signal; uses redirected-signal;
} }
case heartbeat {
description
"DOTS heartbeats.";
leaf peer-hb-status {
type boolean;
mandatory true;
description
"Indicates whether a DOTS agent receives heartbeats
from its peer.";
}
}
} }
} }
} }
<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.
skipping to change at page 77, line 21 skipping to change at page 79, line 11
| | | | [-2, integer]| String | | | | | [-2, integer]| String |
| idle-config | container | 44 | 5 map | Object | | idle-config | container | 44 | 5 map | Object |
| trigger-mitigation | boolean | 45 | 7 bits 20 | False | | trigger-mitigation | boolean | 45 | 7 bits 20 | False |
| | | | 7 bits 21 | True | | | | | 7 bits 21 | True |
| ietf-dots-signal-cha | | | | | | ietf-dots-signal-cha | | | | |
|nnel:redirected-signal| container | 46 | 5 map | Object | |nnel:redirected-signal| container | 46 | 5 map | Object |
| alt-server | string | 47 | 3 text string | String | | alt-server | string | 47 | 3 text string | String |
| alt-server-record | leaf-list | 48 | 4 array | Array | | alt-server-record | leaf-list | 48 | 4 array | Array |
| | inet: | | | | | | inet: | | | |
| | ip-address | | 3 text string | String | | | ip-address | | 3 text string | String |
| ietf-dots-signal-cha | | | | |
| nnel:heartbeat | container | 49 | 5 map | Object |
| probing-rate | container | 50 | 5 map | Object |
| peer-hb-status | boolean | 51 | 7 bits 20 | False |
| | | | 7 bits 21 | True |
+----------------------+-------------+-----+---------------+--------+ +----------------------+-------------+-----+---------------+--------+
Table 4: CBOR Key Values Used in DOTS Signal Channel Messages & Their Table 4: CBOR Key Values Used in DOTS Signal Channel Messages & Their
Mappings to JSON and YANG Mappings to JSON and YANG
7. (D)TLS Protocol Profile and Performance Considerations 7. (D)TLS Protocol Profile and Performance Considerations
7.1. (D)TLS Protocol Profile 7.1. (D)TLS Protocol Profile
This section defines the (D)TLS protocol profile of DOTS signal This section defines the (D)TLS protocol profile of DOTS signal
skipping to change at page 80, line 34 skipping to change at page 82, line 26
the DOTS client for each configuration request (Section 4.5.2), the DOTS client for each configuration request (Section 4.5.2),
attackers replaying configuration requests with lower numeric attackers replaying configuration requests with lower numeric
'sid' values will be rejected by the DOTS server if it maintains a 'sid' values will be rejected by the DOTS server if it maintains a
higher numeric 'sid' value for this DOTS client. higher numeric 'sid' value for this DOTS client.
Owing to the aforementioned protections, all DOTS signal channel Owing to the aforementioned protections, all DOTS signal channel
requests are safe to transmit in TLS 1.3 as early data. Refer to requests are safe to transmit in TLS 1.3 as early data. Refer to
[I-D.boucadair-dots-earlydata] for more details. [I-D.boucadair-dots-earlydata] for more details.
A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request
message exchange is shown in Figure 27. message exchange is shown in Figure 29.
DOTS Client DOTS Server DOTS Client DOTS Server
ClientHello ClientHello
(0-RTT DOTS signal message) (0-RTT DOTS signal message)
--------> -------->
ServerHello ServerHello
{EncryptedExtensions} {EncryptedExtensions}
{Finished} {Finished}
<-------- [DOTS signal message] <-------- [DOTS signal message]
(end_of_early_data) (end_of_early_data)
{Finished} --------> {Finished} -------->
[DOTS signal message] <-------> [DOTS signal message] [DOTS signal message] <-------> [DOTS signal message]
Note that: Note that:
() 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 29: 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. As a reminder, that the DTLS record fit within a single datagram. As a reminder,
DTLS handles fragmentation and reassembly only for handshake messages DTLS handles fragmentation and reassembly only for handshake messages
and not for the application data (Section 4.1.1 of [RFC6347]). If and not for the application data (Section 4.1.1 of [RFC6347]). If
the PMTU cannot be discovered, DOTS agents MUST assume a PMTU of 1280 the PMTU cannot be discovered, DOTS agents MUST assume a PMTU of 1280
bytes, as IPv6 requires that every link in the Internet have an MTU bytes, as IPv6 requires that every link in the Internet have an MTU
skipping to change at page 83, line 28 skipping to change at page 84, line 34
| +--------------+ | | | | | | +--------------+ | | | | |
| +----+--------+ | +---------------+ | +----+--------+ | +---------------+
| ^ | | ^ |
| | | | | |
| +----------------+ | | | +----------------+ | |
| | DDoS detector | | | | | DDoS detector | | |
| | (DOTS client) +<-------------+ | | | (DOTS client) +<-------------+ |
| +----------------+ | | +----------------+ |
+---------------------------------------------+ +---------------------------------------------+
Figure 28: Example of Authentication and Authorization of DOTS Agents Figure 30: Example of Authentication and Authorization of DOTS Agents
In the example depicted in Figure 28, the DOTS gateway and DOTS In the example depicted in Figure 30, the DOTS gateway and DOTS
clients within the 'example.com' domain mutually authenticate. After clients within the 'example.com' domain mutually authenticate. After
the DOTS gateway validates the identity of a DOTS client, it the DOTS gateway validates the identity of a DOTS client, it
communicates with the AAA server in the 'example.com' domain to communicates with the AAA server in the 'example.com' domain to
determine if the DOTS client is authorized to request DDoS determine if the DOTS client is authorized to request DDoS
mitigation. If the DOTS client is not authorized, a 4.01 mitigation. If the DOTS client is not authorized, a 4.01
(Unauthorized) is returned in the response to the DOTS client. In (Unauthorized) is returned in the response to the DOTS client. In
this example, the DOTS gateway only allows the application server and this example, the DOTS gateway only allows the application server and
DDoS attack detector to request DDoS mitigation, but does not permit DDoS attack detector to request DDoS mitigation, but does not permit
the user of type 'guest' to request DDoS mitigation. the user of type 'guest' to request DDoS mitigation.
Also, DOTS gateways and servers located in different domains must Also, DOTS gateways and servers located in different domains must
perform mutual authentication (e.g., using certificates). A DOTS perform mutual authentication (e.g., using certificates). A DOTS
server will only allow a DOTS gateway with a certificate for a server will only allow a DOTS gateway with a certificate for a
particular domain to request mitigation for that domain. In particular domain to request mitigation for that domain. In
reference to Figure 28, the DOTS server only allows the DOTS gateway reference to Figure 30, the DOTS server only allows the DOTS gateway
to request mitigation for 'example.com' domain and not for other to request mitigation for 'example.com' domain and not for other
domains. domains.
9. IANA Considerations 9. IANA Considerations
9.1. DOTS Signal Channel UDP and TCP Port Number 9.1. DOTS Signal Channel UDP and TCP Port Number
IANA is requested to assign the port number TBD to the DOTS signal IANA is requested to assign the port number TBD to the DOTS signal
channel protocol for both UDP and TCP from the "Service Name and channel protocol for both UDP and TCP from the "Service Name and
Transport Protocol Port Number Registry" available at Transport Protocol Port Number Registry" available at
skipping to change at page 88, line 47 skipping to change at page 89, line 47
| min-value-decimal | 41 | 6tag4 | IESG | [RFCXXXX] | | min-value-decimal | 41 | 6tag4 | IESG | [RFCXXXX] |
| max-value-decimal | 42 | 6tag4 | IESG | [RFCXXXX] | | max-value-decimal | 42 | 6tag4 | IESG | [RFCXXXX] |
| current-value- | 43 | 6tag4 | IESG | [RFCXXXX] | | current-value- | 43 | 6tag4 | IESG | [RFCXXXX] |
| decimal | | | | | | decimal | | | | |
| idle-config | 44 | 5 | IESG | [RFCXXXX] | | idle-config | 44 | 5 | IESG | [RFCXXXX] |
| trigger-mitigation | 45 | 7 | IESG | [RFCXXXX] | | trigger-mitigation | 45 | 7 | IESG | [RFCXXXX] |
| ietf-dots-signal-chan| 46 | 5 | IESG | [RFCXXXX] | | ietf-dots-signal-chan| 46 | 5 | IESG | [RFCXXXX] |
| nel:redirected-signal| | | | | | nel:redirected-signal| | | | |
| alt-server | 47 | 3 | IESG | [RFCXXXX] | | alt-server | 47 | 3 | IESG | [RFCXXXX] |
| alt-server-record | 48 | 4 | IESG | [RFCXXXX] | | alt-server-record | 48 | 4 | IESG | [RFCXXXX] |
| ietf-dots-signal-chan| 49 | 5 | IESG | [RFCXXXX] |
| nel:heartbeat | | | | |
| probing-rate | 50 | 5 | IESG | [RFCXXXX] |
| peer-hb-status | 51 | 7 | IESG | [RFCXXXX] |
+----------------------+-------+-------+------------+---------------+ +----------------------+-------+-------+------------+---------------+
Table 6: Initial DOTS Signal Channel CBOR Key Values Registry Table 6: Initial DOTS Signal Channel CBOR Key Values Registry
9.6.2. Status Codes Sub-Registry 9.6.2. Status Codes Sub-Registry
The document requests IANA to create a new sub-registry, entitled The document requests IANA to create a new sub-registry, entitled
"DOTS Signal Channel Status Codes". Codes in this registry are used "DOTS Signal Channel Status Codes". Codes in this registry are used
as valid values of 'status' parameter. as valid values of 'status' parameter.
The registry is initially populated with the following values: The registry is initially populated with the following values:
skipping to change at page 90, line 29 skipping to change at page 91, line 31
| 7 | attack-mitigation-withdrawn | Attack | [RFCXXXX] | | 7 | attack-mitigation-withdrawn | Attack | [RFCXXXX] |
| | | mitigation | | | | | mitigation | |
| | | is | | | | | is | |
| | | withdrawn. | | | | | withdrawn. | |
| 8 | attack-mitigation-signal-loss | Attack | [RFCXXXX] | | 8 | attack-mitigation-signal-loss | Attack | [RFCXXXX] |
| | | mitigation | | | | | mitigation | |
| | | will be | | | | | will be | |
| | | triggered | | | | | triggered | |
| | | for the | | | | | for the | |
| | | mitigation | | | | | mitigation | |
| | | request only | | | | | request | |
| | | when the | | | | | only when | |
| | | DOTS signal | | | | | the DOTS | |
| | | signal | |
| | | channel | | | | | channel | |
| | | session is | | | | | session is | |
| | | lost. | | | | | lost. | |
+-----+----------------------------------+--------------+-----------+ +-----+----------------------------------+--------------+-----------+
New codes can be assigned via Standards Action [RFC8126]. New codes can be assigned via Standards Action [RFC8126].
9.6.3. Conflict Status Codes Sub-Registry 9.6.3. Conflict Status Codes Sub-Registry
The document requests IANA to create a new sub-registry, entitled The document requests IANA to create a new sub-registry, entitled
skipping to change at page 92, line 21 skipping to change at page 93, line 21
The registry is initially populated with the following values: The registry is initially populated with the following values:
+------+--------------------------+---------------------+-----------+ +------+--------------------------+---------------------+-----------+
| Code | Label | Description | Reference | | Code | Label | Description | Reference |
+------+--------------------------+---------------------+-----------+ +------+--------------------------+---------------------+-----------+
| 1 | overlapping-targets | Overlapping | [RFCXXXX] | | 1 | overlapping-targets | Overlapping | [RFCXXXX] |
| | | targets. | | | | | targets. | |
| 2 | conflict-with-acceptlist | Conflicts with an | [RFCXXXX] | | 2 | conflict-with-acceptlist | Conflicts with an | [RFCXXXX] |
| | | existing accept- | | | | | existing accept- | |
| | | list. This code is | | | | | list. This code is | |
| | | returned when the | | | | | returned | |
| | | DDoS mitigation | | | | | when the DDoS | |
| | | detects source | | | | | mitigation detects | |
| | | source | |
| | | addresses/prefixes | | | | | addresses/prefixes | |
| | | in the accept- | | | | | in the | |
| | | listed ACLs are | | | | | accept-listed ACLs | |
| | | attacking the | | | | | are attacking the | |
| | | target. | | | | | target. | |
| 3 | cuid-collision | CUID Collision. | [RFCXXXX] | | 3 | cuid-collision | CUID Collision. | [RFCXXXX] |
| | | This code is | | | | | This code is | |
| | | returned when a | | | | | returned when a | |
| | | DOTS client uses a | | | | | DOTS client uses a | |
| | | 'cuid' that is | | | | | 'cuid' that is | |
| | | already used by | | | | | already used by | |
| | | another DOTS | | | | | another DOTS | |
| | | client. | | | | | client. | |
+------+--------------------------+---------------------+-----------+ +------+--------------------------+---------------------+-----------+
skipping to change at page 94, line 30 skipping to change at page 95, line 30
statement, and substatements thereof, should be defined: statement, and substatements thereof, should be defined:
"enum": Replicates the label from the registry. "enum": Replicates the label from the registry.
"value": Contains the IANA-assigned value corresponding to the "value": Contains the IANA-assigned value corresponding to the
'status', 'conflict-status', 'conflict-cause', or 'status', 'conflict-status', 'conflict-cause', or
'attack-status'. 'attack-status'.
"description": Replicates the description from the registry. "description": Replicates the description from the registry.
"reference": Replicates the reference from the registry and add the "reference": Replicates the reference from the registry and adds
title of the document. the title of the document.
When the iana-dots-signal-channel YANG module is updated, a new When the iana-dots-signal-channel YANG module is updated, a new
"revision" statement must be added in front of the existing revision "revision" statement must be added in front of the existing revision
statements. statements.
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-
skipping to change at page 97, line 25 skipping to change at page 98, line 25
performing interop testing at IETF Hackathons. performing interop testing at IETF Hackathons.
Thanks to the core WG for the recommendations on Hop-Limit and Thanks to the core WG for the recommendations on Hop-Limit and
redirect signaling. redirect signaling.
Special thanks to Benjamin Kaduk for the detailed AD review. Special thanks to Benjamin Kaduk for the detailed AD review.
Thanks to Alexey Melnikov, Adam Roach, Suresh Krishnan, Mirja Thanks to Alexey Melnikov, Adam Roach, Suresh Krishnan, Mirja
Kuehlewind, and Alissa Cooper for the review. Kuehlewind, and Alissa Cooper for the review.
Thanks to Carsten Bormann for his review of the DOTS heartbeat
mechanism.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-core-hop-limit] [I-D.ietf-core-hop-limit]
Boucadair, M., K, R., and J. Shallow, "Constrained Boucadair, M., K, R., and J. Shallow, "Constrained
Application Protocol (CoAP) Hop-Limit Option", draft-ietf- Application Protocol (CoAP) Hop-Limit Option", draft-ietf-
core-hop-limit-07 (work in progress), October 2019. core-hop-limit-07 (work in progress), October 2019.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
skipping to change at page 101, line 47 skipping to change at page 103, line 8
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
L., and K. Nishizuka, "Use cases for DDoS Open Threat L., and K. Nishizuka, "Use cases for DDoS Open Threat
Signaling", draft-ietf-dots-use-cases-20 (work in Signaling", draft-ietf-dots-use-cases-20 (work in
progress), September 2019. progress), September 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
1.3", draft-ietf-tls-dtls13-32 (work in progress), July 1.3", draft-ietf-tls-dtls13-33 (work in progress), October
2019. 2019.
[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- <http://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- <http://www.iana.org/assignments/core-parameters/core-
 End of changes. 73 change blocks. 
169 lines changed or deleted 295 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/