Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification
Extracted elements (25)
A new 'fragment' matching field is introduced for both IPv4 and IPv6 because RFC 8519 lacked IPv6 fragment support and its IPv4 'flags' field does not allow bitmask definition, meaning packets with other flag bits set would bypass ACEs that use 'flags' alone.
New DOTS-specific ACL/ACE structures are defined rather than augmenting the existing 'ietf-access-control-list' (RFC 8519), because that model did not support per-client retrieval or deletion of filtering entries, both of which are required for DOTS operation.
The 'reject' forwarding action (drop and send ICMP error) is intentionally not supported in 'ietf-dots-data-channel'. Generating ICMP error messages during DDoS mitigation would both exacerbate the attack and provide explicit feedback to the attacker that traffic is being blocked.
The same ICMP match structure is used for both ICMP and ICMPv6. Whether an ACL targets ICMP or ICMPv6 is governed by the 'l3' match choice or the ACL type, not by separate protocol-specific containers.
A DOTS client MUST register with its DOTS server(s) by creating a 'dots-client' resource (via POST or PUT) before using the data channel. The registration MUST include a 'cuid' parameter; requests missing 'cuid' MUST be rejected with '400 Bad Request' and error-tag 'missing-attribute'.
A DOTS server MUST maintain a filtering rule for at least 10080 minutes (1 week). If no refresh request is received, the server removes expired entries. A refresh is typically a PUT that echoes the GET response with read-only parameters (e.g., 'pending-lifetime') stripped out.
A DOTS server MUST maintain an alias entry for at least 10080 minutes (1 week). If no refresh request is received from the DOTS client before expiry, the DOTS server removes the expired entry.
DOTS clients MUST use the same 'cuid' for both the signal channel and the data channel. The 'cuid' is a globally unique identifier that prevents request collisions, with the same syntax and processing rules as defined in RFC 8782.
DOTS clients SHOULD reuse the same TLS session for multiple requests and responses to reduce workload. While quiescent, a DOTS client MAY probe the server (e.g., via TLS heartbeat per RFC 6520) to verify cryptographic state and maintain NAT/firewall bindings.
DOTS clients that support both 'fragment' and 'flags' matching fields (or 'flags-bitmask' and 'flags') MUST NOT set these fields in the same ACE request, as they serve overlapping purposes.
DOTS implementations MUST support matching based on IPv4 and IPv6 headers, transport headers (TCP, UDP, ICMP), and any combination thereof. Mandatory fields per ACL type are: IPv4/IPv6 (length, protocol, destination/source prefix, fragment); TCP (flags-bitmask, source/destination port range); UDP (length, source/destination port range); ICMP (type, code).
DOTS servers MUST limit the number of 'dots-client' resources to 1 per request; requests with multiple 'dots-client' resources MUST be rejected. A '409 Conflict' status-line MUST be returned if the data resource already exists.
If a filtering request conflicts with an existing rule from another DOTS client in the same domain and no local policy is set, the DOTS server returns a '409 Conflict' status-line with error-tag 'resource-denied'. DOTS servers SHOULD support a configurable conflict-resolution policy (e.g., reject all, reject new, notify administrator).
If the 'activation-type' attribute is not provided in a filtering rule request, the DOTS server MUST use 'activate-when-mitigating' as the default. When mitigation is active, the DOTS server MUST only activate 'activate-when-mitigating' filters bound to the DOTS client that triggered the mitigation.
In order to detect and prevent infinite loops, DOTS gateways MUST check that none of their own information appears in the Via header field. If a loop is detected, the gateway MUST NOT forward the message and SHOULD return '508 Loop Detected'. Otherwise, the DOTS agent MUST update or insert the Via header field with its own information.
The 'target-prefix' list in alias creation MUST NOT include broadcast, loopback, or multicast addresses. DOTS servers MUST validate that supplied prefixes are within the scope of the DOTS client domain; FQDN-resolved addresses are subject to the same validation.
When DOTS gateways are involved, the same 'cdid' (client domain identifier) handling rules from RFC 8782 MUST be followed. A DOTS gateway MUST strip the 'cdid' parameter from a PUT response before forwarding it to the DOTS client.
An alias groups target resources (target-prefix, target-port-range, target-protocol, target-fqdn, target-uri) under a named identifier. At least one of 'target-prefix', 'target-fqdn', or 'target-uri' MUST be present. Aliases created via the data channel can be referenced efficiently in subsequent DOTS signal channel mitigation requests.
The 'activation-type' enumeration controls when an ACL is enforced: 'activate-when-mitigating' (value 1) installs the ACL only during active mitigation for the DOTS client; 'immediate' (value 2) activates it immediately; 'deactivate' (value 3) stores the ACL without activating it.
The 'capabilities' read-only container allows a DOTS client to discover which match fields and forwarding actions a DOTS server supports, covering address-family, forwarding-actions, rate-limit, transport-protocols, and per-protocol field support for IPv4, IPv6, TCP, UDP, and ICMP.
The DOTS data channel uses RESTCONF over TLS over TCP as its transport stack. JSON payloads (encoded per RFC 7951) carry DOTS data-channel-specific messages. This layering provides reliable delivery required for bulk data exchange.
The 'flags-bitmask' grouping for TCP matching uses a uint16 'bitmask' field that matches the last 4 bits of byte 12 and byte 13 of the TCP header (the 4 TCP data-offset bits in byte 12 are excluded). An 'operator' field (not/match/any) governs interpretation.
The 'fragment-type' bitmask field supports four fragment states: 'df' (Don't Fragment, IPv4 only), 'isf' (Is a Fragment), 'ff' (First Fragment), and 'lf' (Last Fragment). An 'operator' field (not/match/any) governs how the bitmask is applied.
This document registers the YANG module 'ietf-dots-data-channel' (namespace 'urn:ietf:params:xml:ns:yang:ietf-dots-data-channel', prefix 'data-channel') in the IANA 'YANG Module Names' registry. The module revision date is 2020-05-28.
DOTS servers MUST validate that IP prefixes in alias and filtering requests (including those resolved from FQDNs or URIs) fall within the scope of the DOTS client's domain. Prefix lists MUST NOT include broadcast, loopback, or multicast addresses. Mutual authentication between DOTS agents is required, as specified in Section 8 of RFC 8782.