[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

DOTS                                                       F. Andreasen
Internet Draft                                                 T. Reddy
Intended status: Standards Track                                  Cisco
Expires: April 30, 2017                                October 31, 2016



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


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



Andreasen               Expires April 31, 2017                 [Page 1]


Internet-Draft      DOTS Information & Data Model     October 2016 2016


   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.



Table of Contents

   1. Introduction...................................................3
   2. Notational Conventions and Terminology.........................4
   3. Information Model..............................................4
      3.1. General...................................................4
      3.2. Signal Channel Messages...................................6
         3.2.1. Open Signal Channel..................................6
         3.2.2. Close Signal Channel.................................8
         3.2.3. Redirect Signal Channel..............................8
         3.2.4. Request Status Update................................9
         3.2.5. Status Update.......................................10
         3.2.6. Request Mitigation..................................10
         3.2.7. Stop Mitigation.....................................11
      3.3. Data Channel Messages....................................11
         3.3.1. Open Data Channel...................................11
         3.3.2. Close Data Channel..................................12
         3.3.3. Redirect Data Channel...............................12
         3.3.4. SendData............................................12
      3.4. Information Elements.....................................13
         3.4.1. Protocol version....................................13
         3.4.2. Attack Target.......................................13
         3.4.3. Agent Id............................................13
         3.4.4. Blacklist...........................................13
         3.4.5. Whitelist...........................................13
         3.4.6. Attack telemetry....................................13
         3.4.7. Mitigator feedback..................................14
         3.4.8. Mitigation efficacy.................................14
         3.4.9. Mitigation failure..................................14
         3.4.10. Mitigation Scope...................................14
         3.4.11. Mitigation Scope Conflict..........................15
         3.4.12. Resource Group Alias...............................15
         3.4.13. Mitigation duration................................15
         3.4.14. Peer health........................................15
         3.4.15. Filters............................................15
         3.4.16. Filter-actions.....................................15
         3.4.17. Acceptable signal lossiness........................15
         3.4.18. Heartbeat interval.................................16
         3.4.19. Data Channel Address...............................16
         3.4.20. Extensions.........................................16


Andreasen               Expires April 31, 2017                 [Page 2]


Internet-Draft      DOTS Information & Data Model     October 2016 2016


   4. Data Model....................................................16
   5. IANA Considerations...........................................16
   6. Security Considerations.......................................16
   7. Acknowledgements..............................................16
   8. References....................................................17
      8.1. Normative References.....................................17
      8.2. Informative References...................................17

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.



    +---------------+                                 +---------------+
    |               | <------- Signal Channel ------> |               |
    |  DOTS Client  |                                 |  DOTS Server  |
    |               | <=======  Data Channel  ======> |               |
    +---------------+                                 +---------------+

                          : 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


Andreasen               Expires April 31, 2017                 [Page 3]


Internet-Draft      DOTS Information & Data Model     October 2016 2016


   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

   The information model is broken into the following areas:

   o  General, which provides a general high-level overview of the
      overall information model and its structure

   o  Signal Channel specific, which provides an API-style interface
      description for the signal channel

   o  Data Channel specific, which provides an API-style interface
      description for the data channel

   o  Information Element specific, which describes the various
      information elements used by the above

3.1. General

   DOTS supports request/response style interactions as well as
   asynchronous messages as illustrated below:

      DOTS-Request(parameters) => DOTS-Response(parameters)

      DOTS-Notification(parameters)

   DOTS requests, responses and notifications are collectively referred
   to as DOTS messages, and associated with each DOTS message is one or



Andreasen               Expires April 31, 2017                 [Page 4]


Internet-Draft      DOTS Information & Data Model     October 2016 2016


   more parameters. DOTS messages include one or more parameters, each
   of which belong to one of the following categories

   o  Mandatory, which are base DOTS protocol parameters that MUST
      always be included with the message in question.

   o  Optional, which are base DOTS protocol parameters that MAY be
      included with the message in question.

   o  Extensions, which are extended DOTS protocol parameters that MAY
      be included with the message in question.

   Mandatory and optional DOTS protocol parameters MUST be supported by
   all DOTS agents. Extension DOTS protocol parameters define extended
   functionality above and beyond the base DOTS protocol that MAY be
   supported by a particular DOTS agent. The DOTS protocol includes an
   extension framework that enables each DOTS agent to determine which
   extension a peer DOTS agent supports. The extension framework also
   enables a DOTS agent to specify how to handle any unsupported
   extensions.

   DOTS supports versioning in the form of a DOTS protocol version,
   which is included in every DOTS message. If a DOTS agent receives a
   DOTS request with an unsupported protocol version, it will reply
   with a failure and an indication of the protocol version(s)
   supported. This enables a future version of the DOTS protocol to be
   defined in a backwards compatible manner. If a DOTS Notification
   with an unsupported protocol version is received, it will simply be
   discarded.

   All DOTS messages include a message-id and an agent-id. The agent-id
   identifies the originator of the message, whereas the message-id
   provides an identifier for DOTS Request/Response correlation and
   DOTS Notification identification.

   o  [Editor's note: There are different views on whether an agent-id
      is needed at the DOTS level or whether the underlying security
      mechanisms (incl. authenticated identity via (D)TLS) suffices.
      For now, the draft includes an explicit agent-id at the DOTS
      level].

   o  [Editor's note: Need to look more closely at how we ensure
      message-id uniqueness. One option is to include the agent-id from
      the request or notification as part of it. Also, not clear (yet)
      if this is really information/data model or protocol]




Andreasen               Expires April 31, 2017                 [Page 5]


Internet-Draft      DOTS Information & Data Model     October 2016 2016


   DOTS messages are exchanged over the DOTS Signal channel and the
   DOTS Data Channel. In either case, there is a channel establishment
   procedure taking place initially whereby:

   1. The DOTS client determines the address of a DOTS server to
      establish the DOTS channel with. The base DOTS protocol assumes
      the DOTS client has already obtained either this address, or a
      domain name [RFC1034] or DNS SRV name [RFC2782] that can lead to
      it. One way of achieving that is by provisioning.

   2. The DOTS agents mutually authenticate each other. The Information
      and Data model assumes that the DOTS protocol will run on top of
      a secure transport (e.g. TLS [RFC5246] or DTLS [RFC6347]) that
      also provides mutual authentication. The DOTS agent-id will need
      to be tied-to or covered by this transport-level mutual
      authentication. If not, explicit mutual authentication of the
      DOTS agent-id at the DOTS protocol level will be needed

       o [Editor's note: The mutual authentication aspect of the DOTS
          agent-id is a bit sketchy; needs more consideration]


   Note that the mutual authentication of the DOTS agents are needed to
   verify the service relationship between the DOTS client and server
   as well as govern relevant authorization policies with respect
   further DOTS operation (e.g. scrubbing of traffic for the client in
   question).



   o  [Editor's note: The below is work in progress - main focus is on
      overall approach and messages right now. The actual parameters
      are expected to evolve in future versions]



3.2. Signal Channel Messages

   In this section, we describe the signal channel messages.

   o   [Editor's note: Most (all ?) messages can be extended -
      currently not clearly shown in the following]

3.2.1. Open Signal Channel

   The OpenSignalChannel request establishes a signal channel from the
   LocalAgent to the RemoteAgent:


Andreasen               Expires April 31, 2017                 [Page 6]


Internet-Draft      DOTS Information & Data Model     October 2016 2016


      OSCreply OpenSignalChannel(LocalAgentId, RemoteAgent
                                [, ExtensionsSupported])


   LocalAgentId is the local DOTS client id.

   RemoteAgent is one or more of IP-address(es), domain-name and DNS
   SRV name for the remote DOTS agent with which the signal channel is
   to be established. When more than one of these is present, the
   priority order for client use is DNS SRV, domain-name and IP-
   address(es). A lower priority MUST NOT be used unless a higher
   priority fails to produce a response.

   o  Note that the intent of this priority order is not to replace any
      DNS caching but rather to provide a "last resort" in case of DNS
      failure. If domain name use is not desired, then RemoteAgent MUST
      only include IP-address(es).

   ExtensionsSupported may optionally be included to indicate which
   extensions are supported by the DOTS client.



   A successful OSCreply contains the following information:

   o  Response code, which indicates the outcome of the request

   o  RemoteAgentId, which is the peer DOTS agent Id.

   o  SignalChannel, which is a handle for the new signal channel
      assuming the request succeeded

   o  [optional] ExtensionsSupported, which lists the extensions
      supported by the remote DOTS agent.



   A failure OSCreply contains the following information:

   o  Response code, which indicates the outcome of the request

   o  RemoteAgent, which indicates a different agent to establish the
      signal channel with (redirect)

   o  [optional] ExtensionsSupported, which lists the extensions
      supported by the remote DOTS agent.



Andreasen               Expires April 31, 2017                 [Page 7]


Internet-Draft      DOTS Information & Data Model     October 2016 2016






3.2.2. Close Signal Channel

   The CloseSignalChannel request closes a previously established
   signal channel:

      CSCreply CloseSignalChannel(SignalChannel)


   SignalChannel is the handle for the signal channel to be closed.



   The CSCreply contains the following information

   o  Response code, which indicates the outcome of the request





3.2.3. Redirect Signal Channel

   The RedirectSignalChannel request instructs the peer DOTS agent to
   change the signal channel to the alternative DOTS agent indicated.

   o  [Editor's note: At the IETF Berlin meeting, there was discussion
      around using anycast to possibly avoid redirection. Anycast
      however would not be mandatory, and even when supported, it may
      be desirable to "redirect" to a non-anycast address after initial
      discovery for stability]

   o  [Editor's note: Data channel is currently associated with the
      data channel. Either they both have to get redirected or we need
      a way of (re)associating the data channel with the new signal
      channel; maybe a MoveSignalChannel() ?]

   o  [Editor's note: When redirecting the channel, do we redirect the
      existing one or create a new one and close the old one ? The
      latter seems cleaner, albeit more explicit.]


      RSCreply RedirectSignalChannel(SignalChannel, NewAgent)



Andreasen               Expires April 31, 2017                 [Page 8]


Internet-Draft      DOTS Information & Data Model     October 2016 2016


   SignalChannel is the handle for the signal channel to be redirected.

   NewAgent is an IP-address, domain-name or DNS SRV name for the new
   remote DOTS agent with which the signal channel is to be redirected
   to.



   The CSCreply contains the following information

   o  Response code, which indicates the outcome of the request. Note
      that a success response merely indicates successful receipt and
      reply to the request; successful redirection of signal channel is
      not implied.



3.2.4. Request Status Update

   The RequestStatusUpdate message is a notification to the peer agent
   asking it to provide a status update as indicated

      RequestStatusUpdate(Target [, Heartbeat] [, Health] [, Attack]
                                    [, Mitigation] [, Efficacy])


   Target specifies the attack target for which status updates are
   requested

   o  [Editor's note: Need to come up with a more detailed model for
      how we identify and describe targets]

   Heartbeat requests a status update at the heartbeat interval
   specified.

   Health requests health information for the target.

   Attack requests attack information for the target.

   Mitigation requests mitigation status information for the target.

   Efficacy requests mitigation efficacy information for the target.







Andreasen               Expires April 31, 2017                 [Page 9]


Internet-Draft      DOTS Information & Data Model     October 2016 2016


3.2.5. Status Update

   The StatusUpdate message is a notification to the peer agent.
   StatusUpdate provides heartbeat functionality and updates around
   health, attack status, mitigation status and mitigation efficacy



      StatusUpdate(Target, [, HealthStatus] [, AttackStatus]
                     [, MitigationStatus] [, MitigationEfficacy])


   Target specifies the attack target for which status updates are
   provided.

   HealthStatus provides overall health for the target

   AttackStatus provides information about an ongoing attack for the
   target

   o  [Editor's note: Do we need to identify and refer to specific
      attacks for a given target or just the target itself. For now,
      assume just the target itself. Question applies to other
      parameters here as well.]

   MitigationStatus provides information about current mitigation(s) in
   place for the target. The status reflects information from the
   mitigator's point of view.

   MitigationEfficacy provides information about the efficacy of the
   mitigation. The efficacy reflects information from the attack
   target's point of view.





3.2.6. Request Mitigation

   The RequestMitigation message is a notification to the peer agent to
   invoke mitigation for the attack target specified. If the request is
   received and honored, mitigation will commence and a StatusUpdate
   message will be sent to reflect that. Note that either message is
   especially susceptible to loss during an active DDoS attack

      RequestMitigation(Target)



Andreasen               Expires April 31, 2017                [Page 10]


Internet-Draft      DOTS Information & Data Model     October 2016 2016


   Target specifies the attack target for mitigation is requested.



3.2.7. Stop Mitigation

   The StopMitigation message is a notification to the peer agent to
   stop further attack mitigation for the target indicated. The message
   is sent on behalf of the attack target towards the mitigator.

      StopMitigation(Target)

   Target specifies the attack target for which mitigation is to be
   stopped.


3.3. Data Channel Messages

   In this section, we describe the data channel messages.

   o  [Editor's note: Most (all ?) messages can be extended - currently
      not clearly shown in the following]



3.3.1. Open Data Channel

   The OpenDataChannel request opens a Data Channel to be used in
   conjunction with a previously established Signal Channel

      ODCreply OpenDataChannel(SignalChannel [, ExtensionsSupported])


   SignalChannel is the handle for the existing signal channel.

   ExtensionsSupported may optionally be included to indicate which
   extensions are supported by the DOTS client.



   A successful ODCreply contains the following information

   o  DataChannel, which is a handle for the new data channel

   o  [optional] ExtensionsSupported, which lists the extensions
      supported by the remote DOTS agent.



Andreasen               Expires April 31, 2017                [Page 11]


Internet-Draft      DOTS Information & Data Model     October 2016 2016




   A failure ODCreply contains the following information

   o  Response code, which indicates the outcome of the request

   o  RemoteAgent, which indicates a different agent to establish the
      data channel with (redirect)



3.3.2. Close Data Channel

   The CloseDataChannel request closes a previously established data
   channel:

      CDCreply CloseDataChannel(DataChannel)


   DataChannel is the handle for the data channel to be closed.



   The CDCreply contains the following information

   o  Response code, which indicates the outcome of the request



3.3.3. Redirect Data Channel

   o  [Editor's note: Resolve open questions in Redirect Signal Channel
      first]



3.3.4. SendData

   The SendData request sends data to the peer DOTS agent over the data
   channel.

      SDreply SendData(DataChannelData)


   DataChannelData may contain one or more of the following:

   o  Blacklists, whitelists, filters, aliases\names)


Andreasen               Expires April 31, 2017                [Page 12]


Internet-Draft      DOTS Information & Data Model     October 2016 2016


   [Editor's note: The above needs much more work and overall
   structure. Break up into individual pieces and make sure it's
   modular,  extensible and we have clarity on which data is mandatory
   versus optional to support]



3.4. Information Elements

   o  [Editor's note: The following should merely be considered as a
      bucket of possible IEs at this point; further work needed,
      including reconciling with message definitions in sections above]


3.4.1. Protocol version



3.4.2. Attack Target

   o  [Editor's note: may be superfluous given Mitigation Scope below"]



3.4.3. Agent Id

   (identity for each DOTS client and server, contains a least a domain
   portion that can be authenticated)



3.4.4. Blacklist

   (define, retrieve, manage and refer to)



3.4.5. Whitelist

   (define, retrieve, manage and refer to)



3.4.6. Attack telemetry

   (collected behavioral characteristics defining the nature of a DDoS
   attack)


Andreasen               Expires April 31, 2017                [Page 13]


Internet-Draft      DOTS Information & Data Model     October 2016 2016


   o  [9/27: Probably extended functionality.]



3.4.7. Mitigator feedback

   (attack mitigation feedback from server to client, incl. mitigation
   status [start, stop, metrics, etc.], attack ended and information
   about mitigation failure)



3.4.8. Mitigation efficacy

   (attack mitigation efficacy feedback from client to server)



3.4.9. Mitigation failure

   (unsupported target type, mitigation capacity exceeded, excessive
   "clean traffic", out-of-service, etc.)



3.4.10. 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 different types of attack targets]

   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]



Andreasen               Expires April 31, 2017                [Page 14]


Internet-Draft      DOTS Information & Data Model     October 2016 2016


   o  [9/27: Roland doesn't think we need this as baseline
      information.]



3.4.11. Mitigation Scope Conflict

   Nature and scope of conflicting mitigation requests received from
   two or more clients



3.4.12. Resource Group Alias

   (define in data channel, refer to in signal/data channel; aliases
   for mitigation scope)



3.4.13. Mitigation duration

    (desired lifetime - renewable)



3.4.14. Peer health

    (? - measure of peer health)



3.4.15. Filters



3.4.16. Filter-actions

   (rate-limit, discard)



3.4.17. Acceptable signal lossiness

    (for unreliable delivery)





Andreasen               Expires April 31, 2017                [Page 15]


Internet-Draft      DOTS Information & Data Model     October 2016 2016


3.4.18. Heartbeat interval



3.4.19. 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)]



3.4.20. Extensions

   (standard, vendor-specific, supported)



4. Data Model

   TODO



5. IANA Considerations

   TODO



6. Security Considerations

   TODO



7. Acknowledgements

   TODO

   This document was prepared using 2-Word-v2.0.template.dot.






Andreasen               Expires April 31, 2017                [Page 16]


Internet-Draft      DOTS Information & Data Model     October 2016 2016


8. References

8.1. Normative References

   [RFC1034] Mockapetris, P.V., "Domain Names - concept and
             facilities", RFC 1034, November 1987.

   [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
             specifying the location of services (DNS SRV)", RFC 2782,
             February 2000.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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.

   [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.





8.2. Informative References

   [RFC5246] Dierks, T., and E. Rescorla, "The Transport Layer Security
   (TLS) Protocol Version 1.2", RFC 5246, August 2008

   [RFC6347] Rescorla, E., and N. Modadugu, "Datagram Transport Layer
   Security Version 1.2", RFC 6347, January 2012













Andreasen               Expires April 31, 2017                [Page 17]


Internet-Draft      DOTS Information & Data Model     October 2016 2016


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               Expires April 31, 2017                [Page 18]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/