One document matched: draft-reddy-dots-info-model-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-reddy-dots-info-model-00" ipr="trust200902">
<front>
<title abbrev="Information model for DOTS">Information Model for DDoS Open
Threat Signaling (DOTS)</title>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>tireddy@cisco.com</email>
</address>
</author>
<author fullname="Prashanth Patil" initials="P." surname="Patil">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<country>India</country>
</postal>
<email>praspati@cisco.com</email>
</address>
</author>
<author fullname="Mike Geller" initials="M." surname="Geller">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>3250</street>
<city></city>
<region>Florida</region>
<code>33309</code>
<country>USA</country>
</postal>
<email>mgeller@cisco.com</email>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>California</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<author fullname="Sandeep Rao" initials="S." surname="Rao">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>rsandeep@cisco.com</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<date />
<workgroup>DOTS</workgroup>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>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.</t>
<t>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.</t>
<t>This document explains mechanisms to dynamically change the
configuration of IPFIX-compliant Monitoring Devices (<xref
target="RFC7011"></xref>) and PSAMP-compliant Monitoring Devices (<xref
target="RFC5476"></xref>) using the Network Configuration Protocol
(NETCONF) <xref target="RFC6241"></xref> 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.</t>
</section>
<section anchor="notation" title="Notational Conventions">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Terminology">
<t>This document makes use of the following terms:<list style="symbols">
<t>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.</t>
<t>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.</t>
<t>DOTS Controller: Refers to the entity that is responsible for
undertaking appropriate actions to satisfy the requests from a DOTS
Client.</t>
<t>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.</t>
<t>Configuration Manager: Refers to an entity that is responsible
for the provisioning of a set of Network Elements.</t>
<t>Monitoring Devices: These are devices in the network that are
provisioned to monitor network flows, collect information and export
them to a "Flow Collector".</t>
</list></t>
</section>
<section title="Solution Overview">
<t>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
<xref target="RFC6020"></xref> to dynamically configure Monitoring
Devices. The configuration data models for IPFIX and PSAMP are discussed
in <xref target="RFC6728"></xref>.</t>
<t>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:</t>
<t><list style="numbers">
<t>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.</t>
<t>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).</t>
</list></t>
<t><figure anchor="figure1" title="Configuration Cycle for IPFIX">
<artwork><![CDATA[
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
]]></artwork>
</figure></t>
<t><xref target="figure1"></xref> 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.</t>
<t>The sequences marked (1)-(5) in <xref target="figure1"></xref> refer
to the work flow of the proposed solution, these flows can be broadly
categorized into three phases:</t>
<t><list style="numbers">
<t>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.</t>
<t>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".</t>
<t>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".</t>
<t>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.</t>
</list></t>
<t>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).</t>
<t>Note, <xref target="RFC6088"></xref> provides typical information
that can be included in the traffic identification information set.</t>
<t><figure anchor="figure2"
title="Configuration Cycle for Attack Mitigation">
<artwork><![CDATA[
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 |
+-----------+
]]></artwork>
</figure></t>
<t>As shown in <xref target="fig3"></xref>, 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).</t>
<t><figure align="center" anchor="fig3"
title="Signalling Interface & Policy Enforcement Interface">
<artwork><![CDATA[
+-----------+ +-----------+
| DOTS | | DOTS |
| Client |<---Signalling Interface--->| Controller|
|[Collector]| | (Server) |
+-----------+ +-----+-----+
^
|
Policy Enforcement Interface
|
+--------------------+-+
| |
+-------------+ |
| Config | |
| manager | |
+-------------+ |
| | |
| | |
| +---------+ |
| | |
v v v
+--------+ +--------+ +--------+
| Switch |(...) | Middle | | Router |
+--------+ | box | | |
+--------+ +--------+
]]></artwork>
</figure></t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>The authentication mechanism between the Flow Collector and DOTS
Controller should be immune to pervasive monitoring <xref
target="RFC7258"></xref>. 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.</t>
<t>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.</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>Thanks to C. Jacquenet for the review.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.7011"?>
<?rfc include="reference.RFC.6728"?>
<?rfc include="reference.RFC.6241"?>
<?rfc include="reference.RFC.6020"?>
<?rfc include="reference.RFC.5476"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.7258"?>
<?rfc include='reference.RFC.6088'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:56:10 |