Distributed Denial-of-Service Open Threat Signaling (DOTS) Information and Data Model

A distributed denial-of-service (DDoS) attack is an attempt to make machines or network resources unavailable to their intended users. In most cases, sufficient scale can be achieved by compromising enough end-hosts and using those infected hosts to perpetrate and amplify the attack. The victim in this attack can be an application server, a client, a router, a firewall, or an entire network. In order to mitigate a DDoS attack while still providing service to legitimate entities, it is necessary to identify and separate the majority of attack traffic from legitimate traffic and only forward the latter to the entity under attack, which is also known as "scrubbing". Depending on the type of attack, the scrubbing process may be more or less complicated, and in some cases, e.g. a bandwidth saturation, it must be done upstream of the DDoS attack target. DDoS Open Threat Signaling (DOTS) defines an architecture to help solve these issues (see ). In the DOTS architecture, a DDoS attack target is associated with a DOTS client which can signal a DOTS server for help in mitigating an attack. The DOTS client and DOTS server (collectively referred to as DOTS agents) can interact with each other over two different channels: a signal and a data channel, as illustrated in ().

| | | DOTS Client | | DOTS Server | | | <======= Data Channel ======> | | +---------------+ +---------------+]]> The DOTS signal channel is primarily used to convey information related to a possible DDoS attack so appropriate mitigation actions can be undertaken on the suspecT traffic. The DOTS data channel is used for infrequent bulk data exchange between DOTS agents in the aim to significantly augment attack response coordination. In this document, we define the overall information model and data model for the DOTS signal channel and data channel. The information and data models are designed to adhere to the overall DOTS architecture , the DOTS use case scenarios, and the DOTS requirements .

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . The reader should be familiar with the terms defined in .

[Editor's note: The following is very much -00 work in progress...] The Information Model is broken into 3 separate pieces: General, which describes the overall structure of the information model Signal Channel specific Data Channel specific Following these, specific information elements to be used by the above are described.

Security services in the form of authentication, authorization, message integrity and confidentiality are assumed to be handled by lower layers (e.g. DTLS or TLS) and hence they do not form part of the information model. Note: Not clear this is (operationally) sufficient to support the mutual authentication between DOTS client and DOTS server and the following authorization aspects governed by the service relationship that's assumed to be in place between the two. General operation and structure: Base-line functionality (with protocol and data model version) Extended functionality (negotiated, mandatory, optional, incl. data model versioning) Request/response and asynchronous delivery (signal channel) DOTS server discovery [Editors' note: Assume provisioned or DNS-based for now - data model]

Signal Channel Messages: Start session (signal channel) Stop session Open Data Channel Close Data Channel Redirect [Editor's note: At the IETF Berlin meeting, there was discussion around using anycast to possibly avoid redirection - do we keep "redirect" ?] Heartbeat Status (peer-health, incl. attack status, mitigation status and mitigation efficacy) [Editor's note: Some of these may be separate messages per the following] Client Signal specific: "request mitigation", "stop mitigation", "request mitigation status", ("mitigation efficacy update" ?) Server Signal specific: ("mitigation status" ?)

Data Channel Messages: Open Data Channel Close Data Channel Redirect Bulk data exchange (blacklists, whitelists, filters, aliases\names)

Protocol version Attack Target [Editor's note: may be superfluous given Mitigation Scope below"] Agent Id (identity for each DOTS client and server, contains a least a domain portion that can be authenticated) Blacklist (define, retrieve, manage and refer to) Whitelist (defined, retrieve, manage and refer to) Information about the attack (e.g. targeted port range, protocol or scope) [Editor's note: Not clear this is really different from "Mitigation Scope" below - taken from requirement OP-006] Attack telemetry (collected behavioral characteristics defining the nature of a DDoS attack) Mitigator feedback (attack mitigation feedback from server to client, incl. mitigation status [start, stop, metrics, etc.], attack ended and information about mitigation failure) Mitigation efficacy (attack mitigation efficacy feedback from client to server) Mitigation failure (unsupported target type, mitigation capacity exceeded, excessive "clean traffic", out-of-service, etc.) Mitigation Scope: Classless Internet Domain Routing (CIDR) prefixes, BGP prefix, URI, DNS names, E.164, "resource group alias", port range, protocol, or service [Editor's note: comes from requirements - not clear how "protocol" and "service" are defined. Also, consider which URI schemes] [Editor's note: It would probably be useful to structure mitigation scope and related information (like telemetry, blacklist, etc.) into different "types", since different types of targets will have different parameters and different DOTS servers may support differnt types of attack targets] Mitigation Scope Conflict: Nature and scope of conflicting mitigation requests received from two or more clients Resource Group Alias (define in data channel, refer to in signal/data channel; aliases for mitigation scope) Mitigation duration (desired lifetime - renewable) Peer health (? - measure of peer health) Filters Filter-actions: rate-limit, discard Acceptable signal lossiness (for unreliable delivery) Heartbeat interval Data Channel Address [Editor's note: For discussion (not entirely aligned with current architecture draft text); assumes establish signal channel first and learn data channel address through it (would be useful for redirection as well and makes it easier for signal and data channel to terminate on different entities)] Extensions: standard, vendor-specific, supported

TODO