<?xml version="1.0"encoding="US-ASCII"?>encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="4"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-dots-robust-blocks-06"ipr="trust200902">number="9362" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.15.0 --> <front> <title abbrev="DOTS Robust Block Transmission">Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission</title> <seriesInfo name="RFC" value="9362"/> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <organization>Orange</organization> <address> <postal><street></street><street/> <city>Rennes</city><region></region><region/> <code>35000</code> <country>France</country> </postal> <email>mohamed.boucadair@orange.com</email> </address> </author> <author fullname="Jon Shallow" initials="J." surname="Shallow"><organization></organization><organization/> <address> <postal><street></street> <city></city> <region></region> <code></code><street/> <city/> <region/> <code/> <country>United Kingdom</country> </postal> <email>supjps-ietf@jpshallow.com</email> </address> </author> <date year="2023" month="February" /><workgroup>DOTS</workgroup><area>sec</area> <workgroup>dots</workgroup> <keyword>Quick-Block</keyword> <keyword>Robust-Block</keyword> <keyword>R-Block</keyword> <keyword>Tough-Block</keyword> <keyword>Resilient-Block</keyword> <keyword>Fast-Block</keyword> <keyword>Resilience</keyword> <keyword>Filtering</keyword> <keyword>Faster transmission</keyword> <keyword>Large amounts of data</keyword> <keyword>Less packet interchange</keyword> <keyword>Fast recovery</keyword> <abstract> <t>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-Block2CoAPConstrained Application Protocol (CoAP) options. These options enable robust and faster transmission rates for large amounts of data with less packet interchanges as well assupportingsupport for faster recovery should any of the blocks get lost in transmission(especially,(especially during DDoS attacks).</t> <t>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.</t> </abstract> </front> <middle> <section anchor="introduction"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>The Constrained Application Protocol (CoAP) <xreftarget="RFC7252"></xref>,target="RFC7252" format="default"/>, 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 <xreftarget="RFC7959"></xref>target="RFC7959" format="default"/> introduced the CoAP Block1 and Block2 options to handle data records that cannot fit in a single IP packet,so notto avoid having to rely on IP fragmentation. The block-wise transfer was further updated by <xreftarget="RFC8323"></xref>target="RFC8323" format="default"/> for use over TCP, TLS, and WebSockets.</t> <t>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,Packet rates, and hence block transmissionrate, isrates, are controlled by Round-Trip Times (RTTs).</t> <t>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., <xreftarget="RFC9244"></xref>).target="RFC9244" format="default"/>). As a reminder, <xreftarget="RFC7959"></xref>target="RFC7959" format="default"/> recommends the use of Confirmable (CON) responses to handle potential packet loss. However, such a recommendation does not work with aflooded pipe"flooded pipe" DDoS situation because the returning ACK packets may not get through.</t> <t>The block-wise transfer specified in <xreftarget="RFC7959"></xref>target="RFC7959" format="default"/> covers the generalcase,case but falls short in situations where packet loss is highly asymmetrical. The mechanism specified in <xreftarget="RFC9177"></xref>target="RFC9177" format="default"/> provides features roughly similarfeaturesto the Block1/Block2options,options but also provides additional properties that are tailored towards the intended DDoS Open Threat Signaling (DOTS) transmission. Concretely, <xreftarget="RFC9177"></xref>target="RFC9177" format="default"/> 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 inSection 4.7 of<xreftarget="RFC9132"></xref>).</t>target="RFC9132" sectionFormat="of" section="4.7"/>).</t> <t><xreftarget="RFC9177"></xref>target="RFC9177" format="default"/> 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 inSection 4.7 of<xreftarget="RFC7252"></xref> (mainly,target="RFC7252" sectionFormat="of" section="4.7"/> (mainly PROBING_RATE).Table 1<xref target="tab-1"/> lists the additional CoAP parameters that are used for the guards(Section 7.2 of <xref target="RFC9177"></xref>).(<xref target="RFC9177" sectionFormat="of" section="7.2"/>). Note that NON in this table refers to Non-confirmable.</t><t><figure align="center"> <artwork align="center"><![CDATA[+---------------------+-------------------+ | Parameter Name | Default Value | +=====================+===================+ | MAX_PAYLOADS | 10 | | NON_MAX_RETRANSMIT | 4 | | NON_TIMEOUT | 2 s | | NON_TIMEOUT_RANDOM | between<table anchor="tab-1"> <name>Congestion Control Parameters</name> <thead> <tr> <th>Parameter Name</th> <th>Default Value</th> </tr> </thead> <tbody> <tr> <td>MAX_PAYLOADS</td> <td>10</td> </tr> <tr> <td>NON_MAX_RETRANSMIT</td> <td>4</td> </tr> <tr> <td>NON_TIMEOUT</td> <td>2 s</td> </tr> <tr> <td>NON_TIMEOUT_RANDOM</td> <td>between 2-3s | | NON_RECEIVE_TIMEOUT | 4 s | | NON_PROBING_WAIT | betweens</td> </tr> <tr> <td>NON_RECEIVE_TIMEOUT</td> <td>4 s</td> </tr> <tr> <td>NON_PROBING_WAIT</td> <td>between 247-248s | | NON_PARTIAL_TIMEOUT | 247 s | +---------------------+-------------------+ Table 1: Congestion Control Parameters]]></artwork> </figure></t>s</td> </tr> <tr> <td>NON_PARTIAL_TIMEOUT</td> <td>247 s</td> </tr> </tbody> </table> <t>PROBING_RATE and other transmission parameters are negotiated between DOTS peers as discussed inSection 4.5.2 of<xreftarget="RFC9132"></xref>.target="RFC9132" sectionFormat="of" section="4.5.2"/>. Nevertheless, negotiating the parameters listed inTable 1<xref target="tab-1"/> is not supported in <xreftarget="RFC9132"></xref>.target="RFC9132" format="default"/>. This document defines new DOTS signal channel attributes, corresponding to the parameters inTable 1,<xref target="tab-1"/>, that are used to customize the configuration of robust block transmission in a DOTS context.</t> </section> <section anchor="notation"title="Terminology">numbered="true" toc="default"> <name>Terminology</name> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119"></xref>target="RFC2119"/> <xreftarget="RFC8174"></xref>target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> <t>Readers should be familiar with the terms and concepts defined in <xreftarget="RFC7252"></xref>target="RFC7252" format="default"/> and <xreftarget="RFC8612"></xref>.</t>target="RFC8612" format="default"/>.</t> <t>The terms "payload" and "body" are defined in <xreftarget="RFC7959"></xref>.target="RFC7959" format="default"/>. 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.</t> <t>Themeaningmeanings of the symbols in YANG tree diagrams are defined in <xreftarget="RFC8340"></xref>target="RFC8340" format="default"/> and <xreftarget="RFC8791"></xref>.</t>target="RFC8791" format="default"/>.</t> </section> <section anchor="new"title="DOTSnumbered="true" toc="default"> <name>DOTS Attributes for Robust BlockTransmission"> <t>Section 7.2 of <xref target="RFC9177"></xref>Transmission</name> <t><xref target="RFC9177" sectionFormat="of" section="7.2"/> defines the following parameters that are used for congestion controlpurposes:<list style="hanging"> <t hangText="MAX_PAYLOADS:">ispurposes:</t> <dl newline="false" spacing="normal"> <dt>MAX_PAYLOADS:</dt> <dd>This parameter represents the maximum number of payloads that can be transmitted at any onetime.</t> <t hangText="NON_MAX_RETRANSMIT:">istime.</dd> <dt>NON_MAX_RETRANSMIT:</dt> <dd>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 <xref target="RFC7252"></xref>).</t> <t hangText="NON_TIMEOUT:">is(<xref target="RFC7252" sectionFormat="of" section="4.8"/>).</dd> <dt>NON_TIMEOUT:</dt> <dd>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 <xref target="RFC7252"></xref>).</t> <t hangText="NON_TIMEOUT_RANDOM:">is(<xref target="RFC7252" sectionFormat="of" section="4.8"/>).</dd> <dt>NON_TIMEOUT_RANDOM:</dt> <dd>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).</t> <t hangText="NON_RECEIVE_TIMEOUT:">isACK_RANDOM_FACTOR).</dd> <dt>NON_RECEIVE_TIMEOUT:</dt> <dd>This parameter represents the maximum time to wait for a missing payload before requesting retransmission. By default, NON_RECEIVE_TIMEOUT has a value of twiceNON_TIMEOUT.</t> <t hangText="NON_PROBING_WAIT:">isNON_TIMEOUT.</dd> <dt>NON_PROBING_WAIT:</dt> <dd>This parameter is used to limit the potential wait needed when usingPROBING_RATE.</t> <t hangText="NON_PARTIAL_TIMEOUT:">isPROBING_RATE.</dd> <dt>NON_PARTIAL_TIMEOUT:</dt> <dd>This parameter is used for expiring partially receivedbodies.</t> </list></t>bodies.</dd> </dl> <t>These parameters are used together with the PROBING_RATEparameterparameter, 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 <xref target="RFC7252"></xref>),(<xref target="RFC7252" sectionFormat="of" section="4.7"/>), 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.</t> <t>This document augments the "ietf-dots-signal-channel" DOTS signal YANG module defined inSection 5.3 of<xreftarget="RFC9132"></xref>target="RFC9132" sectionFormat="of" section="5.3"/> with the following additional attributes that can be negotiated between DOTS peers to enable robust and faster transmission:</t><t><list style="hanging"> <t hangText="max-payloads:">This<dl newline="false" spacing="normal"> <dt>max-payloads:</dt> <dd> <t>This attribute echoes the MAX_PAYLOADS parameter defined in <xreftarget="RFC9177"></xref>.<vspace blankLines="1" />Thistarget="RFC9177" format="default"/>.</t> <t>This is an optional attribute. If the attribute is supplied in both‘idle-config’'idle-config' and‘mitigating-config’,'mitigating-config', then itMUST<bcp14>MUST</bcp14> convey the same value. If the attribute is only provided as part of‘idle-config’'idle-config' (or‘mitigating-config’),'mitigating-config'), then the other definition (i.e.,‘mitigating-config’'mitigating-config' (or‘idle-config’)) MUST'idle-config')) <bcp14>MUST</bcp14> be updated to the same value.</t><t hangText="non-max-retransmit:">This</dd> <dt>non-max-retransmit:</dt> <dd> <t>This attribute echoes the NON_MAX_RETRANSMIT parameter defined in <xreftarget="RFC9177"></xref>.target="RFC9177" format="default"/>. The default value of this attribute is 'max-retransmit'. Note that DOTS uses a default value of '3' instead of '4' (which is usedfor the genericgenerically by CoAPuse (Section 4.5.2 of <xref target="RFC9132"></xref>)formax-transmit. <vspace blankLines="1" />This'max-transmit'; see <xref target="RFC9132" sectionFormat="of" section="4.5.2"/> and <xref target="RFC7252" sectionFormat="of" section="4.8"/>).</t> <t>This is an optional attribute.</t><t hangText="non-timeout:">This</dd> <dt>non-timeout:</dt> <dd> <t>This attribute, expressed in seconds, echoes the NON_TIMEOUT parameter defined in <xreftarget="RFC9177"></xref>.target="RFC9177" format="default"/>. The default value of this attribute is'ack-timeout'.<vspace blankLines="1" />This'ack-timeout'.</t> <t>This attribute is also used to compute the NON_TIMEOUT_RANDOMparameter.<vspace blankLines="1" />Thisparameter.</t> <t>This is an optional attribute.</t><t hangText="non-receive-timeout:">This</dd> <dt>non-receive-timeout:</dt> <dd> <t>This attribute, expressed in seconds, echoes the NON_RECEIVE_TIMEOUT parameter defined in <xreftarget="RFC9177"></xref>.target="RFC9177" format="default"/>. The default value of this attribute is twice'non-timeout'.<vspace blankLines="1" />This'non-timeout'.</t> <t>This is an optional attribute.</t><t hangText="non-probing-wait:">This</dd> <dt>non-probing-wait:</dt> <dd> <t>This attribute, expressed in seconds, echoes the NON_PROBING_WAIT parameter defined in <xreftarget="RFC9177"></xref>. <vspace blankLines="1" />Thistarget="RFC9177" format="default"/>. </t> <t>This is an optional attribute.</t><t hangText="non-partial-timeout:">This</dd> <dt>non-partial-timeout:</dt> <dd> <t>This attribute, expressed in seconds, echoes the NON_PARTIAL_TIMEOUT parameter defined in <xreftarget="RFC9177"></xref>.target="RFC9177" format="default"/>. The default value of this attribute is 247seconds.<vspace blankLines="1" />Thisseconds.</t> <t>This is an optional attribute.</t></list></t></dd> </dl> <t>The tree structure of the "ietf-dots-robust-trans" module (<xreftarget="module"></xref>)target="module" format="default"/>) is shown in <xreftarget="tree"></xref>.</t> <t><figure anchor="tree" title="DOTStarget="tree" format="default"/>.</t> <figure anchor="tree"> <name>DOTS Fast Block Transmission TreeStructure"> <artwork><![CDATA[module:Structure</name> <sourcecode name="" type="yangtree"><![CDATA[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-wait: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:/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-wait:non-partial-timeout: +-- (direction)? | +--:(server-to-client-only) | +-- max-value-decimal? decimal64 | +-- min-value-decimal? decimal64 +-- current-value-decimal? decimal64]]></artwork> </figure></t>]]></sourcecode> </figure> <t>These attributes are mapped toCBORConcise Binary Object Representation (CBOR) types as specified in <xreftarget="maptab"></xref>target="maptab" format="default"/> andSection 6 ofin <xreftarget="RFC9132"></xref>.</t>target="RFC9132" sectionFormat="of" section="6"/>.</t> <t>DOTS clients follow the procedure specified inSection 4.5 of<xreftarget="RFC9132"></xref>target="RFC9132" sectionFormat="of" section="4.5"/> to negotiate, configure, and retrieve the DOTS signal channel session behavior (including Q-Block parameters) with DOTS peers.</t><t><list style="hanging"> <t hangText="Implementation<dl newline="false" spacing="normal"> <dt>Implementation Note1:">'non-probing-wait'1:</dt> <dd>'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 ofNON_TIMEOUT_RANDOM) and, then,NON_TIMEOUT_RANDOM); the jitter (ACK_RANDOM_FACTOR - 1) is then added to each time the value ischecked.</t> <t hangText="Implementationchecked.</dd> <dt>Implementation Note2:">If2:</dt> <dd>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 inSection 7.2 of<xreftarget="RFC9177"></xref>target="RFC9177" sectionFormat="of" section="7.2"/> unless explicit values are provided as part of the negotiatedconfiguration.</t> </list></t>configuration.</dd> </dl> <t>An example of a PUT message to configure Q-Block parameters is depicted in <xreftarget="put"></xref>.target="put" format="default"/>. 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-wait''non-partial-timeout' are not explicitly configured in this example, these attributes will be computed following the algorithms provided inSection 7.2 of<xreftarget="RFC9177"></xref>.target="RFC9177" sectionFormat="of" section="7.2"/>. Themeaningmeanings of the other attributesisare detailed inSection 4.5 of<xreftarget="RFC9132"></xref>.</t> <t><figure align="center" anchor="put" title="Exampletarget="RFC9132" sectionFormat="of" section="4.5"/>.</t> <figure anchor="put"> <name>Example of PUT to Convey the ConfigurationParameters"> <artwork align="left"><![CDATA[Parameters</name> <sourcecode name="" type="http-message"><![CDATA[ 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" } } }}]]></artwork> </figure></t> <t></t>} ]]></sourcecode> </figure> <t>The payload of the message depicted in <xreftarget="put"></xref>target="put" format="default"/> is CBOR-encoded as indicated by the Content-Format set to "application/dots+cbor"(Section 10.3 of <xref target="RFC9132"></xref>).(<xref target="RFC9132" sectionFormat="of" section="10.4"/>). However, and for the sake of better readability, the example uses JSON encoding of YANG-modeled data following the mappingtabletables in <xreftarget="maptab"></xref>target="maptab" format="default"/> andSection 6 ofin <xreftarget="RFC9132"></xref>:target="RFC9132" sectionFormat="of" section="6"/>: use the JSON names and types defined in <xreftarget="maptab"></xref>.target="maptab" format="default"/>. These conventions are inherited from <xreftarget="RFC9132"></xref>.</t>target="RFC9132" format="default"/>.</t> </section> <section anchor="maptab"title="YANG/JSONnumbered="true" toc="default"> <name>YANG/JSON Mapping Parameters toCBOR">CBOR</name> <t>The YANG/JSON mapping parameters to CBOR are listed inTable 2.<list style="symbols"> <t>Note:<xref target="tab-2"/>.</t> <t indent="3">Note: Implementers must check that the mapping output provided by their YANG-to-CBOR encoding schemes is aligned with the content ofTable 2.</t> </list></t> <t><figure align="center"> <artwork><![CDATA[+----------------------+------------+------+---------------+--------+ | Parameter Name | YANG | CBOR | CBOR Major | JSON | | | Type | Key | Type & | Type | | | | | Information | | +======================+============+======+===============+========+ | ietf-dots-robust- | container | TBA1 | 5 map | Object | | trans:max-payloads | | | | | +----------------------+------------+------+---------------+--------+ | ietf-dots-robust- | container | TBA2 | 5 map | Object | | trans:non-max- | | | | | | retransmit | | | | | +----------------------+------------+------+---------------+--------+ | ietf-dots-robust- | container | TBA3 | 5 map | Object | | trans:non-timeout | | | | | +----------------------+------------+------+---------------+--------+ | ietf-dots-robust- | container | TBA4 | 5 map | Object | | trans:non-receive- | | | | | | timeout | | | | | +----------------------+------------+------+---------------+--------+ | ietf-dots-robust- | container | TBA5 | 5 map | Object | | trans:non-probing- | | | | | | wait | | | | | +----------------------+------------+------+---------------+--------+ | ietf-dots-robust- | container | TBA6 | 5 map | Object | | trans:non-partial- | | | | | | wait | | | | | +----------------------+------------+------+---------------+--------+ Table 2: YANG/JSON<xref target="tab-2"/>.</t> <table anchor="tab-2"> <name>YANG/JSON Mapping Parameters toCBOR ]]></artwork> </figure></t> <t></t>CBOR</name> <thead> <tr> <th>Parameter Name</th> <th>YANG Type</th> <th>CBOR Key</th> <th>CBOR Major Type & Information</th> <th>JSON Type</th> </tr> </thead> <tbody> <tr> <td>ietf-dots-robust-trans:max-payloads</td> <td>container</td> <td>32776</td> <td>5 map</td> <td>Object</td> </tr> <tr> <td>ietf-dots-robust-trans:non-max-retransmit</td> <td>container</td> <td>32777</td> <td>5 map</td> <td>Object</td> </tr> <tr> <td>ietf-dots-robust-trans:non-timeout</td> <td>container</td> <td>32778</td> <td>5 map</td> <td>Object</td> </tr> <tr> <td>ietf-dots-robust-trans:non-receive-timeout</td> <td>container</td> <td>32779</td> <td>5 map</td> <td>Object</td> </tr> <tr> <td>ietf-dots-robust-trans:non-probing-wait</td> <td>container</td> <td>32780</td> <td>5 map</td> <td>Object</td> </tr> <tr> <td>ietf-dots-robust-trans:non-partial-timeout</td> <td>container</td> <td>32781</td> <td>5 map</td> <td>Object</td> </tr> </tbody> </table> </section> <section anchor="module"title="DOTSnumbered="true" toc="default"> <name>DOTS Robust Block Transmission YANGModule">Module</name> <t>This module uses the data structure extension defined in <xreftarget="RFC8791"></xref>.</t> <t><figure> <artwork><![CDATA[<CODE BEGINS> file "ietf-dots-robust-trans@2022-01-04.yang"target="RFC8791" format="default"/>.</t> <sourcecode name="ietf-dots-robust-trans@2023-01-26.yang" type="yang" markers="true"><![CDATA[ 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)20222023 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(http://trustee.ietf.org/license-info).(https://trustee.ietf.org/license-info). This version of this YANG module is part of RFCXXXX;9362; see the RFC itself for full legal notices."; revision2022-01-042023-01-26 { description "Initial revision."; reference "RFCXXXX: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 acceptablemax-payloads'max-payloads' value."; } leaf min-value { type uint16; description "Minimum acceptablemax-payloads'max-payloads' value."; } } } leaf current-value { type uint16; default "10"; description "Currentmax-payloads'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 acceptablenon-max-retransmit'non-max-retransmit' value."; } leaf min-value { type uint16; description "Minimum acceptablenon-max-retransmit'non-max-retransmit' value."; } } } leaf current-value { type uint16; default "3"; description "Currentnon-max-retransmit'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 "Maximumack-timeout'ack-timeout' value."; } leaf min-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; description "Minimumack-timeout'ack-timeout' value."; } } } leaf current-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; default "2.00"; description "Currentack-timeout'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 "Maximumnon-receive-timeout'non-receive-timeout' value."; } leaf min-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; description "Minimumnon-receive-timeout'non-receive-timeout' value."; } } } leaf current-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; default "4.00"; description "Currentnon-receive-timeout'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"Is used"Used to limit the potential wait needed when usingprobing-rate.";'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 "Maximumnon-probing-wait'non-probing-wait' value."; } leaf min-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; description "Minimumnon-probing-wait'non-probing-wait' value."; } } } leaf current-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; description "Currentnon-probing-wait'non-probing-wait' value."; reference "RFC 9177: Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission, Section 7.2"; } } containernon-partial-waitnon-partial-timeout { description"Is used"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 "Maximumnon-partial-wait'non-partial-timeout' value."; } leaf min-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; description "Minimumnon-partial-wait'non-partial-timeout' value."; } } } leaf current-value-decimal { type decimal64 { fraction-digits 2; } units "seconds"; default "247.00"; description "Currentnon-partial-wait'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>]]></artwork> </figure></t>]]></sourcecode> </section> <section anchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <section anchor="map"title="DOTSnumbered="true" toc="default"> <name>Registry for DOTS Signal Channel CBORMappings Registry">Mappings</name> <t>This specification registers the following parameters in the IANA "DOTS Signal Channel CBOR Key Values" registry <xreftarget="Key-Map"></xref>.</t> <t><list style="symbols"> <t>Note to the RFC Editor: Please replace TBA1-TBA6 with the CBOR keys that are assigned from the 32768-49151 range. Please update Table 2 accordingly.</t> </list></t> <t><figure align="center"> <artwork><![CDATA[+------------------------+-------+-------+------------+---------------+ | Parameter Name | CBOR |target="Key-Map" format="default"/>.</t> <table> <name>DOTS Robust Block Transmission CBOR| Change | Specification | | |Mappings</name> <thead> <tr> <th>Parameter Name</th> <th>CBOR Key|Value</th> <th>CBOR Major| Controller | Document(s) | | | Value | Type | | | +========================+=======+=======+============+===============+ | ietf-dots-robust-trans:| TBA1 | 5 | IESG | [RFCXXXX] | | max-payloads | | | | | +------------------------+-------+-------+------------+---------------+ | ietf-dots-robust-trans:| TBA2 | 5 | IESG | [RFCXXXX] | | non-max-retransmit | | | | | +------------------------+-------+-------+------------+---------------+ | ietf-dots-robust-trans:| TBA3 | 5 | IESG | [RFCXXXX] | | non-timeout | | | | | +------------------------+-------+-------+------------+---------------+ | ietf-dots-robust-trans:| TBA4 | 5 | IESG | [RFCXXXX] | | non-receive-timeout | | | | | +------------------------+-------+-------+------------+---------------+ | ietf-dots-robust-trans:| TBA5 | 5 | IESG | [RFCXXXX] | | non-probing-wait | | | | | +------------------------+-------+-------+------------+---------------+ | ietf-dots-robust-trans:| TBA6 | 5 | IESG | [RFCXXXX] | | non-partial-wait | | | | | +------------------------+-------+-------+------------+---------------+ ]]></artwork> </figure></t>Type</th> <th>Change Controller</th> <th>Specification Document(s)</th> </tr> </thead> <tbody> <tr> <td>ietf-dots-robust-trans:max-payloads</td> <td>32776</td> <td>5</td> <td>IESG</td> <td>RFC 9362</td> </tr> <tr> <td>ietf-dots-robust-trans:non-max-retransmit</td> <td>32777</td> <td>5</td> <td>IESG</td> <td>RFC 9362</td> </tr> <tr> <td>ietf-dots-robust-trans:non-timeout</td> <td>32778</td> <td>5</td> <td>IESG</td> <td>RFC 9362</td> </tr> <tr> <td>ietf-dots-robust-trans:non-receive-timeout</td> <td>32779</td> <td>5</td> <td>IESG</td> <td>RFC 9362</td> </tr> <tr> <td>ietf-dots-robust-trans:non-probing-wait</td> <td>32780</td> <td>5</td> <td>IESG</td> <td>RFC 9362</td> </tr> <tr> <td>ietf-dots-robust-trans:non-partial-timeout</td> <td>32781</td> <td>5</td> <td>IESG</td> <td>RFC 9362</td> </tr> </tbody> </table> </section> <section anchor="yang-iana"title="DOTSnumbered="true" toc="default"> <name>DOTS Robust Block Transmission YANGModule"> <t>This document requests IANA to registerModule</name> <t>IANA has registered the following URI in the "ns" subregistry within the "IETF XML Registry" <xreftarget="RFC3688"></xref>:</t> <t><figure> <artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans Registrant Contact: The IESG. XML: N/A;target="RFC3688" format="default"/>:</t> <dl newline="false" spacing="compact"> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans</dd> <dt>Registrant Contact:</dt><dd>The IESG.</dd> <dt>XML:</dt><dd>N/A; the requested URI is an XMLnamespace. ]]></artwork> </figure></t> <t>This document requests IANA to registernamespace.</dd> </dl> <t>IANA has registered the following YANG module in the "YANG Module Names" subregistry <xreftarget="RFC6020"></xref>target="RFC6020" format="default"/> within the "YANG Parameters" registry.</t><t><figure> <artwork><![CDATA[ Name: ietf-dots-robust-trans Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans Maintained<dl newline="false" spacing="compact"> <dt>Name:</dt><dd>ietf-dots-robust-trans</dd> <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans</dd> <dt>Maintained byIANA? N Prefix: dots-robust Reference: RFC XXXX ]]></artwork> </figure></t>IANA?</dt><dd>N</dd> <dt>Prefix:</dt><dd>dots-robust</dd> <dt>Reference:</dt><dd>RFC 9362</dd> </dl> </section> </section> <section anchor="security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>The security considerations for the DOTS signal channel protocol are discussed inSection 11 of<xreftarget="RFC9132"></xref>.</t>target="RFC9132" sectionFormat="of" section="11"/>.</t> <t>CoAP-specific security considerations are discussed inSection 11 of<xreftarget="RFC9177"></xref>.</t>target="RFC9177" sectionFormat="of" section="11"/>.</t> <t>Consistent withSection 5 of<xreftarget="RFC9132"></xref>,target="RFC9132" sectionFormat="of" section="5"/>, 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.</t> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7959.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8323.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8791.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9177.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9132.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9244.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8612.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/> <reference anchor="Key-Map" target="https://www.iana.org/assignments/dots/"> <front> <title>DOTS Signal Channel CBOR Key Values</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> </references> </references> <section anchor="ack"title="Acknowledgements">numbered="false" toc="default"> <name>Acknowledgements</name> <t>Thanks toTiru Reddy, Meiling Chen, and Kaname Nishizuka<contact fullname="Tiru Reddy"/>, <contact fullname="Meiling Chen"/>, and <contact fullname="Kaname Nishizuka"/> for the review.</t> <t>Thanks toMichal Vaško<contact fullname="Michal Vaško"/> for the yangdoctors review.</t> <t>Thanks toValery Smyslov<contact fullname="Valery Smyslov"/> for shepherding the document,Paul Wouters<contact fullname="Paul Wouters"/> for the AD review,Paul Kyzivat<contact fullname="Paul Kyzivat"/> for the artart directorate review,Tim Evens<contact fullname="Tim Evens"/> for the Gen-ART review, andJean-Michel Combes<contact fullname="Jean-Michel Combes"/> for the int-dir review.</t> <t>Thanks toJohn Scudder, Lars Eggert, Éric Vyncke, Roman Danyliw, Rob Wilton, and Martin Duke<contact fullname="John Scudder"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Rob Wilton"/>, and <contact fullname="Martin Duke"/> forthetheir comments during the IESG review.</t> </section></middle> <back> <references title="Normative References"> <?rfc include='reference.RFC.2119'?> <?rfc include='reference.RFC.7252'?> <?rfc include='reference.RFC.8174'?> <?rfc include='reference.RFC.7959'?> <?rfc include='reference.RFC.8323'?> <?rfc include='reference.RFC.8791'?> <?rfc include='reference.RFC.9177'?> <?rfc include='reference.RFC.9132'?> <?rfc include='reference.RFC.6020'?> <?rfc include='reference.RFC.3688'?> </references> <references title="Informative References"> <?rfc include="reference.RFC.9244"?> <?rfc include='reference.RFC.8612'?> <?rfc include='reference.RFC.8340'?> <reference anchor="Key-Map" target="https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel-cbor-key-values"> <front> <title>DOTS Signal Channel CBOR Key Values</title> <author fullname="IANA"> <organization></organization> </author> <date /> </front> </reference> </references></back> </rfc>