| DOTS | F. Andreasen |
| Internet-Draft | T. Reddy |
| Intended status: Standards Track | Cisco |
| Expires: March 30, 2017 | September 26, 2016 |
Distributed Denial-of-Service Open Threat Signaling (DOTS) Information and Data Model
draft-andreasen-dots-info-data-model-00
This document defines an information model and a data model for Distributed Denial-of-Service Open Threat Signaling (DOTS). The document specifies the Message and Information Elements that are transported between DOTS agents and their interconnected relationships. The primary purpose of the DOTS Information and Data Model is to address the DOTS requirements and DOTS use cases.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 30, 2017.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 [I-D.ietf-dots-architecture]). 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 (Figure 1).
+---------------+ +---------------+
| | <------- Signal Channel ------> | |
| DOTS Client | | DOTS Server |
| | <======= Data Channel ======> | |
+---------------+ +---------------+
Figure 1: DOTS signal and data channels
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 [I-D.ietf-dots-architecture] , the DOTS use case scenarios, and the DOTS requirements [I-D.ietf-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 [RFC2119].
The reader should be familiar with the terms defined in [I-D.ietf-dots-architecture].
[Editor's note: The following is very much -00 work in progress...]
The Information Model is broken into 3 separate pieces:
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.
General operation and structure:
Signal Channel Messages:
Data Channel Messages:
Protocol version
Attack Target
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)
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
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
Extensions: standard, vendor-specific, supported
TODO
TODO
TODO
TODO
| [I-D.ietf-dots-architecture] | Mortensen, A., Andreasen, F., Reddy, T., christopher_gray3@cable.comcast.com, c., Compton, R. and N. Teague, "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture", Internet-Draft draft-ietf-dots-architecture-00, July 2016. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC6020] | Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010. |
| [RFC6728] | Muenz, G., Claise, B. and P. Aitken, "Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols", RFC 6728, DOI 10.17487/RFC6728, October 2012. |
| [I-D.ietf-dots-requirements] | Mortensen, A., Moskowitz, R. and T. Reddy, "Distributed Denial of Service (DDoS) Open Threat Signaling Requirements", Internet-Draft draft-ietf-dots-requirements-02, July 2016. |
| [RFC6088] | Tsirtsis, G., Giarreta, G., Soliman, H. and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, DOI 10.17487/RFC6088, January 2011. |