| 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
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.
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 (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 (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.
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.
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.
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].
This document makes use of the following terms:
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. 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:
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.
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).
+-----------+ +-----------+
| 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.
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.
Thanks to C. Jacquenet for the review.
| [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. |
| [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. |