RFC 9362 PROPOSED STANDARD SECURITY · DDOS · COAP
DOTS Robust Block: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission
Lets DOTS peers negotiate the tuning knobs for sending big messages quickly while a DDoS attack drops packets.
RFC EDITOR
Boucadair, M. and J. Shallow, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission", RFC 9362, DOI 10.17487/RFC9362, February 2023, <https://www.rfc-editor.org/info/rfc9362>.
BIBTEX
@misc{rfc9362,
series = {Request for Comments},
number = 9362,
howpublished = {RFC 9362},
publisher = {RFC Editor},
doi = {10.17487/RFC9362},
url = {https://www.rfc-editor.org/info/rfc9362},
author = {M. Boucadair and J. Shallow},
title = {{Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission}},
pagetotal = 21,
year = 2023,
month = feb,
} RFC text
Contents
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 9362 Orange
Category: Standards Track J. Shallow
ISSN: 2070-1721 February 2023
Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel Configuration Attributes for Robust Block Transmission
Abstract
This document specifies new DDoS Open Threat Signaling (DOTS) signal
channel configuration parameters that can be negotiated between DOTS
peers to enable the use of Q-Block1 and Q-Block2 Constrained
Application Protocol (CoAP) options. These options enable robust and
faster transmission rates for large amounts of data with less packet
interchanges as well as support for faster recovery should any of the
blocks get lost in transmission (especially during DDoS attacks).
Also, this document defines a YANG data model for representing these
new DOTS signal channel configuration parameters. This model
augments the DOTS signal YANG module ("ietf-dots-signal-channel")
defined in RFC 9132.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9362.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction
2. Terminology
3. DOTS Attributes for Robust Block Transmission
4. YANG/JSON Mapping Parameters to CBOR
5. DOTS Robust Block Transmission YANG Module
6. IANA Considerations
6.1. Registry for DOTS Signal Channel CBOR Mappings
6.2. DOTS Robust Block Transmission YANG Module
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252], although
inspired by HTTP, was designed to use UDP instead of TCP. The
message layer of CoAP over UDP includes support for reliable
delivery, simple congestion control, and flow control. The block-
wise transfer [RFC7959] introduced the CoAP Block1 and Block2 options
to handle data records that cannot fit in a single IP packet, to
avoid having to rely on IP fragmentation. The block-wise transfer
was further updated by [RFC8323] for use over TCP, TLS, and
WebSockets.
The CoAP Block1 and Block2 options work well in environments where
there are no or minimal packet losses. These options operate
synchronously where each individual block has to be requested and can
only ask for (or send) the next block when the request for the
previous block has completed. Packet rates, and hence block
transmission rates, are controlled by Round-Trip Times (RTTs).
There is a requirement for these blocks of data to be transmitted at
higher rates under network conditions where there may be asymmetrical
transient packet loss (e.g., responses may get dropped). An example
is when a network is subject to a Distributed Denial of Service
(DDoS) attack and there is a need for DDoS mitigation agents relying
upon CoAP to communicate with each other (e.g., [RFC9244]). As a
reminder, [RFC7959] recommends the use of Confirmable (CON) responses
to handle potential packet loss. However, such a recommendation does
not work with a "flooded pipe" DDoS situation because the returning
ACK packets may not get through.
The block-wise transfer specified in [RFC7959] covers the general
case but falls short in situations where packet loss is highly
asymmetrical. The mechanism specified in [RFC9177] provides features
roughly similar to the Block1/Block2 options but also provides
additional properties that are tailored towards the intended DDoS
Open Threat Signaling (DOTS) transmission. Concretely, [RFC9177]
primarily targets applications such as DOTS that can't use
Confirmable responses to handle potential packet loss and that
support application-specific mechanisms to assess whether the remote
peer is able to handle the messages sent by a CoAP endpoint (e.g.,
DOTS heartbeats as discussed in Section 4.7 of [RFC9132]).
[RFC9177] includes guards to prevent a CoAP agent from overloading
the network by adopting an aggressive sending rate. These guards are
followed in addition to the existing CoAP congestion control as
specified in Section 4.7 of [RFC7252] (mainly PROBING_RATE). Table 1
lists the additional CoAP parameters that are used for the guards
(Section 7.2 of [RFC9177]). Note that NON in this table refers to
Non-confirmable.
+=====================+===================+
| Parameter Name | Default Value |
+=====================+===================+
| MAX_PAYLOADS | 10 |
+---------------------+-------------------+
| NON_MAX_RETRANSMIT | 4 |
+---------------------+-------------------+
| NON_TIMEOUT | 2 s |
+---------------------+-------------------+
| NON_TIMEOUT_RANDOM | between 2-3 s |
+---------------------+-------------------+
| NON_RECEIVE_TIMEOUT | 4 s |
+---------------------+-------------------+
| NON_PROBING_WAIT | between 247-248 s |
+---------------------+-------------------+
| NON_PARTIAL_TIMEOUT | 247 s |
+---------------------+-------------------+
Table 1: Congestion Control Parameters
PROBING_RATE and other transmission parameters are negotiated between
DOTS peers as discussed in Section 4.5.2 of [RFC9132]. Nevertheless,
negotiating the parameters listed in Table 1 is not supported in
[RFC9132]. This document defines new DOTS signal channel attributes,
corresponding to the parameters in Table 1, that are used to
customize the configuration of robust block transmission in a DOTS
context.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Readers should be familiar with the terms and concepts defined in
[RFC7252] and [RFC8612].
The terms "payload" and "body" are defined in [RFC7959]. The term
"payload" is thus used for the content of a single CoAP message
(i.e., a single block being transferred), while the term "body" is
used for the entire resource representation that is being transferred
in a block-wise fashion.
The meanings of the symbols in YANG tree diagrams are defined in
[RFC8340] and [RFC8791].
3. DOTS Attributes for Robust Block Transmission
Section 7.2 of [RFC9177] defines the following parameters that are
used for congestion control purposes:
MAX_PAYLOADS: This parameter represents the maximum number of
payloads that can be transmitted at any one time.
NON_MAX_RETRANSMIT: This parameter represents the maximum number of
times a request for the retransmission of missing payloads can
occur without a response from the remote peer. By default,
NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT
(Section 4.8 of [RFC7252]).
NON_TIMEOUT: This parameter represents the maximum period of delay
between sending sets of MAX_PAYLOADS payloads for the same body.
NON_TIMEOUT has the same value as ACK_TIMEOUT (Section 4.8 of
[RFC7252]).
NON_TIMEOUT_RANDOM: This parameter represents the initial actual
delay between sending the first two MAX_PAYLOADS_SETs of the same
body. It is a random duration between NON_TIMEOUT and
(NON_TIMEOUT * ACK_RANDOM_FACTOR).
NON_RECEIVE_TIMEOUT: This parameter represents the maximum time to
wait for a missing payload before requesting retransmission. By
default, NON_RECEIVE_TIMEOUT has a value of twice NON_TIMEOUT.
NON_PROBING_WAIT: This parameter is used to limit the potential wait
needed when using PROBING_RATE.
NON_PARTIAL_TIMEOUT: This parameter is used for expiring partially
received bodies.
These parameters are used together with the PROBING_RATE parameter,
which in CoAP indicates the average data rate that must not be
exceeded by a CoAP endpoint in sending to a peer endpoint that does
not respond. The single body of blocks will be subjected to
PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets.
If the wait time between sending bodies that are not being responded
to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time
is limited to NON_PROBING_WAIT.
This document augments the "ietf-dots-signal-channel" DOTS signal
YANG module defined in Section 5.3 of [RFC9132] with the following
additional attributes that can be negotiated between DOTS peers to
enable robust and faster transmission:
max-payloads: This attribute echoes the MAX_PAYLOADS parameter
defined in [RFC9177].
This is an optional attribute. If the attribute is supplied in
both 'idle-config' and 'mitigating-config', then it MUST convey
the same value. If the attribute is only provided as part of
'idle-config' (or 'mitigating-config'), then the other definition
(i.e., 'mitigating-config' (or 'idle-config')) MUST be updated to
the same value.
non-max-retransmit: This attribute echoes the NON_MAX_RETRANSMIT
parameter defined in [RFC9177]. The default value of this
attribute is 'max-retransmit'. Note that DOTS uses a default
value of '3' instead of '4' (which is used generically by CoAP for
'max-transmit'; see Section 4.5.2 of [RFC9132] and Section 4.8 of
[RFC7252]).
This is an optional attribute.
non-timeout: This attribute, expressed in seconds, echoes the
NON_TIMEOUT parameter defined in [RFC9177]. The default value of
this attribute is 'ack-timeout'.
This attribute is also used to compute the NON_TIMEOUT_RANDOM
parameter.
This is an optional attribute.
non-receive-timeout: This attribute, expressed in seconds, echoes
the NON_RECEIVE_TIMEOUT parameter defined in [RFC9177]. The
default value of this attribute is twice 'non-timeout'.
This is an optional attribute.
non-probing-wait: This attribute, expressed in seconds, echoes the
NON_PROBING_WAIT parameter defined in [RFC9177].
This is an optional attribute.
non-partial-timeout: This attribute, expressed in seconds, echoes
the NON_PARTIAL_TIMEOUT parameter defined in [RFC9177]. The
default value of this attribute is 247 seconds.
This is an optional attribute.
The tree structure of the "ietf-dots-robust-trans" module (Section 5)
is shown in Figure 1.
module: ietf-dots-robust-trans
augment-structure /dots-signal:dots-signal/dots-signal:message-type
/dots-signal:signal-config
/dots-signal:mitigating-config:
+-- max-payloads
| +-- (direction)?
| | +--:(server-to-client-only)
| | +-- max-value? uint16
| | +-- min-value? uint16
| +-- current-value? uint16
+-- non-max-retransmit
| +-- (direction)?
| | +--:(server-to-client-only)
| | +-- max-value? uint16
| | +-- min-value? uint16
| +-- current-value? uint16
+-- non-timeout
| +-- (direction)?
| | +--:(server-to-client-only)
| | +-- max-value-decimal? decimal64
| | +-- min-value-decimal? decimal64
| +-- current-value-decimal? decimal64
+-- non-receive-timeout
| +-- (direction)?
| | +--:(server-to-client-only)
| | +-- max-value-decimal? decimal64
| | +-- min-value-decimal? decimal64
| +-- current-value-decimal? decimal64
+-- non-probing-wait
| +-- (direction)?
| | +--:(server-to-client-only)
| | +-- max-value-decimal? decimal64
| | +-- min-value-decimal? decimal64
| +-- current-value-decimal? decimal64
+-- non-partial-timeout:
+-- (direction)?
| +--:(server-to-client-only)
| +-- max-value-decimal? decimal64
| +-- min-value-decimal? decimal64
+-- current-value-decimal? decimal64
augment-structure /dots-signal:dots-signal/dots-signal:message-type
/dots-signal:signal-config
/dots-signal:idle-config:
+-- max-payloads
| +-- (direction)?
| | +--:(server-to-client-only)
| | +-- max-value? uint16
| | +-- min-value? uint16
| +-- current-value? uint16
+-- non-max-retransmit
| +-- (direction)?
| | +--:(server-to-client-only)
| | +-- max-value? uint16
| | +-- min-value? uint16
| +-- current-value? uint16
+-- non-timeout
| +-- (direction)?
| | +--:(server-to-client-only)
| | +-- max-value-decimal? decimal64
| | +-- min-value-decimal? decimal64
| +-- current-value-decimal? decimal64
+-- non-receive-timeout
| +-- (direction)?
| | +--:(server-to-client-only)
| | +-- max-value-decimal? decimal64
| | +-- min-value-decimal? decimal64
| +-- current-value-decimal? decimal64
+-- non-probing-wait
| +-- (direction)?
| | +--:(server-to-client-only)
| | +-- max-value-decimal? decimal64
| | +-- min-value-decimal? decimal64
| +-- current-value-decimal? decimal64
+-- non-partial-timeout:
+-- (direction)?
| +--:(server-to-client-only)
| +-- max-value-decimal? decimal64
| +-- min-value-decimal? decimal64
+-- current-value-decimal? decimal64
Figure 1: DOTS Fast Block Transmission Tree Structure
These attributes are mapped to Concise Binary Object Representation
(CBOR) types as specified in Section 4 and in Section 6 of [RFC9132].
DOTS clients follow the procedure specified in Section 4.5 of
[RFC9132] to negotiate, configure, and retrieve the DOTS signal
channel session behavior (including Q-Block parameters) with DOTS
peers.
Implementation Note 1: 'non-probing-wait' ideally should be left
having some jitter and so should not be hard-coded with an
explicit value. It is suggested to use a base value (using
NON_TIMEOUT instead of NON_TIMEOUT_RANDOM); the jitter
(ACK_RANDOM_FACTOR - 1) is then added to each time the value is
checked.
Implementation Note 2: If any of the signal channel session
configuration parameters is updated, the 'non-probing-wait' and
'non-partial-timeout' values should be recalculated according to
the definition algorithms provided in Section 7.2 of [RFC9177]
unless explicit values are provided as part of the negotiated
configuration.
An example of a PUT message to configure Q-Block parameters is
depicted in Figure 2. In this example, a non-default value is
configured for the 'max-payloads' attribute, while default values are
used for 'non-max-retransmit', 'non-timeout', and 'non-receive-
timeout' in both idle and mitigation times. Given that 'non-probing-
wait' and 'non-partial-timeout' are not explicitly configured in this
example, these attributes will be computed following the algorithms
provided in Section 7.2 of [RFC9177]. The meanings of the other
attributes are detailed in Section 4.5 of [RFC9132].
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "config"
Uri-Path: "sid=123"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:signal-config": {
"mitigating-config": {
"heartbeat-interval": {
"current-value": 30
},
"missing-hb-allowed": {
"current-value": 15
},
"probing-rate": {
"current-value": 15
},
"max-retransmit": {
"current-value": 3
},
"ack-timeout": {
"current-value-decimal": "2.00"
},
"ack-random-factor": {
"current-value-decimal": "1.50"
},
"ietf-dots-robust-trans:max-payloads": {
"current-value": 15
},
"ietf-dots-robust-trans:non-max-retransmit": {
"current-value": 3
},
"ietf-dots-robust-trans:non-timeout": {
"current-value-decimal": "2.00"
},
"ietf-dots-robust-trans:non-receive-timeout": {
"current-value-decimal": "4.00"
}
},
"idle-config": {
"heartbeat-interval": {
"current-value": 0
},
"max-retransmit": {
"current-value": 3
},
"ack-timeout": {
"current-value-decimal": "2.00"
},
"ack-random-factor": {
"current-value-decimal": "1.50"
},
"ietf-dots-robust-trans:max-payloads": {
"current-value": 15
},
"ietf-dots-robust-trans:non-max-retransmit": {
"current-value": 3
},
"ietf-dots-robust-trans:non-timeout": {
"current-value-decimal": "2.00"
},
"ietf-dots-robust-trans:non-receive-timeout": {
"current-value-decimal": "4.00"
}
}
}
}
Figure 2: Example of PUT to Convey the Configuration Parameters
The payload of the message depicted in Figure 2 is CBOR-encoded as
indicated by the Content-Format set to "application/dots+cbor"
(Section 10.4 of [RFC9132]). However, and for the sake of better
readability, the example uses JSON encoding of YANG-modeled data
following the mapping tables in Section 4 and in Section 6 of
[RFC9132]: use the JSON names and types defined in Section 4. These
conventions are inherited from [RFC9132].
4. YANG/JSON Mapping Parameters to CBOR
The YANG/JSON mapping parameters to CBOR are listed in Table 2.
Note: Implementers must check that the mapping output provided by
their YANG-to-CBOR encoding schemes is aligned with the content of
Table 2.
+====================+===========+=======+=================+========+
| Parameter Name | YANG Type | CBOR | CBOR Major Type | JSON |
| | | Key | & Information | Type |
+====================+===========+=======+=================+========+
| ietf-dots-robust- | container | 32776 | 5 map | Object |
| trans:max- | | | | |
| payloads | | | | |
+--------------------+-----------+-------+-----------------+--------+
| ietf-dots-robust- | container | 32777 | 5 map | Object |
| trans:non-max- | | | | |
| retransmit | | | | |
+--------------------+-----------+-------+-----------------+--------+
| ietf-dots-robust- | container | 32778 | 5 map | Object |
| trans:non-timeout | | | | |
+--------------------+-----------+-------+-----------------+--------+
| ietf-dots-robust- | container | 32779 | 5 map | Object |
| trans:non- | | | | |
| receive-timeout | | | | |
+--------------------+-----------+-------+-----------------+--------+
| ietf-dots-robust- | container | 32780 | 5 map | Object |
| trans:non- | | | | |
| probing-wait | | | | |
+--------------------+-----------+-------+-----------------+--------+
| ietf-dots-robust- | container | 32781 | 5 map | Object |
| trans:non- | | | | |
| partial-timeout | | | | |
+--------------------+-----------+-------+-----------------+--------+
Table 2: YANG/JSON Mapping Parameters to CBOR
5. DOTS Robust Block Transmission YANG Module
This module uses the data structure extension defined in [RFC8791].
<CODE BEGINS> file "ietf-dots-robust-trans@2023-02-28.yang"
module ietf-dots-robust-trans {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans";
prefix dots-robust;
import ietf-dots-signal-channel {
prefix dots-signal;
reference
"RFC 9132: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification";
}
import ietf-yang-structure-ext {
prefix sx;
reference
"RFC 8791: YANG Data Structure Extensions";
}
organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org>
Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>;
Author: Jon Shallow
<mailto:ietf-supjps@jpshallow.com>";
description
"This module contains YANG definitions for the configuration
of parameters that can be negotiated between a DOTS client
and a DOTS server for robust block transmission.
Copyright (c) 2023 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9362; see the
RFC itself for full legal notices.";
revision 2023-02-28 {
description
"Initial revision.";
reference
"RFC 9362: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Configuration Attributes
for Robust Block Transmission";
}
grouping robust-transmission-attributes {
description
"A set of DOTS signal channel session configuration
parameters that are negotiated between DOTS agents when
making use of Q-Block1 and Q-Block2 options.";
container max-payloads {
description
"Indicates the maximum number of payloads that
can be transmitted at any one time.";
choice direction {
description
"Indicates the communication direction in which the
data nodes can be included.";
case server-to-client-only {
description
"These data nodes appear only in a message sent
from the server to the client.";
leaf max-value {
type uint16;
description
"Maximum acceptable 'max-payloads' value.";
}
leaf min-value {
type uint16;
description
"Minimum acceptable 'max-payloads' value.";
}
}
}
leaf current-value {
type uint16;
default "10";
description
"Current 'max-payloads' value.";
reference
"RFC 9177: Constrained Application Protocol (CoAP)
Block-Wise Transfer Options Supporting
Robust Transmission, Section 7.2";
}
}
container non-max-retransmit {
description
"Indicates the maximum number of times a request
for the retransmission of missing payloads can
occur without a response from the remote peer.";
choice direction {
description
"Indicates the communication direction in which the
data nodes can be included.";
case server-to-client-only {
description
"These data nodes appear only in a message sent
from the server to the client.";
leaf max-value {
type uint16;
description
"Maximum acceptable 'non-max-retransmit' value.";
}
leaf min-value {
type uint16;
description
"Minimum acceptable 'non-max-retransmit' value.";
}
}
}
leaf current-value {
type uint16;
default "3";
description
"Current 'non-max-retransmit' value.";
reference
"RFC 9177: Constrained Application Protocol (CoAP)
Block-Wise Transfer Options Supporting
Robust Transmission, Section 7.2";
}
}
container non-timeout {
description
"Indicates the maximum period of delay between
sending sets of MAX_PAYLOADS payloads for the same
body.";
choice direction {
description
"Indicates the communication direction in which the
data nodes can be included.";
case server-to-client-only {
description
"These data nodes appear only in a message sent
from the server to the client.";
leaf max-value-decimal {
type decimal64 {
fraction-digits 2;
}
units "seconds";
description
"Maximum 'ack-timeout' value.";
}
leaf min-value-decimal {
type decimal64 {
fraction-digits 2;
}
units "seconds";
description
"Minimum 'ack-timeout' value.";
}
}
}
leaf current-value-decimal {
type decimal64 {
fraction-digits 2;
}
units "seconds";
default "2.00";
description
"Current 'ack-timeout' value.";
reference
"RFC 9177: Constrained Application Protocol (CoAP)
Block-Wise Transfer Options Supporting
Robust Transmission, Section 7.2";
}
}
container non-receive-timeout {
description
"Indicates the time to wait for a missing payload
before requesting retransmission.";
choice direction {
description
"Indicates the communication direction in which the
data nodes can be included.";
case server-to-client-only {
description
"These data nodes appear only in a message sent
from the server to the client.";
leaf max-value-decimal {
type decimal64 {
fraction-digits 2;
}
units "seconds";
description
"Maximum 'non-receive-timeout' value.";
}
leaf min-value-decimal {
type decimal64 {
fraction-digits 2;
}
units "seconds";
description
"Minimum 'non-receive-timeout' value.";
}
}
}
leaf current-value-decimal {
type decimal64 {
fraction-digits 2;
}
units "seconds";
default "4.00";
description
"Current 'non-receive-timeout' value.";
reference
"RFC 9177: Constrained Application Protocol (CoAP)
Block-Wise Transfer Options Supporting
Robust Transmission, Section 7.2";
}
}
container non-probing-wait {
description
"Used to limit the potential wait needed when
using 'probing-rate'.";
choice direction {
description
"Indicates the communication direction in which the
data nodes can be included.";
case server-to-client-only {
description
"These data nodes appear only in a message sent
from the server to the client.";
leaf max-value-decimal {
type decimal64 {
fraction-digits 2;
}
units "seconds";
description
"Maximum 'non-probing-wait' value.";
}
leaf min-value-decimal {
type decimal64 {
fraction-digits 2;
}
units "seconds";
description
"Minimum 'non-probing-wait' value.";
}
}
}
leaf current-value-decimal {
type decimal64 {
fraction-digits 2;
}
units "seconds";
description
"Current 'non-probing-wait' value.";
reference
"RFC 9177: Constrained Application Protocol (CoAP)
Block-Wise Transfer Options Supporting
Robust Transmission, Section 7.2";
}
}
container non-partial-timeout {
description
"Used for expiring partially received bodies.";
choice direction {
description
"Indicates the communication direction in which the
data nodes can be included.";
case server-to-client-only {
description
"These data nodes appear only in a message sent
from the server to the client.";
leaf max-value-decimal {
type decimal64 {
fraction-digits 2;
}
units "seconds";
description
"Maximum 'non-partial-timeout' value.";
}
leaf min-value-decimal {
type decimal64 {
fraction-digits 2;
}
units "seconds";
description
"Minimum 'non-partial-timeout' value.";
}
}
}
leaf current-value-decimal {
type decimal64 {
fraction-digits 2;
}
units "seconds";
default "247.00";
description
"Current 'non-partial-timeout' value.";
reference
"RFC 9177: Constrained Application Protocol (CoAP)
Block-Wise Transfer Options Supporting
Robust Transmission, Section 7.2";
}
}
}
sx:augment-structure "/dots-signal:dots-signal"
+ "/dots-signal:message-type"
+ "/dots-signal:signal-config"
+ "/dots-signal:mitigating-config" {
description
"Indicates DOTS configuration attributes to use for
robust transmission when a mitigation is active.";
uses robust-transmission-attributes;
}
sx:augment-structure "/dots-signal:dots-signal"
+ "/dots-signal:message-type"
+ "/dots-signal:signal-config"
+ "/dots-signal:idle-config" {
description
"Indicates DOTS configuration parameters to use for
robust transmission when no mitigation is active.";
uses robust-transmission-attributes;
}
}
<CODE ENDS>
6. IANA Considerations
6.1. Registry for DOTS Signal Channel CBOR Mappings
This specification registers the following parameters in the IANA
"DOTS Signal Channel CBOR Key Values" registry [Key-Map].
+===================+==========+=======+============+===============+
| Parameter Name | CBOR | CBOR | Change | Specification |
| | Key | Major | Controller | Document(s) |
| | Value | Type | | |
+===================+==========+=======+============+===============+
| ietf-dots-robust- | 32776 | 5 | IESG | RFC 9362 |
| trans:max- | | | | |
| payloads | | | | |
+-------------------+----------+-------+------------+---------------+
| ietf-dots-robust- | 32777 | 5 | IESG | RFC 9362 |
| trans:non-max- | | | | |
| retransmit | | | | |
+-------------------+----------+-------+------------+---------------+
| ietf-dots-robust- | 32778 | 5 | IESG | RFC 9362 |
| trans:non-timeout | | | | |
+-------------------+----------+-------+------------+---------------+
| ietf-dots-robust- | 32779 | 5 | IESG | RFC 9362 |
| trans:non- | | | | |
| receive-timeout | | | | |
+-------------------+----------+-------+------------+---------------+
| ietf-dots-robust- | 32780 | 5 | IESG | RFC 9362 |
| trans:non- | | | | |
| probing-wait | | | | |
+-------------------+----------+-------+------------+---------------+
| ietf-dots-robust- | 32781 | 5 | IESG | RFC 9362 |
| trans:non- | | | | |
| partial-timeout | | | | |
+-------------------+----------+-------+------------+---------------+
Table 3: DOTS Robust Block Transmission CBOR Mappings
6.2. DOTS Robust Block Transmission YANG Module
IANA has registered the following URI in the "ns" subregistry within
the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
IANA has registered the following YANG module in the "YANG Module
Names" subregistry [RFC6020] within the "YANG Parameters" registry.
Name: ietf-dots-robust-trans
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans
Maintained by IANA? N
Prefix: dots-robust
Reference: RFC 9362
7. Security Considerations
The security considerations for the DOTS signal channel protocol are
discussed in Section 11 of [RFC9132].
CoAP-specific security considerations are discussed in Section 11 of
[RFC9177].
Consistent with Section 5 of [RFC9132], the "ietf-dots-robust-trans"
module is not intended to be used via NETCONF/RESTCONF. It serves as
an abstract representation in DOTS signal channel messages. The
"ietf-dots-robust-trans" module does not introduce any new
vulnerabilities beyond those specified above.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/info/rfc7959>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>.
[RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data
Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
June 2020, <https://www.rfc-editor.org/info/rfc8791>.
[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K,
"Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification", RFC 9132,
DOI 10.17487/RFC9132, September 2021,
<https://www.rfc-editor.org/info/rfc9132>.
[RFC9177] Boucadair, M. and J. Shallow, "Constrained Application
Protocol (CoAP) Block-Wise Transfer Options Supporting
Robust Transmission", RFC 9177, DOI 10.17487/RFC9177,
March 2022, <https://www.rfc-editor.org/info/rfc9177>.
8.2. Informative References
[Key-Map] IANA, "DOTS Signal Channel CBOR Key Values",
<https://www.iana.org/assignments/dots/>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
Threat Signaling (DOTS) Requirements", RFC 8612,
DOI 10.17487/RFC8612, May 2019,
<https://www.rfc-editor.org/info/rfc8612>.
[RFC9244] Boucadair, M., Ed., Reddy.K, T., Ed., Doron, E., Chen, M.,
and J. Shallow, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry", RFC 9244,
DOI 10.17487/RFC9244, June 2022,
<https://www.rfc-editor.org/info/rfc9244>.
Acknowledgements
Thanks to Tiru Reddy, Meiling Chen, and Kaname Nishizuka for the
review.
Thanks to Michal Vaško for the yangdoctors review.
Thanks to Valery Smyslov for shepherding the document, Paul Wouters
for the AD review, Paul Kyzivat for the artart directorate review,
Tim Evens for the Gen-ART review, and Jean-Michel Combes for the int-
dir review.
Thanks to John Scudder, Lars Eggert, Éric Vyncke, Roman Danyliw, Rob
Wilton, and Martin Duke for their comments during the IESG review.
Authors' Addresses
Mohamed Boucadair
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com
Jon Shallow
United Kingdom
Email: supjps-ietf@jpshallow.com
AI ELI5
On this page
PROBLEMDOTS peers must exchange large messages while a DDoS attack may be dropping packets, but the standard CoAP block-wise options send one block at a time and rely on acknowledgements that may never get through.
MECHANISMRFC 9362 adds six optional configuration attributes to the DOTS signal channel (max-payloads, non-max-retransmit, non-timeout, non-receive-timeout, non-probing-wait, non-partial-timeout) so peers can negotiate the parameters of the Q-Block1 and Q-Block2 options, and it defines a YANG module and CBOR keys for them.
WHY IT MATTERSDOTS clients and servers can tune robust block transmission using the same negotiation procedure they already use for other signal channel parameters, with no new vulnerabilities beyond those of DOTS and CoAP.
§1Why Block Transfer Needs Tuning
The Constrained Application Protocol (CoAP) runs over UDP. Its Block1 and Block2 options, from RFC 7959, split data that does not fit in one IP packet into blocks. They work well when there is little or no packet loss, but they are synchronous: each block must be requested, and the next one can only be asked for or sent once the previous one has completed. Block rates are therefore controlled by round-trip times.
That is a poor fit for a network under a Distributed Denial of Service (DDoS) attack, where responses may be dropped in only one direction. RFC 7959 recommends Confirmable responses to cope with loss, but in a flooded-pipe situation the returning ACK packets may not get through. RFC 9177 defines the Q-Block1 and Q-Block2 options for applications such as DOTS that cannot use Confirmable responses, and it adds guards so that a CoAP agent does not overload the network.
The gap this document fills: RFC 9132 lets DOTS peers negotiate transmission parameters such as PROBING_RATE, but it does not cover the extra congestion control parameters that RFC 9177 introduces. RFC 9362 adds signal channel attributes for them.
Normal block sending is like passing one note at a time and waiting for a thank-you before the next. That is slow when the mail room is flooded, so the sides need a way to agree on a faster, sturdier routine.
§2The Congestion Control Parameters
Section 7.2 of RFC 9177 defines the parameters that guard against aggressive sending. RFC 9362 describes each one and gives the defaults shown in its Table 1.
MAX_PAYLOADS(default 10): the maximum number of payloads that can be transmitted at any one time.NON_MAX_RETRANSMIT(default 4): the maximum number of times a request to retransmit missing payloads can occur without a response from the remote peer.NON_TIMEOUT(default 2 s): the maximum delay between sending sets ofMAX_PAYLOADSpayloads for the same body.NON_TIMEOUT_RANDOM(between 2 and 3 s): the initial actual delay between sending the first two sets of the same body.NON_RECEIVE_TIMEOUT(default 4 s): the maximum time to wait for a missing payload before requesting retransmission, by default twiceNON_TIMEOUT.NON_PROBING_WAIT(between 247 and 248 s): limits the wait needed when usingPROBING_RATE.NON_PARTIAL_TIMEOUT(247 s): used for expiring partially received bodies.
These work together with PROBING_RATE, which in CoAP is the average data rate that must not be exceeded when sending to a peer that does not respond. The whole body of blocks is subject to PROBING_RATE, not the individual packets. If the wait between bodies exceeds NON_PROBING_WAIT, the wait is capped at that value.
These are the rules of a careful sender: how many boxes to send at once, how long to wait before asking about a missing one, and when to give up on a half-finished delivery.
§3The New Signal Channel Attributes
RFC 9362 augments the ietf-dots-signal-channel YANG module from RFC 9132 with six attributes, each of which echoes one of the parameters above: max-payloads, non-max-retransmit, non-timeout, non-receive-timeout, non-probing-wait and non-partial-timeout. All are optional. Time-valued attributes are expressed in seconds.
Defaults differ slightly from plain CoAP in places. non-max-retransmit defaults to max-retransmit, and the text notes that DOTS uses 3 rather than the 4 CoAP uses generically. non-timeout defaults to ack-timeout, non-receive-timeout defaults to twice non-timeout, and non-partial-timeout defaults to 247 seconds.
If max-payloads is supplied in both idle-config and mitigating-config, the two values MUST be the same. If it appears in only one of them, the other MUST be updated to the same value.
DOTS clients negotiate, configure and retrieve these values using the procedure in Section 4.5 of RFC 9132. Two implementation notes apply: non-probing-wait should keep some jitter rather than be hard-coded, and when any session configuration parameter changes, non-probing-wait and non-partial-timeout should be recalculated per RFC 9177 unless explicit values were negotiated.
The two sides already chat about their settings. This document just adds six more settings to that chat, all optional, so each side can say what it prefers.
§4The YANG Module and Tree
The module is named ietf-dots-robust-trans and uses the data structure extension from RFC 8791. It augments both the mitigating-config and idle-config parts of the signal channel configuration.
Each attribute is a container holding a current-value (or current-value-decimal for the time-based ones). A direction choice with a server-to-client-only case adds max-value and min-value, which appear only in messages from the server to the client and tell the client the acceptable range. Integer attributes use uint16; time attributes use decimal64 with two fraction digits and the unit seconds.
Section 5 of RFC 9132 says the module is not meant to be used via NETCONF or RESTCONF. It serves as an abstract representation of what is carried in DOTS signal channel messages.
A YANG module is a tidy form that says exactly what each setting is called and what kind of value it holds, so both sides read it the same way.
- 32776max-payloads — Maximum payloads transmitted at one time.
- 32777non-max-retransmit — Maximum retransmission requests without a response.
- 32778non-timeout — Maximum delay between sets of payloads.
- 32779non-receive-timeout — Time to wait for a missing payload.
- 32780non-probing-wait — Limits the wait when using PROBING_RATE.
- 32781non-partial-timeout — Expires partially received bodies.
§5Encoding and a Worked Example
On the wire, the messages are CBOR. Each new container is mapped to a CBOR key of major type 5 (a map): max-payloads is 32776, non-max-retransmit 32777, non-timeout 32778, non-receive-timeout 32779, non-probing-wait 32780 and non-partial-timeout 32781. Implementers must check that their YANG-to-CBOR encoder output matches the RFC's table.
The RFC shows a CoAP PUT to .well-known/dots/config/sid=123 with content format application/dots+cbor. It sets a non-default max-payloads of 15 in both idle and mitigating configuration, and leaves non-max-retransmit, non-timeout and non-receive-timeout at their defaults. Because non-probing-wait and non-partial-timeout are not given, they are computed by the algorithms in RFC 9177. The example is written in JSON for readability, following the mapping tables of RFC 9132.
Each new setting gets a number label so it can be sent in a compact form. The example shows one side asking to send 15 boxes at a time and keeping everything else normal.
§6Security and IANA Notes
The security considerations of the DOTS signal channel are in Section 11 of RFC 9132, and CoAP-specific ones are in Section 11 of RFC 9177. RFC 9362 states that its module does not introduce any new vulnerabilities beyond those.
For IANA, the six CBOR keys (32776 to 32781) are registered in the DOTS Signal Channel CBOR Key Values registry, with the IESG as change controller. IANA has also registered the XML namespace urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans and the YANG module ietf-dots-robust-trans with prefix dots-robust.
Adding these settings does not open any new doors for attackers. The numbers and names were also written into the official public lists so nobody else reuses them.
§7References
[RFC7252]RFC 7252Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014.June 2014[RFC7959]RFC 7959Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, August 2016.August 2016[RFC9132]RFC 9132Boucadair, M., Ed., Shallow, J., and T. Reddy.K, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 9132, September 2021.September 2021[RFC9177]RFC 9177Boucadair, M. and J. Shallow, "Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission", RFC 9177, March 2022.March 2022[RFC9244]RFC 9244Boucadair, M., Ed., Reddy.K, T., Ed., Doron, E., Chen, M., and J. Shallow, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry", RFC 9244, June 2022.June 2022[RFC8791]RFC 8791Bierman, A., Bjorklund, M., and K. Watsen, "YANG Data Structure Extensions", RFC 8791, June 2020.June 2020