Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
Extracted elements (26)
ACL attributes are NOT RECOMMENDED in an initial mitigation request for a given mitigation scope or in scope-adjusting requests. This recommendation is explicitly motivated by the desire to avoid delaying attack mitigations because of failures to process ACL attributes.
The activation-type update applied via the DOTS signal channel is maintained as the new activation type for the ACL even after the termination of the mitigation request. This persistence means the signal channel override survives mitigation teardown, and the DOTS client must use the data channel afterward if it wishes to revert.
The DOTS data channel protocol is not designed to withstand attack conditions; when a DDoS attack saturates the inbound link, the DOTS client cannot use the data channel to modify or withdraw filtering rules (e.g., accept-lists that conflict with mitigation). The signal channel is designed to be resilient under exactly these conditions, making it the appropriate vehicle for in-attack filter control.
The DOTS signal and data channels from a DOTS client may use different DOTS servers, yet the scope of mitigation and filtering rules is not restricted to one server but to the entire DOTS server domain. DOTS servers within a domain are assumed to have an unspecified coordination mechanism to align their decisions.
If the DOTS signal and data channels are not established with the same DOTS server in a domain, the request-processing operations described in Section 3.2.1 (ACL lookup, activation-type update, lifetime refresh) are performed using whatever inter-server coordination mechanism the domain employs. RFC 9133 does not specify this coordination mechanism.
The 'ietf-dots-signal-control' YANG module is not intended for use via NETCONF/RESTCONF for DOTS server management; it serves only to provide a data model and CBOR encoding for signal channel messages. A management data model is explicitly out of scope.
This specification does not require any modification to the efficacy update and withdrawal procedures defined in RFC 9132. ACL-related clauses MUST NOT be included in PUT requests used to send efficacy updates or in DELETE requests.
A DOTS client must use the same 'cuid' for both the DOTS signal and data channels (RFC 9132 Section 4.4.1). This requirement facilitates binding of channels used by the same DOTS client and is the mechanism by which ACL names are associated with the correct client across channels.
DOTS clients MUST NOT use filtering control over the DOTS signal channel during 'idle' time (i.e., when no mitigation is active). DOTS servers MUST discard such requests with a 4.00 (Bad Request) response.
If the DOTS server cannot find the ACL name ('acl-name') conveyed in the mitigation request for the given DOTS client, it MUST respond with a 4.04 (Not Found) error response code.
If the DOTS server fails to apply a filter update for any reason, it MUST respond with 5.03 (Service Unavailable) and include the failed ACL update in the diagnostic payload of the response.
If the DOTS server finds the ACL name and the request passes RFC 9132 Section 4.4.1 validation, the DOTS server MUST proceed with the 'activation-type' update and MUST also update the lifetime of the corresponding ACL as it would for a data channel refresh (RFC 8783 Section 7.2).
It is RECOMMENDED for a DOTS client to subscribe to asynchronous notifications of attack mitigation status (RFC 9132 Section 4.4.2.1). If not, the polling mechanism in RFC 9132 Section 4.4.2.2 must be followed.
Upon receiving a 5.03 (Service Unavailable) with a diagnostic payload indicating a failed ACL update on an initial or scope-adjusted mitigation request, the DOTS client MUST immediately resend the request with all original parameters but without the ACL attributes. After Max-Age expires, the client retries with a new 'mid' including the ACL attributes.
When including ACL attributes in a mitigation request—whether it is an initial request or one overriding an existing request—a new 'mid' MUST be used.
'acl-list', 'acl-name', and 'activation-type' are defined as comprehension-required parameters. If the DOTS server does not understand any of these attributes, it must respond with a 4.00 (Bad Request) error per Section 6 of RFC 9132.
'acl-name' is a mandatory sub-attribute of 'acl-list' that names an access list previously defined using the DOTS data channel (RFC 8783 Section 4.3) and associated with the DOTS client. An ACL name uniquely identifies an ACL bound to a given DOTS client, though the same name may be reused by distinct clients.
'activation-type' is an optional sub-attribute of 'acl-list' that overrides the existing activation-type installed via the data channel. Valid values are 'deactivate', 'immediate', and 'activate-when-mitigating'; both 'immediate' and 'activate-when-mitigating' take effect immediately when processed by the DOTS server.
The 'acl-list' attribute is added to the CBOR body of a DOTS signal channel mitigation request. It carries one or more entries each containing 'acl-name' (mandatory, a leafref to an ACL created via the data channel) and 'activation-type' (optional, overrides the existing activation-type for that ACL).
The DOTS signal channel extension augments the 'ietf-dots-signal-channel' YANG module. The 'acl-list' list is keyed on 'acl-name' and added under /dots-signal:dots-signal/message-type/mitigation-scope/scope; 'activation-type' defaults to 'activate-when-mitigating'.
RFC 9133 adds two entries to the 'DOTS Signal Channel CBOR Key Values' subregistry within the IANA 'Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel' registry: 'activation-type' (key 52, CBOR major type 0) and 'ietf-dots-signal-control:acl-list' (key 53, CBOR major type 4), both with IESG as Change Controller.
RFC 9133 registers the YANG module 'ietf-dots-signal-control' (namespace urn:ietf:params:xml:ns:yang:ietf-dots-signal-control, prefix dots-control) in the IANA 'YANG Module Names' subregistry, and registers the corresponding XML namespace URI in the IETF XML Registry.
A compromised DOTS client can exploit the filtering control capability to exacerbate an ongoing attack—for example by activating accept-lists that allow attack traffic through—or may refuse to react to ACL conflict notifications. These are variations of existing DOTS threat vectors; operators should monitor and audit DOTS agents to detect misbehaviors.
A DOTS client is entitled to access only the filtering resources it created; it cannot modify filtering rules created by other DOTS clients of the same domain. DOTS servers must enforce this association, and failure to do so will have severe impact on DOTS client domains.
This specification restricts the signal channel extension to activation/deactivation of existing filters only; creation of new filtering rules remains solely the responsibility of the DOTS data channel (RFC 8783). DOTS client domains should pre-provision filters before attacks so they are available for on-demand activation.
Filter control attributes use the following CBOR encodings: 'activation-type' is encoded with CBOR key 52 (CBOR major type 0, unsigned integer); 'ietf-dots-signal-control:acl-list' is encoded with CBOR key 53 (CBOR major type 4, array). 'acl-name' reuses CBOR key 23 (CBOR major type 3, text string) as defined in RFC 9132.