RFC 9362

Part 1 of 5 🎀

Internet Engineering Task Force (IETF) 🌸 bestie, this is RFC 9362, published February 2023 by M. Boucadair (Orange) and J. Shallow. It's a Standards Track document, so it's an actual binding spec and not just an idea. ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates.

Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission 💅

Abstract ✨

okay so this doc adds new DOTS signal channel configuration parameters that DOTS peers can negotiate so they can use the Q-Block1 and Q-Block2 Constrained Application Protocol (CoAP) options 🦋. The payoff is robust, faster transmission of big chunks of data with fewer packet exchanges, plus quicker recovery if any blocks get lost in transit, especially during DDoS attacks 😭

It also defines a YANG data model for representing these new DOTS signal channel configuration parameters. The model augments the DOTS signal YANG module (ietf-dots-signal-channel) from RFC 9132 💜

Status of This Memo

This is an Internet Standards Track document. 🌈

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 7841 🧚

Info about the current status of this document, any errata, and how to give feedback on it lives 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) as they stand on the date this document was published. Please actually read those, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come 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 🦋

okay so the Constrained Application Protocol (CoAP) [RFC7252] was inspired by HTTP, but it was designed to run over UDP instead of TCP. Its message layer supports reliable delivery, simple congestion control, and flow control 💖

Block-wise transfer [RFC7959] added the CoAP Block1 and Block2 options. These handle data records that can't fit in a single IP packet, so nobody has to lean on IP fragmentation 🧚 Then [RFC8323] extended block-wise transfer so it works over TCP, TLS, and WebSockets ✨

The CoAP Block1 and Block2 options work great when there's no packet loss or very little of it. They run synchronously: each block has to be requested, and the next block can only be asked for (or sent) once the request for the previous block has finished. Packet rates, and so block transmission rates, are controlled by Round-Trip Times (RTTs) 🌸

Now here's the drama. Some blocks of data need to move at higher rates when the network has asymmetrical transient packet loss (for example, responses may get dropped) 😭 A big example is a DDoS attack, when DDoS mitigation agents that rely on CoAP need to talk to each other (e.g., [RFC9244]). Quick reminder: [RFC7959] recommends Confirmable (CON) responses to handle potential packet loss. But that doesn't work in a "flooded pipe" DDoS situation, because the returning ACK packets may never make it back 💀

The block-wise transfer in [RFC7959] covers the general case, but it falls short when packet loss is highly asymmetrical. The mechanism in [RFC9177] has features roughly similar to the Block1/Block2 options, plus extra properties tailored to DOTS transmission. Concretely, [RFC9177] mainly targets apps like DOTS that can't use Confirmable responses to handle potential packet loss, and that support application-specific mechanisms to check whether the remote peer can handle the messages a CoAP endpoint sends (e.g., DOTS heartbeats as discussed in Section 4.7 of [RFC9132]) 👑

[RFC9177] also includes guards so a CoAP agent can't overload the network by blasting at an aggressive sending rate. Those guards come on top of the existing CoAP congestion control in Section 4.7 of [RFC7252] (mainly PROBING_RATE). Table 1 lists the extra CoAP parameters used for those guards (Section 7.2 of [RFC9177]). Heads up: NON in this table means 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]. But negotiating the parameters in Table 1 isn't supported in [RFC9132] 😤 So this document defines new DOTS signal channel attributes that correspond to the Table 1 parameters, and those attributes customize the configuration of robust block transmission in a DOTS context 🫶

2. Terminology ✨

okay bestie, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like that 💅

You should be familiar with the terms and concepts defined in [RFC7252] and [RFC8612] 📚

The terms "payload" and "body" are defined in [RFC7959]. "Payload" is the content of a single CoAP message (so one block being transferred), while "body" is the entire resource representation being transferred block by block 🌈

The meanings of the symbols in YANG tree diagrams are defined in [RFC8340] and [RFC8791] 🧚

3. DOTS Attributes for Robust Block Transmission 🎀

okay so Section 7.2 of [RFC9177] defines these parameters for congestion control purposes 💅

• MAX_PAYLOADS: this one is the max number of payloads that can be transmitted at any one time 🦋
• NON_MAX_RETRANSMIT: this is the max number of times a request for retransmitting missing payloads can happen without a response from the remote peer 🫶 By default, it has the same value as MAX_RETRANSMIT (Section 4.8 of [RFC7252]).
• NON_TIMEOUT: this is the max period of delay between sending sets of MAX_PAYLOADS payloads for the same body ⏰ It has the same value as ACK_TIMEOUT (Section 4.8 of [RFC7252]).
• NON_TIMEOUT_RANDOM: this is the initial actual delay between sending the first two MAX_PAYLOADS_SETs of the same body 🎲 It's a random duration between NON_TIMEOUT and (NON_TIMEOUT * ACK_RANDOM_FACTOR).
• NON_RECEIVE_TIMEOUT: this is the max time to wait for a missing payload before requesting retransmission 🙈 By default, it has a value of twice NON_TIMEOUT.
• NON_PROBING_WAIT: this one exists to limit the potential wait needed when using PROBING_RATE 🌸
• NON_PARTIAL_TIMEOUT: this one is used for expiring partially received bodies 🍓

okay, so these parameters get used together with the PROBING_RATE parameter 🧚 In CoAP, that one indicates the average data rate that must not be exceeded by a CoAP endpoint when it's sending to a peer endpoint that does not respond. The single body of blocks gets subjected to PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets. If the wait time between sending bodies that aren't being responded to, based on PROBING_RATE, goes over NON_PROBING_WAIT, then the wait time gets 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 some extra attributes that can be negotiated between DOTS peers. They're there 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] 🦋 Its default value 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] ⏱️ Its default value 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] 🌈 Its default value 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] 🍑 Its default value 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, and honestly it's giving very organized 👑

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 get 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, so it should not be hard-coded with an explicit value. It's suggested to use a base value (using NON_TIMEOUT instead of NON_TIMEOUT_RANDOM), and then the jitter (ACK_RANDOM_FACTOR - 1) is 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 shown 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. Since non-probing-wait and non-partial-timeout aren't explicitly configured in this example, those 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 in Figure 2 is CBOR-encoded, as indicated by the Content-Format set to "application/dots+cbor" (Section 10.4 of [RFC9132]) 🧠 However, 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 ✨

okay so bestie, this part is all about the YANG/JSON mapping parameters to CBOR 🎀 they're all listed in Table 2 below 💅

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 ✨

okay bestie, this is where the YANG magic lives 🦋 this module leans on the data structure extension from [RFC8791] 💅

   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>

the module itself is called ietf-dots-robust-trans, revision 2023-02-28, and it's all about the knobs a DOTS client and server can negotiate for robust block transmission 🎀

Here's the vibe check 🔥 it imports the signal channel module from RFC 9132 and the structure extensions from RFC 8791, then the big grouping robust-transmission-attributes holds six containers: max-payloads, non-max-retransmit, non-timeout, non-receive-timeout, non-probing-wait and non-partial-timeout 💖 every one of them has a choice direction with a server-to-client-only case, so those max and min leaves only show up in messages going from the server to the client 🙈

The current values have defaults too: max-payloads is 10, non-max-retransmit is 3, non-timeout is 2.00 seconds, non-receive-timeout is 4.00 seconds and non-partial-timeout is 247.00 seconds 🧚 non-probing-wait doesn't have a default in this module, so it's a little bit of a mystery ✨

Last but not least, the two sx:augment-structure statements plug the grouping into signal-config in two spots: mitigating-config, for when a mitigation is active 🛡️, and idle-config, for when no mitigation is active 💤 both are totally iconic 👑

---

6. IANA Considerations ✨

6.1. Registry for DOTS Signal Channel CBOR Mappings 🎀

Okay so this spec registers a bunch of parameters in the "DOTS Signal Channel CBOR Key Values" registry [Key-Map] 📋. Here's the whole lineup, bestie:

+===================+==========+=======+============+===============+
| 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 also 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 🛡️

Okay, this part is seriously important, so pay attention 🚨. The security considerations for the DOTS signal channel protocol are covered in Section 11 of [RFC9132], so go read that. CoAP-specific security considerations are in Section 11 of [RFC9177] too 🔐.

Consistent with Section 5 of [RFC9132], the ietf-dots-robust-trans module is not intended to be used via NETCONF/RESTCONF 🙅‍♀️. It's just an abstract representation that shows up in DOTS signal channel messages. And the ietf-dots-robust-trans module does not introduce any new vulnerabilities beyond those specified above. So no new drama from this module, periodt 💅.

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 🫶

Huge 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