DOTS T. Reddy
Internet-Draft P. Patil
Intended status: Standards Track M. Geller
Expires: December 31, 2015 D. Wing
S. Rao
Cisco
M. Boucadair
France Telecom
June 29, 2015
Information Model for DDoS Open Threat Signaling (DOTS)
draft-reddy-dots-info-model-00
Abstract
This document discusses the need and the mechanisms to dynamically
update configuration of network monitoring devices to help identify
distributed denial-of-service (DDoS) attacks in a network. Once an
attack is signalled by a client or detected locally, provisioning
cycles are triggered to program a set of network elements to
undertake appropriate actions (including, blackhole, drop, rate-
limit, or add to watch list) on the suspect traffic.
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 December 31, 2015.
Copyright Notice
Copyright (c) 2015 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
Reddy, et al. Expires December 31, 2015 [Page 1]
Internet-Draft Information model for DOTS June 2015
(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
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 . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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 or router, a firewall, or an entire network, etc.
Typically, enterprises configure Network Elements and Monitoring
Devices (appliances) to export traffic flow information for further
processing by applications hosted on other devices, such as DDoS
monitoring applications.
DDoS monitoring applications analyze and correlate flow records to
baseline proper behaviour and measure deviation from that expected
norm ("Observed" vs. "Expected"). Analytics is applied to deliver a
baseline of the network in normal operation conditions and then to
highlight when an anomalous event occurs. As DDoS attacks get more
complex and more sophisticated, DDoS monitoring applications may need
more or different fields in the flow records, change the frequency of
flow record collection, increase the granularity of flow record
collection for traffic to a network resource, tweak the sampling
logic, enable or disable packet sampling, modify the packet selection
technique for sampling, etc., to adjust their decision-making process
for a better detection efficiency.
Reddy, et al. Expires December 31, 2015 [Page 2]
Internet-Draft Information model for DOTS June 2015
This document explains mechanisms to dynamically change the
configuration of IPFIX-compliant Monitoring Devices ([RFC7011]) and
PSAMP-compliant Monitoring Devices ([RFC5476]) using the Network
Configuration Protocol (NETCONF) [RFC6241] to identify attacks on the
network and once an attack is detected, use NETCONF to carry
instructions meant to dynamically enforce appropriate filtering rules
on a set of network devices. In addition to the required
intelligence to decide which actions are needed, a decision-making
process to decide "where" (i.e., which network elements) these
filtering actions are to be performed.
2. Notational Conventions
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].
3. Terminology
This document makes use of the following terms:
o Network Element: refers to a node that is involved in the delivery
of connectivity services. A Network Element can be a router, a
switch, a service function (e.g., firewall), etc.
o DOTS Client: Refers to the entity that is responsible for
signalling an attack. The entity could be a network resource
(e.g. Network application) subjected to attack or flow collector,
firewall, CPE etc. detecting attack on the network.
o DOTS Controller: Refers to the entity that is responsible for
undertaking appropriate actions to satisfy the requests from a
DOTS Client.
o Flow Collector: Refers to the functional entity that is
responsible for instructing the Network Elements about the
monitoring strategy. It is also responsible for collecting
monitoring information from the network. One or multiple Flow
Collectors may be enabled. Considerations about internal
communications between multiple Flow Collectors are out of scope.
A Flow Collector may be collocated with a DOTS Client.
o Configuration Manager: Refers to an entity that is responsible for
the provisioning of a set of Network Elements.
o Monitoring Devices: These are devices in the network that are
provisioned to monitor network flows, collect information and
export them to a "Flow Collector".
Reddy, et al. Expires December 31, 2015 [Page 3]
Internet-Draft Information model for DOTS June 2015
4. Solution Overview
Flow collector (or DDoS monitoring application) needs to program
IPFIX- and PSAMP-compliant Monitoring Devices using vendor-
independent configuration data model. A vendor-independent
configuration data models helps to store and manage the configuration
data of Monitoring Devices in a consistent format. The data model
could be specified using YANG [RFC6020] to dynamically configure
Monitoring Devices. The configuration data models for IPFIX and
PSAMP are discussed in [RFC6728].
In order to offer more automation and dynamicity in changing the
configuration of network monitoring, this document proposes an
architecture that is composed of two parts:
1. Flow Collector communicates the configuration of network
monitoring to the DOTS Controller. This assumes the Flow
Controller has been provisioned with the locator(s) of DOTS
Controller(s) to contact. For multi-homed networks, the Flow
Controller should contact the DOTS Controller attached to the
network from which the suspect traffic is received from.
2. The DOTS Controller is responsible for configuring the Monitoring
Devices. This assumes the DOTS Controller has access to the
underlying network topology (including the interconnection map
and the set of advanced service functions).
Reddy, et al. Expires December 31, 2015 [Page 4]
Internet-Draft Information model for DOTS June 2015
1. Initial DDOS monitoring
provisioning cycle
|
2. Configure monitoring |
devices using NETCONF | 5. DDOS monitoring
| re-provisioning cycle
+--------------+
+---------+-------------------+-------+ |
| | | | DOTS |
| | | | Controller |
V V | +-------+------+
+-------------+ | ^
| Config | | |
| manager | | |
+-------------+ | |
| | | |
| | | |
| +---------+ | |
| | | |
v v v |
+--------+ +--------+ +--------+ |
| Switch | (..) | Middle | | Router | | 4. Update/Modify
+--+-----+ | box | | | | monitoring config
| +---+----+ +--+-----+ |
| | | |
| | | |
| | | +-----+---------+
| | +------> + |
| +---------------------> + Flow |
+--------------------------------------> + collector |
| + Analyzer |
+---------------+
3. Export IPFIX messages, packet samples to flow collector
Figure 1: Configuration Cycle for IPFIX
Figure 1 provides a high level overview of the solution. The
proposed solution is to build a dynamic configuration model in DDoS
Monitoring using a feedback system where a Flow Collector can
influence monitoring configurations on the devices to gather
information about a potential DDoS event.
The sequences marked (1)-(5) in Figure 1 refer to the work flow of
the proposed solution, these flows can be broadly categorized into
three phases:
Reddy, et al. Expires December 31, 2015 [Page 5]
Internet-Draft Information model for DOTS June 2015
1. Initial Provisioning Cycle: Represents the initial state of the
monitoring configuration where an administrator updates the
Controller with a default or preliminary monitoring configuration
delivered to Monitoring Devices. For example, the initial
configuration on the Monitoring Devices is to collect information
elements such as IP addresses/prefixes, application type,
transport ports, flow timestamps, interfaces and so on.
2. Flow Monitoring: Refers to the activity of Monitoring Devices to
inspect and watch network flows. Based on the monitoring
configuration, the Monitoring Device is instructed to collect
specific flow information and export them to a "Flow Collector".
3. Flow Collection and Analysis: A "Flow Collector" device collects
and (possibly) aggregates flow information from one or more
Monitoring Devices. As the Collector continues to gather more
and more data, it can potentially correlate and analyze flow
information to "guess" or determine if a DDoS event is in
progress. If so, the Flow Collector may consider gathering
additional data from the Monitoring Devices and signals this
intent to a "Controller".
4. Re-provisioning Cycle: The Controller receives from the "Flow
Collector", the intent to re-provision Monitoring Devices to
produce additional flow information elements. The Controller,
then delivers the new or updated configuration to the appropriate
Monitoring Devices.
The other provisioning interface is the one between the DOTS
Controller and Network Elements. Concretely, when the Flow Collector
identifies an active attack, it signals to the DOTS Controller the
set of traffic identification information (including all suspect IP
addresses) together with a suggested action (e.g., rate-limit, drop,
monitor). Then, the DOTS Controller propagates the filtering rules
to the Network Elements (including routers, middleboxes). The Flow
Collector, after certain duration, requests the rules to block
traffic from these IP addresses be removed once the attack has
stopped. Means to detect an attack is not valid anymore may be
static (an administrative decision) or dynamic (based on an analysis
of the traffic).
Note, [RFC6088] provides typical information that can be included in
the traffic identification information set.
Reddy, et al. Expires December 31, 2015 [Page 6]
Internet-Draft Information model for DOTS June 2015
a. Configure network devices
using NETCONF
b. Configuration ACK/NACK
+--------------+
+---------+-----------------+------>+ |
| | | | DOTS |
| | | | Controller |
V V | +-------+------+
+-------------+ | ^
| Config | | |
| manager | | | 1. Install/Remove
+-------------+ | | filtering rules
| | | |
| | | | 2. ACK/NACK
| +---------+ | |
| | | |
v v v |
+--------+ +--------+ +--------+ |
| Switch |(...) | Middle | | Router | |
+--------+ | box | | | |
+--------+ +--------+ |
V
+--+--------+
| Flow |
| collector |
|+ Analyzer |
+-----------+
Figure 2: Configuration Cycle for Attack Mitigation
As shown in Figure 3, two distinct interfaces are defined: the one
used by a Flow collector to signal appropriate filtering rules to a
DOTS Controller (for example, [I-D.reddy-dots-transport] can be used
for this interface) and the one to enforce polices in the appropriate
nodes (for example, NETCONF can be used).
Reddy, et al. Expires December 31, 2015 [Page 7]
Internet-Draft Information model for DOTS June 2015
+-----------+ +-----------+
| DOTS | | DOTS |
| Client |<---Signalling Interface--->| Controller|
|[Collector]| | (Server) |
+-----------+ +-----+-----+
^
|
Policy Enforcement Interface
|
+--------------------+-+
| |
+-------------+ |
| Config | |
| manager | |
+-------------+ |
| | |
| | |
| +---------+ |
| | |
v v v
+--------+ +--------+ +--------+
| Switch |(...) | Middle | | Router |
+--------+ | box | | |
+--------+ +--------+
Figure 3: Signalling Interface & Policy Enforcement Interface
DOTS Client and DOTS controller could be located in different
administrative domains. Local decisions (e.g., install filters) can
be made locally be the DOTS Controller. A notification is then sent
to the DOTS Clients using the signaling interface. Concretely, the
decision-making process of the DOTS Controller can be based on events
that are reported by other DOTS Clients, local monitoring tools, etc.
Appropriate notifications and feedback objects should be carried over
the signaling interface.
The signaling interface can also be used by a DOTS Controller to
request a confirmation from a DOTS Client about the enforcement of a
filter. For example, this can occur when the DOTS Controller detects
that some traffic is likely to be a DoS, before undertaking actions
on Network Elements, the DOTS Controller contacts first the DOTS
Client to double check whether that traffic is really a DoS. Upon
confirmation from the DOTS Client, the DOTS Controller initiates a
configuration cycle accordingly.
Reddy, et al. Expires December 31, 2015 [Page 8]
Internet-Draft Information model for DOTS June 2015
5. Security Considerations
The authentication mechanism between the Flow Collector and DOTS
Controller should be immune to pervasive monitoring [RFC7258]. An
attacker can intercept traffic by installing rules that would lead to
redirect all or part of the traffic to an illegitimate Flow
Collector. Means to protect against attacks that would lead to
install, remove, or modify rules must be supported.
In order to protect against denial of service that would be caused by
a misbehaving trusted Flow Collector, DOTS Controller should rate
limit the configuration changes received from a Flow Collector.
6. Acknowledgements
Thanks to C. Jacquenet for the review.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling
(PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
[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, October
2012.
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of
the IP Flow Information Export (IPFIX) Protocol for the
Exchange of Flow Information", STD 77, RFC 7011, September
2013.
Reddy, et al. Expires December 31, 2015 [Page 9]
Internet-Draft Information model for DOTS June 2015
7.2. Informative References
[RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
"Traffic Selectors for Flow Bindings", RFC 6088, January
2011.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, May 2014.
Authors' Addresses
Tirumaleswar Reddy
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: tireddy@cisco.com
Prashanth Patil
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore
India
Email: praspati@cisco.com
Mike Geller
Cisco Systems, Inc.
3250
Florida 33309
USA
Email: mgeller@cisco.com
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134
USA
Email: dwing@cisco.com
Reddy, et al. Expires December 31, 2015 [Page 10]
Internet-Draft Information model for DOTS June 2015
Sandeep Rao
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: rsandeep@cisco.com
Mohamed Boucadair
France Telecom
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Reddy, et al. Expires December 31, 2015 [Page 11]