rfc-9362

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

M. Boucadair, J. Shallow
date2023-02 streamIETF areasec wgdots statusPROPOSED STANDARD pages21 canonicalhttps://www.rfc-editor.org/rfc/rfc9362 doi10.17487/RFC9362
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.

Extracted elements (18)

design-rationale §1

RFC 9177 Q-Block1/Q-Block2 options are chosen over standard Block1/Block2 because they provide additional properties tailored for DOTS: they support asymmetric packet loss scenarios, enable non-confirmable transmission, and allow application-specific mechanisms (e.g., DOTS heartbeats) to assess peer liveness rather than relying on CoAP CON/ACK.

security, congestion

design-rationale §1

Standard CoAP Block1/Block2 options operate synchronously, requiring each block to be acknowledged before the next is sent, with rates controlled by RTTs. During a DDoS 'flooded pipe' attack, returning ACK packets may not get through, making Confirmable (CON) responses ineffective and rendering Block1/Block2 insufficient for DOTS use.

security, congestion

design-rationale §3

The 'non-probing-wait' attribute ideally should not be hard-coded with an explicit value; instead it should incorporate jitter. The recommended approach is to use a base value computed with NON_TIMEOUT (not NON_TIMEOUT_RANDOM) and add ACK_RANDOM_FACTOR-based jitter each time the value is checked.

security, congestion

interoperability-note §3

DOTS uses a default value of 3 for 'non-max-retransmit' instead of the generic CoAP default of 4 (MAX_RETRANSMIT). This aligns with the DOTS-specific 'max-retransmit' default specified in Section 4.5.2 of RFC 9132 rather than the CoAP default in Section 4.8 of RFC 7252.

security

normative-requirement §3 SHOULD

If any signal channel session configuration parameter is updated, the 'non-probing-wait' and 'non-partial-timeout' values should be recalculated according to the algorithms in RFC 9177 Section 7.2, unless explicit values were negotiated.

security

normative-requirement §3 MUST

If 'max-payloads' is only provided as part of 'idle-config' (or 'mitigating-config'), then the other configuration MUST be updated to the same value.

security

normative-requirement §3 MUST

If the 'max-payloads' attribute is supplied in both 'idle-config' and 'mitigating-config', it MUST convey the same value in both.

security

protocol-element §3

The 'max-payloads' attribute echoes the MAX_PAYLOADS parameter from RFC 9177, representing the maximum number of payloads that can be transmitted at any one time. It is optional, encoded as uint16, with a default value of 10, and maps to CBOR key 32776.

security, congestion, cbor

protocol-element §3

The 'non-max-retransmit' attribute echoes NON_MAX_RETRANSMIT from RFC 9177, representing the maximum number of times retransmission of missing payloads can be requested without a remote peer response. It is optional, encoded as uint16, with a DOTS default of 3 (not CoAP's 4), and maps to CBOR key 32777.

security, congestion, cbor

protocol-element §3

The 'non-partial-timeout' attribute echoes NON_PARTIAL_TIMEOUT from RFC 9177, used for expiring partially received bodies. It is optional, expressed in seconds as decimal64 with default 247.00 s, and maps to CBOR key 32781.

security, congestion, cbor

protocol-element §3

The 'non-probing-wait' attribute echoes NON_PROBING_WAIT from RFC 9177, used to limit the potential wait when using PROBING_RATE. It is optional, expressed in seconds as decimal64 with no fixed default (computed from algorithms in RFC 9177 Section 7.2), and maps to CBOR key 32780.

security, congestion, cbor

protocol-element §3

The 'non-receive-timeout' attribute echoes NON_RECEIVE_TIMEOUT from RFC 9177, representing the maximum time to wait for a missing payload before requesting retransmission. It is optional, expressed in seconds as decimal64 with default 4.00 s (twice non-timeout), and maps to CBOR key 32779.

security, congestion, cbor

protocol-element §3

The 'non-timeout' attribute echoes NON_TIMEOUT from RFC 9177, representing the maximum period of delay between sending sets of MAX_PAYLOADS payloads for the same body. It is optional, expressed in seconds as decimal64 with default 2.00 s, and maps to CBOR key 32778.

security, congestion, cbor

registry §6.2

IANA has registered the YANG module 'ietf-dots-robust-trans' in the 'YANG Module Names' subregistry with namespace 'urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans', prefix 'dots-robust', and a corresponding URI in the IETF XML Registry.

registry, yang, security

registry §6.1

This document registers six entries in the IANA 'DOTS Signal Channel CBOR Key Values' registry: ietf-dots-robust-trans:max-payloads (32776), non-max-retransmit (32777), non-timeout (32778), non-receive-timeout (32779), non-probing-wait (32780), non-partial-timeout (32781), all with CBOR Major Type 5 and IESG as Change Controller.

registry, cbor, security

security-consideration §7

Consistent with RFC 9132 Section 5, the 'ietf-dots-robust-trans' YANG module is not intended to be used via NETCONF/RESTCONF; it serves only as an abstract representation in DOTS signal channel messages.

security, yang, netconf

security-consideration §7

Security considerations for the DOTS signal channel protocol are discussed in Section 11 of RFC 9132, and CoAP-specific security considerations are in Section 11 of RFC 9177. The 'ietf-dots-robust-trans' module does not introduce any new vulnerabilities beyond those.

security, yang

wire-format §4

The six robust block transmission parameters are CBOR-encoded as maps (CBOR Major Type 5) with keys 32776 (max-payloads), 32777 (non-max-retransmit), 32778 (non-timeout), 32779 (non-receive-timeout), 32780 (non-probing-wait), and 32781 (non-partial-timeout). The Content-Format is 'application/dots+cbor'.

cbor, security, registry