Distributed Denial-of-Service Open Threat Signaling (DOTS) Information and Data Model
draft-andreasen-dots-info-data-model-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Authors Flemming Andreasen  , Tirumaleswar Reddy.K 
Last updated 2016-09-26
Stream (None)
Formats pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
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]