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]