idnits 2.17.1 draft-reddy-dots-info-model-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 29, 2015) is 3217 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.reddy-dots-transport' is mentioned on line 294, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS T. Reddy 3 Internet-Draft P. Patil 4 Intended status: Standards Track M. Geller 5 Expires: December 31, 2015 D. Wing 6 S. Rao 7 Cisco 8 M. Boucadair 9 France Telecom 10 June 29, 2015 12 Information Model for DDoS Open Threat Signaling (DOTS) 13 draft-reddy-dots-info-model-00 15 Abstract 17 This document discusses the need and the mechanisms to dynamically 18 update configuration of network monitoring devices to help identify 19 distributed denial-of-service (DDoS) attacks in a network. Once an 20 attack is signalled by a client or detected locally, provisioning 21 cycles are triggered to program a set of network elements to 22 undertake appropriate actions (including, blackhole, drop, rate- 23 limit, or add to watch list) on the suspect traffic. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 31, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 67 7.2. Informative References . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 A distributed denial-of-service (DDoS) attack is an attempt to make 73 machines or network resources unavailable to their intended users. 74 In most cases, sufficient scale can be achieved by compromising 75 enough end-hosts and using those infected hosts to perpetrate and 76 amplify the attack. The victim in this attack can be an application 77 server, a client or router, a firewall, or an entire network, etc. 78 Typically, enterprises configure Network Elements and Monitoring 79 Devices (appliances) to export traffic flow information for further 80 processing by applications hosted on other devices, such as DDoS 81 monitoring applications. 83 DDoS monitoring applications analyze and correlate flow records to 84 baseline proper behaviour and measure deviation from that expected 85 norm ("Observed" vs. "Expected"). Analytics is applied to deliver a 86 baseline of the network in normal operation conditions and then to 87 highlight when an anomalous event occurs. As DDoS attacks get more 88 complex and more sophisticated, DDoS monitoring applications may need 89 more or different fields in the flow records, change the frequency of 90 flow record collection, increase the granularity of flow record 91 collection for traffic to a network resource, tweak the sampling 92 logic, enable or disable packet sampling, modify the packet selection 93 technique for sampling, etc., to adjust their decision-making process 94 for a better detection efficiency. 96 This document explains mechanisms to dynamically change the 97 configuration of IPFIX-compliant Monitoring Devices ([RFC7011]) and 98 PSAMP-compliant Monitoring Devices ([RFC5476]) using the Network 99 Configuration Protocol (NETCONF) [RFC6241] to identify attacks on the 100 network and once an attack is detected, use NETCONF to carry 101 instructions meant to dynamically enforce appropriate filtering rules 102 on a set of network devices. In addition to the required 103 intelligence to decide which actions are needed, a decision-making 104 process to decide "where" (i.e., which network elements) these 105 filtering actions are to be performed. 107 2. Notational Conventions 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. Terminology 115 This document makes use of the following terms: 117 o Network Element: refers to a node that is involved in the delivery 118 of connectivity services. A Network Element can be a router, a 119 switch, a service function (e.g., firewall), etc. 121 o DOTS Client: Refers to the entity that is responsible for 122 signalling an attack. The entity could be a network resource 123 (e.g. Network application) subjected to attack or flow collector, 124 firewall, CPE etc. detecting attack on the network. 126 o DOTS Controller: Refers to the entity that is responsible for 127 undertaking appropriate actions to satisfy the requests from a 128 DOTS Client. 130 o Flow Collector: Refers to the functional entity that is 131 responsible for instructing the Network Elements about the 132 monitoring strategy. It is also responsible for collecting 133 monitoring information from the network. One or multiple Flow 134 Collectors may be enabled. Considerations about internal 135 communications between multiple Flow Collectors are out of scope. 136 A Flow Collector may be collocated with a DOTS Client. 138 o Configuration Manager: Refers to an entity that is responsible for 139 the provisioning of a set of Network Elements. 141 o Monitoring Devices: These are devices in the network that are 142 provisioned to monitor network flows, collect information and 143 export them to a "Flow Collector". 145 4. Solution Overview 147 Flow collector (or DDoS monitoring application) needs to program 148 IPFIX- and PSAMP-compliant Monitoring Devices using vendor- 149 independent configuration data model. A vendor-independent 150 configuration data models helps to store and manage the configuration 151 data of Monitoring Devices in a consistent format. The data model 152 could be specified using YANG [RFC6020] to dynamically configure 153 Monitoring Devices. The configuration data models for IPFIX and 154 PSAMP are discussed in [RFC6728]. 156 In order to offer more automation and dynamicity in changing the 157 configuration of network monitoring, this document proposes an 158 architecture that is composed of two parts: 160 1. Flow Collector communicates the configuration of network 161 monitoring to the DOTS Controller. This assumes the Flow 162 Controller has been provisioned with the locator(s) of DOTS 163 Controller(s) to contact. For multi-homed networks, the Flow 164 Controller should contact the DOTS Controller attached to the 165 network from which the suspect traffic is received from. 167 2. The DOTS Controller is responsible for configuring the Monitoring 168 Devices. This assumes the DOTS Controller has access to the 169 underlying network topology (including the interconnection map 170 and the set of advanced service functions). 172 1. Initial DDOS monitoring 173 provisioning cycle 174 | 175 2. Configure monitoring | 176 devices using NETCONF | 5. DDOS monitoring 177 | re-provisioning cycle 178 +--------------+ 179 +---------+-------------------+-------+ | 180 | | | | DOTS | 181 | | | | Controller | 182 V V | +-------+------+ 183 +-------------+ | ^ 184 | Config | | | 185 | manager | | | 186 +-------------+ | | 187 | | | | 188 | | | | 189 | +---------+ | | 190 | | | | 191 v v v | 192 +--------+ +--------+ +--------+ | 193 | Switch | (..) | Middle | | Router | | 4. Update/Modify 194 +--+-----+ | box | | | | monitoring config 195 | +---+----+ +--+-----+ | 196 | | | | 197 | | | | 198 | | | +-----+---------+ 199 | | +------> + | 200 | +---------------------> + Flow | 201 +--------------------------------------> + collector | 202 | + Analyzer | 203 +---------------+ 204 3. Export IPFIX messages, packet samples to flow collector 206 Figure 1: Configuration Cycle for IPFIX 208 Figure 1 provides a high level overview of the solution. The 209 proposed solution is to build a dynamic configuration model in DDoS 210 Monitoring using a feedback system where a Flow Collector can 211 influence monitoring configurations on the devices to gather 212 information about a potential DDoS event. 214 The sequences marked (1)-(5) in Figure 1 refer to the work flow of 215 the proposed solution, these flows can be broadly categorized into 216 three phases: 218 1. Initial Provisioning Cycle: Represents the initial state of the 219 monitoring configuration where an administrator updates the 220 Controller with a default or preliminary monitoring configuration 221 delivered to Monitoring Devices. For example, the initial 222 configuration on the Monitoring Devices is to collect information 223 elements such as IP addresses/prefixes, application type, 224 transport ports, flow timestamps, interfaces and so on. 226 2. Flow Monitoring: Refers to the activity of Monitoring Devices to 227 inspect and watch network flows. Based on the monitoring 228 configuration, the Monitoring Device is instructed to collect 229 specific flow information and export them to a "Flow Collector". 231 3. Flow Collection and Analysis: A "Flow Collector" device collects 232 and (possibly) aggregates flow information from one or more 233 Monitoring Devices. As the Collector continues to gather more 234 and more data, it can potentially correlate and analyze flow 235 information to "guess" or determine if a DDoS event is in 236 progress. If so, the Flow Collector may consider gathering 237 additional data from the Monitoring Devices and signals this 238 intent to a "Controller". 240 4. Re-provisioning Cycle: The Controller receives from the "Flow 241 Collector", the intent to re-provision Monitoring Devices to 242 produce additional flow information elements. The Controller, 243 then delivers the new or updated configuration to the appropriate 244 Monitoring Devices. 246 The other provisioning interface is the one between the DOTS 247 Controller and Network Elements. Concretely, when the Flow Collector 248 identifies an active attack, it signals to the DOTS Controller the 249 set of traffic identification information (including all suspect IP 250 addresses) together with a suggested action (e.g., rate-limit, drop, 251 monitor). Then, the DOTS Controller propagates the filtering rules 252 to the Network Elements (including routers, middleboxes). The Flow 253 Collector, after certain duration, requests the rules to block 254 traffic from these IP addresses be removed once the attack has 255 stopped. Means to detect an attack is not valid anymore may be 256 static (an administrative decision) or dynamic (based on an analysis 257 of the traffic). 259 Note, [RFC6088] provides typical information that can be included in 260 the traffic identification information set. 262 a. Configure network devices 263 using NETCONF 264 b. Configuration ACK/NACK 265 +--------------+ 266 +---------+-----------------+------>+ | 267 | | | | DOTS | 268 | | | | Controller | 269 V V | +-------+------+ 270 +-------------+ | ^ 271 | Config | | | 272 | manager | | | 1. Install/Remove 273 +-------------+ | | filtering rules 274 | | | | 275 | | | | 2. ACK/NACK 276 | +---------+ | | 277 | | | | 278 v v v | 279 +--------+ +--------+ +--------+ | 280 | Switch |(...) | Middle | | Router | | 281 +--------+ | box | | | | 282 +--------+ +--------+ | 283 V 284 +--+--------+ 285 | Flow | 286 | collector | 287 |+ Analyzer | 288 +-----------+ 290 Figure 2: Configuration Cycle for Attack Mitigation 292 As shown in Figure 3, two distinct interfaces are defined: the one 293 used by a Flow collector to signal appropriate filtering rules to a 294 DOTS Controller (for example, [I-D.reddy-dots-transport] can be used 295 for this interface) and the one to enforce polices in the appropriate 296 nodes (for example, NETCONF can be used). 298 +-----------+ +-----------+ 299 | DOTS | | DOTS | 300 | Client |<---Signalling Interface--->| Controller| 301 |[Collector]| | (Server) | 302 +-----------+ +-----+-----+ 303 ^ 304 | 305 Policy Enforcement Interface 306 | 307 +--------------------+-+ 308 | | 309 +-------------+ | 310 | Config | | 311 | manager | | 312 +-------------+ | 313 | | | 314 | | | 315 | +---------+ | 316 | | | 317 v v v 318 +--------+ +--------+ +--------+ 319 | Switch |(...) | Middle | | Router | 320 +--------+ | box | | | 321 +--------+ +--------+ 323 Figure 3: Signalling Interface & Policy Enforcement Interface 325 DOTS Client and DOTS controller could be located in different 326 administrative domains. Local decisions (e.g., install filters) can 327 be made locally be the DOTS Controller. A notification is then sent 328 to the DOTS Clients using the signaling interface. Concretely, the 329 decision-making process of the DOTS Controller can be based on events 330 that are reported by other DOTS Clients, local monitoring tools, etc. 331 Appropriate notifications and feedback objects should be carried over 332 the signaling interface. 334 The signaling interface can also be used by a DOTS Controller to 335 request a confirmation from a DOTS Client about the enforcement of a 336 filter. For example, this can occur when the DOTS Controller detects 337 that some traffic is likely to be a DoS, before undertaking actions 338 on Network Elements, the DOTS Controller contacts first the DOTS 339 Client to double check whether that traffic is really a DoS. Upon 340 confirmation from the DOTS Client, the DOTS Controller initiates a 341 configuration cycle accordingly. 343 5. Security Considerations 345 The authentication mechanism between the Flow Collector and DOTS 346 Controller should be immune to pervasive monitoring [RFC7258]. An 347 attacker can intercept traffic by installing rules that would lead to 348 redirect all or part of the traffic to an illegitimate Flow 349 Collector. Means to protect against attacks that would lead to 350 install, remove, or modify rules must be supported. 352 In order to protect against denial of service that would be caused by 353 a misbehaving trusted Flow Collector, DOTS Controller should rate 354 limit the configuration changes received from a Flow Collector. 356 6. Acknowledgements 358 Thanks to C. Jacquenet for the review. 360 7. References 362 7.1. Normative References 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, March 1997. 367 [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling 368 (PSAMP) Protocol Specifications", RFC 5476, March 2009. 370 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 371 Network Configuration Protocol (NETCONF)", RFC 6020, 372 October 2010. 374 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 375 Bierman, "Network Configuration Protocol (NETCONF)", RFC 376 6241, June 2011. 378 [RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration Data 379 Model for the IP Flow Information Export (IPFIX) and 380 Packet Sampling (PSAMP) Protocols", RFC 6728, October 381 2012. 383 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 384 the IP Flow Information Export (IPFIX) Protocol for the 385 Exchange of Flow Information", STD 77, RFC 7011, September 386 2013. 388 7.2. Informative References 390 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 391 "Traffic Selectors for Flow Bindings", RFC 6088, January 392 2011. 394 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 395 Attack", BCP 188, RFC 7258, May 2014. 397 Authors' Addresses 399 Tirumaleswar Reddy 400 Cisco Systems, Inc. 401 Cessna Business Park, Varthur Hobli 402 Sarjapur Marathalli Outer Ring Road 403 Bangalore, Karnataka 560103 404 India 406 Email: tireddy@cisco.com 408 Prashanth Patil 409 Cisco Systems, Inc. 410 Cessna Business Park, Varthur Hobli 411 Sarjapur Marathalli Outer Ring Road 412 Bangalore 413 India 415 Email: praspati@cisco.com 417 Mike Geller 418 Cisco Systems, Inc. 419 3250 420 Florida 33309 421 USA 423 Email: mgeller@cisco.com 425 Dan Wing 426 Cisco Systems, Inc. 427 170 West Tasman Drive 428 San Jose, California 95134 429 USA 431 Email: dwing@cisco.com 432 Sandeep Rao 433 Cisco Systems, Inc. 434 Cessna Business Park, Varthur Hobli 435 Sarjapur Marathalli Outer Ring Road 436 Bangalore, Karnataka 560103 437 India 439 Email: rsandeep@cisco.com 441 Mohamed Boucadair 442 France Telecom 443 Rennes 35000 444 France 446 Email: mohamed.boucadair@orange.com