Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
Extracted elements (31)
Most telemetry functionality is retained in the DOTS signal channel rather than the data channel, even though the data channel normally handles bulk data. This is because telemetry about ongoing attacks must be available during an attack when the data channel may be impaired. The attack mapping database (Section 8.1.6) is the one exception, using the data channel for pre-population during idle time.
The DOTS telemetry YANG module uses 'enumerations' rather than 'identities' to define units, samples, and intervals. Using 'identities' would require the namespace identifier 'ietf-dots-telemetry' to be included in every telemetry attribute value, significantly increasing message size — contrary to the compactness requirement for DOTS signal channel messages.
The 'ietf-dots-telemetry' YANG module omits 'key' statements from some lists because those keys appear as mandatory Uri-Path parameters in CoAP requests rather than in the message body. This avoids duplicating key fields in both the URI and the payload, reducing message size.
In multihomed deployments, a DOTS client maintaining signal channels with multiple upstream DOTS servers MUST only signal telemetry information relevant to the IP prefixes assigned by each upstream network to the channel with that network's DOTS server. Sharing telemetry from one DOTS server with a second DOTS server is implementation and deployment specific.
Server deviations (Section 5.6.3 of RFC 7950) for the 'ietf-dots-telemetry' YANG module are strongly discouraged because peer DOTS agents have no means to retrieve the list of deviations, making interoperability failures likely. The module is not intended for NETCONF/RESTCONF management use.
A DOTS telemetry setup message MUST include only one of: telemetry configuration parameters, pipe capacity information, or traffic baseline information. Requests mixing these three types MUST be rejected by DOTS servers with a 4.00 (Bad Request) Response Code.
At least one of 'target-prefix', 'target-fqdn', 'target-uri', 'alias-name', or 'mid-list' MUST be present in the target definition. Additionally, at least the 'target' attribute and one other pre-or-ongoing-mitigation attribute MUST be present in a DOTS telemetry message.
DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry notifications to the same peer more frequently than once every 'telemetry-notify-interval'. When block-wise transfer is used, all individual blocks of a single notification count as one notification for rate-limiting purposes.
DOTS clients that are interested in receiving pre-or-ongoing-mitigation telemetry from the DOTS server (Section 9.2) MUST set 'server-originated-telemetry' to 'true' in the telemetry configuration. Omitting this field is equivalent to setting it to 'false'.
DOTS implementations MUST support the CoAP Observe Option (RFC 7641) for the '/tm' operation path. This allows DOTS servers to push unsolicited telemetry notifications to subscribing DOTS clients.
DOTS telemetry setup configuration request and response messages MUST be marked as Confirmable CoAP messages. In contrast, pre-or-ongoing-mitigation telemetry request and response messages MUST be marked as Non-confirmable messages.
The 'tsid' identifier MUST increase monotonically whenever new configuration parameters need to be conveyed; the rollover procedure from RFC 9132 Section 4.4.1 for 'mid' MUST be followed for 'tsid' rollover. DOTS servers MUST NOT reset 'tsid' because a session failed with a DOTS client.
Uri-Path parameters and attributes with empty values MUST NOT be present in a request; the presence of any empty value renders the entire containing message invalid.
When generating telemetry data, the DOTS agent MUST auto-scale so that the appropriate unit is used — specifically, the largest unit within a given unit class that yields a value greater than one. Only one unit per unit class is allowed in a telemetry message.
Mitigation efficacy telemetry (Section 9.1, DOTS client to server) reports the client's assessment of how well the ongoing mitigation is working, including total-traffic, total-attack-traffic, and attack-detail attributes. Mitigation status telemetry (Section 9.2, DOTS server to client) provides the server's view of the attack and its mitigation actions.
RFC 9244 specifies two YANG modules: 'ietf-dots-telemetry' for representing DOTS telemetry message types over the signal channel, and 'ietf-dots-mapping' for sharing attack mapping details over the DOTS data channel. The telemetry module is not intended for NETCONF/RESTCONF server management; it serves only to provide a data model and encoding.
The 'attack-detail' attribute captures per-attack metadata including vendor-id (IANA Enterprise Number), attack-id, attack-description, attack-severity, bytes-dropped/packets-dropped/frames-dropped per second, and 'top-talker' information listing the source prefixes generating the most attack traffic.
The normal traffic baseline ('baseline') conveys percentile values of total traffic normal patterns per target, optionally broken down by transport protocol or port number. It also includes 'total-connection-capacity' with limits on simultaneous connections, embryonic connections, connection rates, request rates, and partial requests — all useful for detecting resource-exhaustion DDoS attacks.
The pre-or-ongoing-mitigation telemetry 'telemetry' message type (path '/tm') carries: target identification, total-traffic (with percentiles and current value), total-attack-traffic, total-attack-connection-protocol, and attack-detail. Each entry is keyed by vendor-id and attack-id and can be correlated to mitigation requests via 'mid-list'.
The telemetry configuration negotiation allows DOTS clients to set measurement-interval, measurement-sample, low/mid/high percentile thresholds (defaulting to 10th/50th/90th), unit classes (packets-per-second, bits-per-second, bytes-per-second), telemetry-notify-interval, and whether server-originated telemetry is desired. Servers respond with min/max acceptable values and supported unit classes.
The Telemetry Identifier ('tmid') is a DOTS-client-generated uint32 that uniquely identifies pre-or-ongoing-mitigation telemetry data. A higher 'tmid' value overrides lower-valued entries from the same DOTS client.
The Telemetry Setup Identifier ('tsid') is a DOTS-client-generated uint32 that uniquely identifies a telemetry setup configuration request. It MUST increase monotonically whenever new configuration parameters need to be conveyed, and a higher 'tsid' automatically supersedes and deletes lower-valued entries at the server.
The 'total-pipe-capacity' structure conveys the maximum incoming traffic volume for each ingress interconnection link of the DOTS client domain, keyed by 'link-id' (RFC 8345) and 'unit'. Clients MAY signal per-link or aggregate capacity; setting 'capacity' to 0 removes a link (but all-zero capacity requests are rejected with 4.00).
The 'vendor-attack-mapping' data (YANG module 'ietf-dots-mapping', path over DOTS data channel) allows DOTS clients to pre-populate an attack taxonomy database mapping vendor-id and attack-id to attack type, description, and aliases. This avoids re-sending verbose attack descriptions during active signal-channel exchanges.
Two telemetry operation path suffixes are defined: '/tm-setup' for telemetry setup configuration (Section 7) and '/tm' for pre-or-ongoing-mitigation telemetry (Section 8). These are appended to the DOTS CoAP path prefix to form the full URI.
IANA maintains the 'DOTS Signal Channel CBOR Key Values' registry. RFC 9244 adds new entries for telemetry attributes (e.g., tsid, tmid, telemetry-setup, total-pipe-capacity, baseline, attack-detail, vendor-id, attack-id, top-talker, etc.) to this registry.
IANA maintains the 'DOTS Signal Channel Conflict Cause Codes' registry. RFC 9244 adds cause code 5 ('Overlapping pipe scope') to this registry, supplementing the existing code 1 ('Overlapping targets') defined in RFC 9132.
IANA registers new URIs for the two DOTS telemetry YANG modules ('ietf-dots-telemetry' and 'ietf-dots-mapping') in the 'IETF XML Registry' and 'YANG Module Names' registry, and registers '/tm-setup' and '/tm' in the 'DOTS Signal Channel URI Suffixes' registry.
DOTS telemetry attributes are transmitted over the DOTS signal channel, which requires mutual authentication and encryption (DTLS). A DOTS server MUST treat attack details received from DOTS clients as hints only and cannot completely rely on or trust them, as the client's detection may differ from the server's own analysis.
The vendor attack mapping data exchanged over the DOTS data channel (RESTCONF/HTTPS) carries Enterprise Numbers (vendor-id) and attack taxonomies. Implementations must validate that vendor-id values correspond to legitimate enterprise numbers to prevent spoofed attack classifications from influencing mitigation decisions.
All DOTS telemetry payloads are CBOR-encoded (RFC 8949) with Content-Format 'application/dots+cbor'. Section 12 provides the full YANG/JSON-to-CBOR key mapping table; numeric CBOR keys replace YANG leaf names. DOTS agents MUST use these CBOR keys, not the YANG string names, on the wire.