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

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

Rennes 35000 France mohamed.boucadair@orange.com


          United Kingdom


        supjps-ietf@jpshallow.com


    
    sec
    dots
    Quick-Block
    Robust-Block
    R-Block
    Tough-Block
    Resilient-Block
    Fast-Block
    Resilience
    Filtering
    Faster transmission
    Large amounts of data
    Less packet interchange
    Fast recovery
    
      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
            .
        
      
      
        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
            () 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
        
          
            .  Introduction
          
          
            .  Terminology
          
          
            .  DOTS Attributes for Robust Block Transmission
          
          
            .  YANG/JSON Mapping Parameters to CBOR
          
          
            .  DOTS Robust Block Transmission YANG Module
          
          
            .  IANA Considerations
            
              
                .  Registry for DOTS Signal Channel CBOR Mappings
              
              
                .  DOTS Robust Block Transmission YANG Module
              
            
          
          
            .  Security Considerations
          
          
            .  References
            
              
                .  Normative References
              
              
                .  Informative References
              
            
          
          
            Acknowledgements
          
          
            Authors' Addresses


  
    
      Introduction
      The Constrained Application Protocol (CoAP) , 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  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  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., ).
      As a reminder,  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 
      covers the general case but falls short in situations where packet loss
      is highly asymmetrical. The mechanism specified in  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,  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 ).
       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  (mainly PROBING_RATE).  lists the
      additional CoAP parameters that are used for the guards (). Note that NON in this table refers to
      Non-confirmable.
      Congestion Control Parameters
        
        
          
            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
          
        
      
      PROBING_RATE and other transmission parameters are negotiated between
      DOTS peers as discussed in . Nevertheless, negotiating the parameters
      listed in  is not supported in .
      This document defines new DOTS signal channel attributes, corresponding
      to the parameters in , that are used to customize the
      configuration of robust block transmission in a DOTS context.
    
    
      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
         when, and only
       when, they appear in all capitals, as shown here.
      Readers should be familiar with the terms and concepts defined in
       and .
      The terms "payload" and "body" are defined in . 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  and .
    
    
      DOTS Attributes for Robust Block Transmission
       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 ().
        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 ().
        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 (), 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  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 .
          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 . 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  and ).
          This is an optional
          attribute.
        
        non-timeout:
        
          This attribute, expressed in seconds,
          echoes the NON_TIMEOUT parameter defined in .
          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 . 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 . 
          This is an
          optional attribute.
        
        non-partial-timeout:
        
          This attribute, expressed in
          seconds, echoes the NON_PARTIAL_TIMEOUT parameter defined in . The default value of this attribute is 247
          seconds.
          This is an optional attribute.
        
      
      The tree structure of the "ietf-dots-robust-trans" module () is shown in .
      
        DOTS Fast Block Transmission Tree Structure
        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

      
      These attributes are mapped to Concise Binary Object Representation (CBOR) types as specified in  and in .
      DOTS clients follow the procedure specified in  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  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 . 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 . The meanings
      of the other attributes are detailed in .
      
        Example of PUT to Convey the Configuration Parameters
        
     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"
           }
         }
       }
     }

      
      The payload of the message depicted in  is
      CBOR-encoded as indicated by the Content-Format set to
      "application/dots+cbor" (). However, and for the sake of better
      readability, the example uses JSON encoding of YANG-modeled data
      following the mapping tables in  and in : use the JSON names and types
      defined in . These conventions are
      inherited from .
    
    
      YANG/JSON Mapping Parameters to CBOR
      The YANG/JSON mapping parameters to CBOR are listed in .
      Note: Implementers must check that the mapping output provided by
          their YANG-to-CBOR encoding schemes is aligned with the content of
          .
      YANG/JSON Mapping Parameters to CBOR
        
        
          
            Parameter Name
            YANG Type
            CBOR Key
            CBOR Major Type & Information
            JSON Type
          
        
        
          
            ietf-dots-robust-trans:max-payloads
            container
            32776
            5 map
            Object
          
          
            ietf-dots-robust-trans:non-max-retransmit
            container
            32777
            5 map
            Object
          
          
            ietf-dots-robust-trans:non-timeout
            container
            32778
            5 map
            Object
          
          
            ietf-dots-robust-trans:non-receive-timeout
            container
            32779
            5 map
            Object
          
          
            ietf-dots-robust-trans:non-probing-wait
            container
            32780
            5 map
            Object
          
          
            ietf-dots-robust-trans:non-partial-timeout
            container
            32781
            5 map
            Object
          
        
      
    
    
      DOTS Robust Block Transmission YANG Module
      This module uses the data structure extension defined in .
      
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;
  }
}

    
    
      IANA Considerations
      
        Registry for DOTS Signal Channel CBOR Mappings
        This specification registers the following parameters in the IANA
        "DOTS Signal Channel CBOR Key Values" registry .
        DOTS Robust Block Transmission CBOR Mappings
          
          
            
              Parameter Name
              CBOR Key Value
              CBOR Major Type
              Change Controller
              Specification Document(s)
            
          
          
            
              ietf-dots-robust-trans:max-payloads
              32776
              5
              IESG
              RFC 9362
            
            
              ietf-dots-robust-trans:non-max-retransmit
              32777
              5
              IESG
              RFC 9362
            
            
              ietf-dots-robust-trans:non-timeout
              32778
              5
              IESG
              RFC 9362
            
            
              ietf-dots-robust-trans:non-receive-timeout
              32779
              5
              IESG
              RFC 9362
            
            
              ietf-dots-robust-trans:non-probing-wait
              32780
              5
              IESG
              RFC 9362
            
            
              ietf-dots-robust-trans:non-partial-timeout
              32781
              5
              IESG
              RFC 9362
            
          
        
      
      
        DOTS Robust Block Transmission YANG Module
        IANA has registered the following URI in the
        "ns" subregistry within the "IETF XML Registry" :
        
          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 
        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
        
      
    
    
      Security Considerations
      The security considerations for the DOTS signal channel protocol are
      discussed in .
      CoAP-specific security considerations are discussed in .
      Consistent with , 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.
    
  
  
    
      References
      
        Normative References
        
          
            Key words for use in RFCs to Indicate Requirement Levels
            
            
            
              In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
            
          
          
          
          
        
        
          
            The IETF XML Registry
            
            
            
              This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.
            
          
          
          
          
        
        
          
            YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
            
            
            
              YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]
            
          
          
          
        
        
          
            The Constrained Application Protocol (CoAP)
            
            
            
            
            
              The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.
              CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.
            
          
          
          
        
        
          
            Block-Wise Transfers in the Constrained Application Protocol (CoAP)
            
            
            
            
              The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.
              Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.
              A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252.
            
          
          
          
        
        
          
            Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
            
            
            
              RFC 2119 specifies common key words that may be used in protocol specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
            
          
          
          
          
        
        
          
            CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
            
            
            
            
            
            
            
            
              The Constrained Application Protocol (CoAP), 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.
              Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.
            
          
          
          
        
        
          
            YANG Data Structure Extensions
            
            
            
            
            
              This document describes YANG mechanisms for defining abstract data structures with YANG.
            
          
          
          
        
        
          
            Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification
            
            
            
            
            
              This document specifies the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.
              A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes.
              This document obsoletes RFC 8782.
            
          
          
          
        
        
          
            Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission
            
            
            
            
              This document specifies alternative Constrained Application Protocol (CoAP) block-wise transfer options: Q-Block1 and Q-Block2.
              These options are similar to, but distinct from, the CoAP Block1 and Block2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are not intended to replace the Block1 and Block2 options but rather have the goal of supporting Non-confirmable (NON) messages for large amounts of data with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 options support faster recovery should any of the blocks get lost in transmission.
            
          
          
          
        
      
      
        Informative References
        
          
            DOTS Signal Channel CBOR Key Values
            
              IANA
            
            
          
        
        
          
            YANG Tree Diagrams
            
            
            
            
              This document captures the current syntax used in YANG module tree diagrams.  The purpose of this document is to provide a single location for this definition.  This syntax may be updated from time to time based on the evolution of the YANG language.
            
          
          
          
          
        
        
          
            DDoS Open Threat Signaling (DOTS) Requirements
            
            
            
            
            
              This document defines the requirements for the Distributed Denial-of- Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks.
            
          
          
          
        
        
          
            Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
            
            
            
            
            
            
            
              This document aims to enrich the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol with various telemetry attributes, allowing for optimal Distributed Denial-of-Service (DDoS) attack mitigation. It specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator in choosing the DDoS mitigation techniques and performing optimal DDoS attack mitigation.
              This document specifies two YANG modules: one for representing DOTS telemetry message types and one for sharing the attack mapping details over the DOTS data channel.
            
          
          
          
        
      
    
    
      Acknowledgements
      Thanks to , , and  for the
      review.
      Thanks to  for the yangdoctors review.
      Thanks to  for shepherding the document, 
      for the AD review,  for the artart directorate review,  for the Gen-ART review, and  for the int-dir
      review.
      Thanks to , , , , , and  for their comments during the IESG
      review.
    
    
      Authors' Addresses
      
        Orange
        
          
            
            Rennes
            
            35000
            France
          
          mohamed.boucadair@orange.com
        
      
      
        
        
          
            
            
            
            
            United Kingdom
          
          supjps-ietf@jpshallow.com

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

Parameter Name	YANG Type	CBOR Key	CBOR Major Type & Information	JSON Type
ietf-dots-robust-trans:max-payloads	container	32776	5 map	Object
ietf-dots-robust-trans:non-max-retransmit	container	32777	5 map	Object
ietf-dots-robust-trans:non-timeout	container	32778	5 map	Object
ietf-dots-robust-trans:non-receive-timeout	container	32779	5 map	Object
ietf-dots-robust-trans:non-probing-wait	container	32780	5 map	Object
ietf-dots-robust-trans:non-partial-timeout	container	32781	5 map	Object

Parameter Name	CBOR Key Value	CBOR Major Type	Change Controller	Specification Document(s)
ietf-dots-robust-trans:max-payloads	32776	5	IESG	RFC 9362
ietf-dots-robust-trans:non-max-retransmit	32777	5	IESG	RFC 9362
ietf-dots-robust-trans:non-timeout	32778	5	IESG	RFC 9362
ietf-dots-robust-trans:non-receive-timeout	32779	5	IESG	RFC 9362
ietf-dots-robust-trans:non-probing-wait	32780	5	IESG	RFC 9362
ietf-dots-robust-trans:non-partial-timeout	32781	5	IESG	RFC 9362