Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification
obsoletes
- rfc-8782 — Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification
Extracted elements (31)
Port 4646 was chosen instead of the default CoAP (D)TLS port 5684 to avoid CoAP service discovery, allow differentiated behavior when a DOTS gateway and an IoT gateway are co-located, and to simplify deployment within LANs where the default router acts as DOTS server without requiring sophisticated discovery.
The DOTS signal channel is built on CoAP because CoAP's features — expectation of packet loss, asynchronous Non-confirmable messaging, congestion control, small message overhead, and (D)TLS support — make it well-suited for DDoS signaling, which must remain functional under attack conditions.
For backward compatibility with RFC 8782 implementations, the only required upgrade is to treat CBOR key values in the range 128–255 as comprehension-optional instead of comprehension-required; all CBOR key values and major types from RFC 8782 remain unchanged in this specification.
A DOTS client MUST NOT include multiple entries in the 'scope' array of a single PUT request; at least one of 'target-prefix', 'target-fqdn', 'target-uri', or 'alias-name' MUST be present in each PUT request.
Absent explicit mutual agreement on a port, the DOTS signal channel MUST run over port 4646 for both UDP and TCP; DOTS clients and servers SHOULD support a configurable parameter to supply an alternate port number.
DOTS agents MUST NOT send more than one UDP datagram per round-trip time to the peer on average; if the client cannot maintain an RTT estimate, it MUST NOT send more than one Non-confirmable request every 3 seconds.
DOTS agents MUST support GET, PUT, and DELETE CoAP methods. CoAP 2.xx responses MUST carry 'application/dots+cbor' payloads; 4.xx and 5.xx error responses MUST include a diagnostic payload to aid troubleshooting.
DOTS agents MUST support mutual (D)TLS authentication. The DOTS client MUST authenticate itself to the DOTS server; the server MUST reject unauthenticated clients. The DOTS server MAY derive the client identity from the client certificate per RFC 7589 Section 7.
DOTS implementations MUST support the CoAP Observe Option for both 'mitigate' and 'config' resources. Mitigation status notifications from the DOTS server MUST always use Non-confirmable CoAP messages, overriding the RFC 7641 default that sends at least one Confirmable message every 24 hours.
DOTS signal channel messages forwarded through NAT MUST NOT include internal IP addresses, prefixes, or port numbers; external addresses and ports as assigned by the translator MUST be used instead.
The 'mid' (Mitigation Identifier) MUST be unique per 'cuid' and DOTS server for active mitigations, MUST increase monotonically to handle out-of-order delivery, and MUST be reset to 0 when it reaches 3/4 of (2^32 - 1) during a non-attack period.
When a mitigation is triggered by signal channel loss, the DOTS server MUST NOT treat signal channel recovery as a trigger to stop the mitigation; only an explicit DELETE, lifetime expiry, or successful scrubbing stops it.
After a DOTS client issues a DELETE for a mitigation request, the DOTS server MAY continue active-but-terminating mitigation for an initial period (default 120 seconds, extendable exponentially up to 300 seconds) to dampen route or DNS flapping; after this period, the DOTS server MUST treat the mitigation as terminated.
Conflict notifications include 'conflict-status' (1=this inactive, another active; 2=this active; 3=all inactive), 'conflict-cause' (1=overlapping targets; 2=conflicts with accept-list; 3=CUID collision), 'conflict-scope' identifying overlapping resources, and 'retry-timer' indicating when the client may reissue the request.
DOTS operations are addressed via CoAP URIs with path prefix '/.well-known/dots' and operation-specific suffixes: '/mitigate' for mitigation, '/config' for session configuration, and '/hb' for heartbeat.
Mitigation efficacy updates are sent via PUT with the mandatory 'attack-status' parameter (1=still under attack, 2=successfully mitigated). The PUT MUST include all parameters from the original mitigation request unchanged except 'lifetime'; an If-Match Option with empty value makes the request conditional on the mitigation's existence.
Redirected signaling allows a DOTS server to redirect a DOTS client to an alternate server by returning a response containing the alternate server's address and port, enabling load balancing and failover scenarios.
Session configuration (Section 4.5) allows negotiation of 'heartbeat-interval' (seconds between heartbeats), 'missing-hb-allowed' (consecutive missed heartbeats before session declared lost), 'max-retransmit', 'ack-timeout', and 'ack-random-factor', permitting DOTS agents to tune reliability and keepalive behavior.
The 'cdid' (Client Domain Identifier) is an optional Uri-Path parameter added by server-domain DOTS gateways to propagate client-domain identity toward the DOTS server. It MUST be derived using the same SPKI hash procedure as 'cuid', positioned before 'cuid', and MUST NOT be generated or forwarded by DOTS clients or client-domain gateways.
The 'cuid' (Client Unique Identifier) is a globally unique, stable Uri-Path parameter generated by the DOTS client, ideally by SHA-256-hashing the SPKI of the client's X.509 certificate (or raw public key or PSK identity), truncating to 16 bytes, and base64url-encoding the result (22 characters) with trailing '=' removed.
The DOTS Happy Eyeballs procedure attempts connections in preference order: UDP over IPv6, UDP over IPv4, TCP over IPv6, TCP over IPv4. The DOTS client caches connection outcomes for roughly 10 minutes. If only TLS over TCP succeeds, the client SHOULD NOT probe for DTLS availability more than once every 24 hours and MUST NOT probe more often than every 5 minutes.
The DOTS YANG module 'ietf-dots-signal-channel' defines the data model for mitigation scopes, signal channel session configuration, and redirected signaling. A companion module 'iana-dots-signal-channel' defines IANA-maintained identities for status and cause codes.
The heartbeat mechanism uses CoAP GET/POST on the '/hb' path to keep the DOTS signal channel active. If a DOTS agent does not receive a response to 'missing-hb-allowed' consecutive heartbeats, the DOTS signal channel session is considered lost, which may trigger preconfigured mitigations.
The 'lifetime' parameter is mandatory in mitigation PUT requests. The recommended value is 3600 seconds. A lifetime of 0 is invalid; a lifetime of -1 requests indefinite mitigation (which the server MAY refuse). The server MUST always return the actual granted lifetime in its response.
The 'trigger-mitigation' boolean (default true) controls when mitigation activates. When set to false, mitigation is not triggered unless the DOTS signal channel session is lost, enabling preconfigured 'break-glass' mitigation that activates on session loss.
IANA assigned UDP and TCP port 4646 for the DOTS signal channel and registered the '/.well-known/dots' URI suffix under the Well-Known URI registry (RFC 8615). The media type 'application/dots+cbor' was registered for DOTS signal channel payloads.
IANA maintains the 'DOTS Signal Channel Protocol' registry with five subregistries: CBOR Key Values, Status Codes (Table 3), Conflict Status Codes, Conflict Cause Codes, and Attack Status Codes (Table 4). The CBOR Key Values subregistry uses a 'comprehension-required' (0–127) and 'comprehension-optional' (128–255) key space split.
DOTS agents MUST mutually authenticate using (D)TLS with certificates or pre-shared keys. An unauthenticated DOTS server exposes clients to man-in-the-middle attacks where an attacker could reject mitigation requests or redirect the client to a rogue server; an unauthenticated client could be used to launch DoS attacks against the DOTS server.
The 'trigger-mitigation=false' mechanism trades off availability against abuse: a DOTS client can preinstall broad mitigation scopes that activate on signal channel loss, which an attacker could exploit by deliberately severing the signal channel. Implementations should restrict preconfigured mitigation scopes to the minimum necessary.
Mitigation status transitions through states 1–8: (1) setup in progress, (2) successfully mitigating, (3) attack stopped, (4) exceeded provider capacity, (5) client withdrawn but terminating, (6) mitigation terminated, (7) mitigation withdrawn by server, (8) mitigation pending signal-channel-loss trigger only. For preconfigured mitigations (trigger-mitigation=false), status 3 and 7 are transmitted four times before transitioning to 8.
All DOTS signal channel messages are serialized in CBOR (RFC 8949); YANG-modeled parameters are mapped to CBOR integer keys defined in Table 5 (Section 6). The content type is 'application/dots+cbor'. Numeric CBOR keys are used in place of string names to minimize message size and reduce fragmentation risk.