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

Text version

Internet Engineering Task Force (IETF)                      M. Boucadair
Request for Comments: 9362                                        Orange
Category: Standards Track                                     J. Shallow
ISSN: 2070-1721                                            February 2023

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

Abstract

This document specifies new DDoS Open Threat Signaling (DOTS) signal channel configuration parameters that can be negotiated between DOTS peers to enable the use of Q-Block1 and Q-Block2 Constrained Application Protocol (CoAP) options. These options enable robust and faster transmission rates for large amounts of data with less packet interchanges as well as support for faster recovery should any of the blocks get lost in transmission (especially during DDoS attacks).

Also, this document defines a YANG data model for representing these new DOTS signal channel configuration parameters. This model augments the DOTS signal YANG module ("ietf-dots-signal-channel") defined in RFC 9132.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9362.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

   1.  Introduction
   2.  Terminology
   3.  DOTS Attributes for Robust Block Transmission
   4.  YANG/JSON Mapping Parameters to CBOR
   5.  DOTS Robust Block Transmission YANG Module
   6.  IANA Considerations
     6.1.  Registry for DOTS Signal Channel CBOR Mappings
     6.2.  DOTS Robust Block Transmission YANG Module
   7.  Security Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction

The Constrained Application Protocol (CoAP) [RFC7252], although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. The block- wise transfer [RFC7959] introduced the CoAP Block1 and Block2 options to handle data records that cannot fit in a single IP packet, to avoid having to rely on IP fragmentation. The block-wise transfer was further updated by [RFC8323] for use over TCP, TLS, and WebSockets.

The CoAP Block1 and Block2 options work well in environments where there are no or minimal packet losses. These options operate synchronously where each individual block has to be requested and can only ask for (or send) the next block when the request for the previous block has completed. Packet rates, and hence block transmission rates, are controlled by Round-Trip Times (RTTs).

There is a requirement for these blocks of data to be transmitted at higher rates under network conditions where there may be asymmetrical transient packet loss (e.g., responses may get dropped). An example is when a network is subject to a Distributed Denial of Service (DDoS) attack and there is a need for DDoS mitigation agents relying upon CoAP to communicate with each other (e.g., [RFC9244]). As a reminder, [RFC7959] recommends the use of Confirmable (CON) responses to handle potential packet loss. However, such a recommendation does not work with a "flooded pipe" DDoS situation because the returning ACK packets may not get through.

The block-wise transfer specified in [RFC7959] covers the general case but falls short in situations where packet loss is highly asymmetrical. The mechanism specified in [RFC9177] provides features roughly similar to the Block1/Block2 options but also provides additional properties that are tailored towards the intended DDoS Open Threat Signaling (DOTS) transmission. Concretely, [RFC9177] primarily targets applications such as DOTS that can't use Confirmable responses to handle potential packet loss and that support application-specific mechanisms to assess whether the remote peer is able to handle the messages sent by a CoAP endpoint (e.g., DOTS heartbeats as discussed in Section 4.7 of [RFC9132]).

[RFC9177] includes guards to prevent a CoAP agent from overloading the network by adopting an aggressive sending rate. These guards are followed in addition to the existing CoAP congestion control as specified in Section 4.7 of [RFC7252] (mainly PROBING_RATE). Table 1 lists the additional CoAP parameters that are used for the guards (Section 7.2 of [RFC9177]). Note that NON in this table refers to Non-confirmable.

                +=====================+===================+
                | Parameter Name      | Default Value     |
                +=====================+===================+
                | MAX_PAYLOADS        | 10                |
                +---------------------+-------------------+
                | NON_MAX_RETRANSMIT  | 4                 |
                +---------------------+-------------------+
                | NON_TIMEOUT         | 2 s               |
                +---------------------+-------------------+
                | NON_TIMEOUT_RANDOM  | between 2-3 s     |
                +---------------------+-------------------+
                | NON_RECEIVE_TIMEOUT | 4 s               |
                +---------------------+-------------------+
                | NON_PROBING_WAIT    | between 247-248 s |
                +---------------------+-------------------+
                | NON_PARTIAL_TIMEOUT | 247 s             |
                +---------------------+-------------------+

Table 1: Congestion Control Parameters

PROBING_RATE and other transmission parameters are negotiated between DOTS peers as discussed in Section 4.5.2 of [RFC9132]. Nevertheless, negotiating the parameters listed in Table 1 is not supported in [RFC9132]. This document defines new DOTS signal channel attributes, corresponding to the parameters in Table 1, that are used to customize the configuration of robust block transmission in a DOTS context.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Readers should be familiar with the terms and concepts defined in [RFC7252] and [RFC8612].

The terms "payload" and "body" are defined in [RFC7959]. The term "payload" is thus used for the content of a single CoAP message (i.e., a single block being transferred), while the term "body" is used for the entire resource representation that is being transferred in a block-wise fashion.

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

3. DOTS Attributes for Robust Block Transmission

Section 7.2 of [RFC9177] defines the following parameters that are used for congestion control purposes:

   MAX_PAYLOADS:  This parameter represents the maximum number of
      payloads that can be transmitted at any one time.
   
   NON_MAX_RETRANSMIT:  This parameter represents the maximum number of
      times a request for the retransmission of missing payloads can
      occur without a response from the remote peer.  By default,
      NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT
      (Section 4.8 of [RFC7252]).
   
   NON_TIMEOUT:  This parameter represents the maximum period of delay
      between sending sets of MAX_PAYLOADS payloads for the same body.
      NON_TIMEOUT has the same value as ACK_TIMEOUT (Section 4.8 of
      [RFC7252]).
   
   NON_TIMEOUT_RANDOM:  This parameter represents the initial actual
      delay between sending the first two MAX_PAYLOADS_SETs of the same
      body.  It is a random duration between NON_TIMEOUT and
      (NON_TIMEOUT * ACK_RANDOM_FACTOR).
   
   NON_RECEIVE_TIMEOUT:  This parameter represents the maximum time to
      wait for a missing payload before requesting retransmission.  By
      default, NON_RECEIVE_TIMEOUT has a value of twice NON_TIMEOUT.
   
   NON_PROBING_WAIT:  This parameter is used to limit the potential wait
      needed when using PROBING_RATE.
   
   NON_PARTIAL_TIMEOUT:  This parameter is used for expiring partially
      received bodies.

These parameters are used together with the PROBING_RATE parameter, which in CoAP indicates the average data rate that must not be exceeded by a CoAP endpoint in sending to a peer endpoint that does not respond. The single body of blocks will be subjected to PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets. If the wait time between sending bodies that are not being responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time is limited to NON_PROBING_WAIT.

This document augments the "ietf-dots-signal-channel" DOTS signal YANG module defined in Section 5.3 of [RFC9132] with the following additional attributes that can be negotiated between DOTS peers to enable robust and faster transmission:

   max-payloads:  This attribute echoes the MAX_PAYLOADS parameter
      defined in [RFC9177].

This is an optional attribute. If the attribute is supplied in both 'idle-config' and 'mitigating-config', then it MUST convey the same value. If the attribute is only provided as part of 'idle-config' (or 'mitigating-config'), then the other definition (i.e., 'mitigating-config' (or 'idle-config')) MUST be updated to the same value.

   non-max-retransmit:  This attribute echoes the NON_MAX_RETRANSMIT
      parameter defined in [RFC9177].  The default value of this
      attribute is 'max-retransmit'.  Note that DOTS uses a default
      value of '3' instead of '4' (which is used generically by CoAP for
      'max-transmit'; see Section 4.5.2 of [RFC9132] and Section 4.8 of
      [RFC7252]).