Distributed
Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
Configuration Attributes for Robust Block TransmissionOrangeRennes35000Francemohamed.boucadair@orange.comUnited Kingdomsupjps-ietf@jpshallow.comDOTSQuick-BlockRobust-BlockR-BlockTough-BlockResilient-BlockFast-BlockResilienceFilteringFaster transmissionLarge amounts of dataLess packet interchangeFast recoveryThis 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.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.
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 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., ). 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 as 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 roughly similar
features to the Block1/Block2 Options. It provides additional properties
that are tailored towards the intended DOTS transmission. Concretely,
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 ). 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 . Table 1 additional CoAP attributes that are
used for the guards.PROBING_RATE and other transmission parameters are negotiated between
DOTS peers as discussed in Section 4.5.2 of . 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.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 meaning of the symbols in YANG tree diagrams are defined in and .(D)TLS is used for statements that apply to both Transport Layer
Security (TLS) and Datagram Transport
Layer Security (DTLS) . Specific terms are
used for any statement that applies to either protocol alone.Section 6.2 of defines
the following attributes that are used for congestion control
purposes:is the maximum number of payloads that
can be transmitted at any one time.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 ).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 ).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.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 ).is used for expiring partially
received bodies. By default, NON_PARTIAL_TIMEOUT has the same value
as EXCHANGE_LIFETIME (Section 4.8.2 of ).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
), 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 with these additional
attributes that can be negotiated between DOTS peers to enable robust
and faster transmission:This attribute echoes the MAX_PAYLOADS
parameter in .This is an optional attribute.For the sake of more flexible configuration, this document defines
also the following attributes:This attribute echoes the
NON_MAX_RETRANSMIT parameter in . The default value of this
attribute is 'max-retransmit'. Note that DOTS uses a default value
of '3' instead of '4' used for the generic CoAP use (Section 4.5.2
of ) for
max-transmit. This is an optional
attribute.This attribute echoes the NON_TIMEOUT
parameter in . The
default value of this attribute is 'ack-timeout'.This is an optional attribute.This attribute echoes the
NON_PROBING_WAIT parameter in . The default value of this
attribute is 247s.This is an optional
attribute.This attribute echoes the
NON_PARTIAL_TIMEOUT parameter in . The default value of this
attribute is 274s.This is an optional
attribute.An example of PUT message to convey the configuration parameters for
the DOTS signal channel is depicted in . In
this example, the 'max-payloads' is set to '15' when no mitigation is
active, while it is set to '10' when a mitigation is active. The same
value is used for both 'non-max-retransmit' and 'non-timeout' in idle
and mitigation times.This document defines the YANG module "ietf-dots-robust-trans"
(), which has the following tree
structure:The YANG/JSON mapping parameters to CBOR are listed in Table
2.Note: Implementers must check that the mapping output provided
by their YANG-to-CBOR encoding schemes is aligned with the content
of Table 2.This module uses the data structure extension defined in .This specification registers the following parameters in the IANA
"DOTS Signal Channel CBOR Key Values" registry .Note to the RFC Editor: Please replace TBA1/TBA2/TBA3 with the
CBOR keys that are assigned from the 128-255 range. Please update
Table 2 accordingly.This document requests IANA to register the following URI in the
"ns" subregistry within the "IETF XML Registry" :This document requests IANA to register the following YANG module
in the "YANG Module Names" subregistry
within the "YANG Parameters" registry.The security considerations for the DOTS signal channel protocol are
discussed in Section 11 of .CoAP-specific security considerations are discussed in Section 11 of
.This document defines YANG data structures that are meant to be used
as an abstract representation in DOTS signal channel messages. As such,
the "ietf-dots-robust-trans" module does not introduce any new
vulnerabilities beyond those specified above.TBCDOTS Signal Channel CBOR Key Values