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

Internet-Draft	DOTS Robust Block Transmission	August 2021
Boucadair & Shallow	Expires 24 February 2022	[Page]

Abstract

This document specifies new DOTS signal channel configuration parameters that are negotiated between DOTS peers to enable the use of Q-Block1 and Q-Block2 Options. These options enable robust and faster transmission rates for large amounts of data with less packet interchanges as well as supporting faster recovery should any of the blocks get lost in transmission.¶

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. [RFC7959] introduced the CoAP Block1 and Block2 Options to handle data records that cannot fit in a single IP packet, so not having to rely on IP fragmentation and 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, and hence block transmission rate, is 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 (i.e., 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., [I-D.ietf-dots-telemetry]). 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 as 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 [I-D.ietf-core-new-block] provides roughly similar features to the Block1/Block2 Options. It provides additional properties that are tailored towards the intended DOTS transmission. Concretely, [I-D.ietf-core-new-block] primarily targets applications such as DDoS Open Threat Signaling (DOTS) that can't use Confirmable (CON) 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 in Section 4.7 of [I-D.ietf-dots-rfc8782-bis]).¶

[I-D.ietf-core-new-block] 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]. Table 1 additional CoAP attributes that are used for the guards.¶

+---------------------+---------------+
| Parameter Name      | Default Value |
+=====================+===============|
| MAX_PAYLOADS        |            10 |
| NON_MAX_RETRANSMIT  |             4 |
| NON_TIMEOUT         |           2 s |
| NON_RECEIVE_TIMEOUT |           4 s |
| NON_PROBING_WAIT    |         247 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 [I-D.ietf-dots-rfc8782-bis]. Nevertheless, the attributes listed in Table 1 are not supported. This document defines new DOTS signal channel attributes that are meant to customize the configuration of robust block transmission in a DOTS context.¶

3. DOTS Attributes for Robust Block Transmission

Section 6.2 of [I-D.ietf-core-new-block] defines the following attributes that are used for congestion control purposes:¶

MAX_PAYLOADS:: is the maximum number of payloads that can be transmitted at any one time.¶
NON_MAX_RETRANSMIT:: is the maximum number of times a request for the retransmission of missings 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:: is 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_RECEIVE_TIMEOUT:: is 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:: is used to limit the potential wait needed calculated when using PROBING_WAIT. By default, NON_PROBING_WAIT has the same value as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).¶
NON_PARTIAL_TIMEOUT:: is used for expiring partially received bodies. By default, NON_PARTIAL_TIMEOUT has the same value as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).¶

These attributes are used together with 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 calculated using on PROBING_RATE exceeds NON_PROBING_WAIT, then the gap time is limited to NON_PROBING_WAIT.¶

This document augments the "ietf-dots-signal-channel" (dots-signal) DOTS signal YANG module defined in [I-D.ietf-dots-rfc8782-bis] with these additional attributes that can be negotiated between DOTS peers to enable robust and faster transmission:¶

max-payloads:

This attribute echoes the MAX_PAYLOADS parameter in [I-D.ietf-core-new-block].¶