Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification
obsoleted by
- rfc-9132 — Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification
Extracted elements (29)
Mitigation status notifications from DOTS servers are forced to Non-confirmable (overriding RFC 7641's recommendation to send Confirmable at least every 24 hours) because the signal channel uses a heartbeat to detect liveness, and Confirmable messages impose excessive overhead during active DDoS attacks.
Port 4646 was chosen instead of CoAP's default 5684 to avoid service/resource discovery defined in RFC 7252 and to enable differentiated behaviors in environments where a DOTS gateway and an IoT gateway are co-located. The default port also simplifies deployment in LAN scenarios where the default router is the DOTS server.
The Happy Eyeballs preference order—UDP/IPv6 first, then UDP/IPv4, TCP/IPv6, TCP/IPv4—promotes UDP to avoid TCP's head-of-line blocking, which is critical during DDoS attacks when rapid signaling is essential.
CoAP over reliable transports (TLS/TCP) does not support Confirmable or Non-confirmable message types per RFC 8323, so transmission-related parameters ('missing-hb-allowed', signal loss ratio) are negotiated only for DOTS over UDP/DTLS.
When DOTS is deployed behind NAT (Traditional NAT, CGN, NAT64, NPTv6), internal addresses MUST be replaced with external addresses in DOTS messages. PCP or STUN may be used to discover external addresses; a co-located DOTS gateway may update messages using the translator's binding table.
Absent a mutual agreement on port, the DOTS signal channel MUST run over port number 4646 for both UDP and TCP. To use a different port, DOTS clients and servers SHOULD support a configurable parameter.
Both DOTS signal and data channel sessions require mutual client authentication (Section 8). The DOTS server uses (D)TLS with mutual certificate validation or PSK to authenticate DOTS clients and authorize their mitigation scopes.
'cuid' MUST be generated by DOTS clients and MUST NOT be changed while mitigations are active. DOTS servers MUST return 4.09 (Conflict) when a 'cuid' is already in use by another DOTS client.
DOTS agents MUST NOT send more than one UDP datagram per RTT to a peer on average. If an RTT estimate cannot be maintained, a DOTS client MUST NOT send more than one Non-confirmable request every 3 seconds.
DOTS agents MUST support GET, PUT, and DELETE CoAP methods. Payloads in 2.xx responses MUST use content type 'application/dots+cbor'. Responses with 4.xx and 5.xx codes MUST include a diagnostic payload.
DOTS clients MUST include the 'lifetime' parameter in mitigation requests. The DOTS server MUST always indicate the actual lifetime in the response and remaining lifetime in status messages. A lifetime of '0' is invalid and MUST be rejected with 4.00.
DOTS clients MUST NOT include multiple entries in the 'scope' array of a single PUT request, to avoid complex partial-failure handling.
DOTS implementations MUST use the CoAP Observe Option for both 'mitigate' and 'config' resources. For the DOTS server application, notification message type MUST always be Non-confirmable.
In deployments with NAT/translators between client and server, DOTS signal channel messages MUST NOT include internal IP addresses or port numbers; external addresses assigned by the translator MUST be used instead.
'mid' values MUST increase monotonically to handle out-of-order delivery. If 'mid' reaches 3/4 of (2^32 - 1) with no active attack, the DOTS client MUST reset 'mid' to 0.
The active-but-terminating period after a mitigation withdrawal SHOULD be set by default to 120 seconds. The DOTS server MAY exponentially increase it (base 2) up to a maximum of 300 seconds if the client re-requests mitigation before the period elapses.
The 'cdid' attribute MUST NOT be generated by DOTS clients. DOTS servers MUST ignore 'cdid' attributes directly supplied by source DOTS clients or client-domain gateways. The first on-path server-domain DOTS gateway inserts 'cdid'; multiple server-domain gateways cannot each insert a value.
When a DOTS signal channel session is established via TLS but DTLS failed, the DOTS client periodically probes to discover whether DTLS becomes available. Such probing SHOULD NOT occur more than every 24 hours and MUST NOT occur more than every 5 minutes.
'cuid' (Client Unique Identifier) is a globally unique, stable identifier generated by the DOTS client, derived as a base64url-encoded truncated SHA-256 hash of the client's SPKI, raw public key, or PSK identity. It SHOULD be 22 characters to avoid UDP fragmentation.
DOTS signal channel session configuration parameters include 'heartbeat-interval', 'missing-hb-allowed', and 'probing-rate', configurable separately for 'idle-config' and 'mitigating-config' states. DOTS agents MUST automatically switch configuration sets upon changes in mitigation activity.
'mid' (Mitigation Identifier) is a per-client integer that uniquely identifies each mitigation request within a given 'cuid' and DOTS server. Higher 'mid' values override lower ones with overlapping scopes; overlapped lower 'mid' entries are automatically deleted.
The 'conflict-information' structure includes 'conflict-status' (1=inactive, 2=active, 3=all inactive), 'conflict-cause' (1=overlapping targets, 2=accept-list conflict, 3=cuid collision), 'conflict-scope', and 'retry-timer' indicating when the DOTS client may reissue the request.
The mitigation scope includes optional attributes: 'target-prefix' (CIDR prefixes), 'target-port-range' (lower/upper bounds), 'target-protocol' (IANA protocol numbers), 'target-fqdn', 'target-uri', 'alias-name', and mandatory 'lifetime'. At least one of target-prefix, target-fqdn, target-uri, or alias-name MUST be present.
'trigger-mitigation' (boolean, default 'true') controls whether DDoS mitigation starts immediately or only when the DOTS signal channel session is lost. Preconfigured mitigations use 'false' and activate on session loss.
RFC 8782 establishes the 'DOTS Signal Channel Protocol' registry with five subregistries: CBOR Key Values, Status Codes, Conflict Status Codes, Conflict Cause Codes, and Attack Status Codes. It also registers UDP/TCP port 4646, the '/.well-known/dots' URI, media type 'application/dots+cbor', a CoAP Content-Format, and a CBOR tag.
All DOTS signal channel traffic MUST be protected by (D)TLS with mutual authentication. DOTS clients are entitled to access only resources they create; a DOTS client cannot retrieve data related to mitigation requests created by other DOTS clients of the same domain.
The 'cuid' is derived from the client's cryptographic identity (SPKI hash or PSK identity hash) to tie the identifier to authentication material and prevent spoofing. DOTS gateways may rewrite 'cuid' values, but servers must enforce per-client access controls.
Mitigation 'status' values define the lifecycle: 1=setup in progress, 2=successfully mitigating, 3=attack stopped (client should withdraw), 4=exceeded mitigation capacity, 5=active but terminating (client withdrew), 6=terminated, 7=withdrawn by server, 8=awaiting signal-loss trigger. Preconfigured mitigations (trigger-mitigation=false) transition from status 3 or 7 to status 8 after four transmissions.
All DOTS signal channel messages are encoded in CBOR (RFC 7049) with content type 'application/dots+cbor'. YANG-modeled parameters are mapped to integer CBOR keys as specified in Table 5 (Section 6). A CBOR tag is registered to identify DOTS signal channel objects.