Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission
Extracted elements (18)
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.
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.
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.
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.
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.
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.
If the 'max-payloads' attribute is supplied in both 'idle-config' and 'mitigating-config', it MUST convey the same value in both.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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'.