Internet DRAFT - draft-andreasen-dots-info-data-model
draft-andreasen-dots-info-data-model
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]
