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 Abstract 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. Status of This Memo 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 Notice 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 Andreasen & Reddy Expires March 30, 2017 [Page 1]
Internet-Draft DOTS Information Model September 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Notational Conventions and Terminology . . . . . . . . . . . 3 3. Information Model . . . . . . . . . . . . . . . . . . . . . . 3 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Signal Channel Specific . . . . . . . . . . . . . . . . . 4 3.3. Data Channel Specific . . . . . . . . . . . . . . . . . . 5 3.4. Information Elements . . . . . . . . . . . . . . . . . . 5 4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction 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). Andreasen & Reddy Expires March 30, 2017 [Page 2]
Internet-Draft DOTS Information Model September 2016 +---------------+ +---------------+ | | <------- 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] . 2. Notational Conventions and Terminology 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]. 3. Information Model [Editor's note: The following is very much -00 work in progress...] The Information Model is broken into 3 separate pieces: o General, which describes the overall structure of the information model o Signal Channel specific o Data Channel specific Following these, specific information elements to be used by the above are described. Andreasen & Reddy Expires March 30, 2017 [Page 3]
Internet-Draft DOTS Information Model September 2016 3.1. General 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. o 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: o Base-line functionality (with protocol and data model version) o Extended functionality (negotiated, mandatory, optional, incl. data model versioning) o Request/response and asynchronous delivery (signal channel) o DOTS server discovery [Editors' note: Assume provisioned or DNS- based for now - data model] 3.2. Signal Channel Specific Signal Channel Messages: o Start session (signal channel) o Stop session o Open Data Channel o Close Data Channel o Redirect * [Editor's note: At the IETF Berlin meeting, there was discussion around using anycast to possibly avoid redirection - do we keep "redirect" ?] o Heartbeat o Status (peer-health, incl. attack status, mitigation status and mitigation efficacy) Andreasen & Reddy Expires March 30, 2017 [Page 4]
Internet-Draft DOTS Information Model September 2016 * [Editor's note: Some of these may be separate messages per the following] o Client Signal specific: "request mitigation", "stop mitigation", "request mitigation status", ("mitigation efficacy update" ?) o Server Signal specific: ("mitigation status" ?) 3.3. Data Channel Specific Data Channel Messages: o Open Data Channel o Close Data Channel o Redirect o Bulk data exchange (blacklists, whitelists, filters, aliases\names) 3.4. Information Elements Protocol version Attack Target o [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) o [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) Andreasen & Reddy Expires March 30, 2017 [Page 5]
Internet-Draft DOTS Information Model September 2016 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 o [Editor's note: comes from requirements - not clear how "protocol" and "service" are defined. Also, consider which URI schemes] o [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 o [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 Andreasen & Reddy Expires March 30, 2017 [Page 6]
Internet-Draft DOTS Information Model September 2016 4. Data Model TODO 5. IANA Considerations TODO 6. Security Considerations TODO 7. Acknowledgements TODO 8. References 8.1. Normative References [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", draft-ietf-dots- architecture-00 (work in progress), 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, <http://www.rfc-editor.org/info/rfc2119>. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>. [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, <http://www.rfc-editor.org/info/rfc6728>. 8.2. Informative References Andreasen & Reddy Expires March 30, 2017 [Page 7]
Internet-Draft DOTS Information Model September 2016 [I-D.ietf-dots-requirements] Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed Denial of Service (DDoS) Open Threat Signaling Requirements", draft-ietf-dots-requirements-02 (work in progress), 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, <http://www.rfc-editor.org/info/rfc6088>. Authors' Addresses Flemming Andreasen Cisco Systems, Inc. USA Email: fandreas@cisco.com Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India Email: tireddy@cisco.com Andreasen & Reddy Expires March 30, 2017 [Page 8]