idnits 2.17.1 draft-ietf-dots-requirements-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 date (October 19, 2015) is 3106 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-dots-use-cases' is mentioned on line 213, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1519 (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 2373 (Obsoleted by RFC 3513) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS A. Mortensen 3 Internet-Draft Arbor Networks, Inc. 4 Intended status: Informational R. Moskowitz 5 Expires: April 21, 2016 HTT Consulting 6 T. Reddy 7 Cisco Systems, Inc. 8 October 19, 2015 10 DDoS Open Threat Signaling Requirements 11 draft-ietf-dots-requirements-00 13 Abstract 15 This document defines the requirements for the DDoS Open Threat 16 Signaling (DOTS) protocols coordinating attack response against 17 Distributed Denial of Service (DDoS) attacks. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 21, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. General Requirements . . . . . . . . . . . . . . . . . . 6 58 2.2. Operational requirements . . . . . . . . . . . . . . . . 7 59 2.3. Data channel requirements . . . . . . . . . . . . . . . . 9 60 2.4. Data model requirements . . . . . . . . . . . . . . . . . 10 61 3. Congestion Control Considerations . . . . . . . . . . . . . . 10 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 63 5. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 5.1. 00 revision . . . . . . . . . . . . . . . . . . . . . . . 11 65 5.2. Initial revision . . . . . . . . . . . . . . . . . . . . 11 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 68 6.2. Informative References . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 71 1. Introduction 73 1.1. Overview 75 Distributed Denial of Service (DDoS) attacks continue to plague 76 networks around the globe, from Tier-1 service providers on down to 77 enterprises and small businesses. Attack scale and frequency 78 similarly have continued to increase, thanks to software 79 vulnerabilities leading to reflection and amplification attacks. 80 Once staggering attack traffic volume is now the norm, and the impact 81 of larger-scale attacks attract the attention of international press 82 agencies. 84 The higher profile and greater impact of contemporary DDoS attacks 85 has led to increased focus on coordinated attack response. Many 86 institutions and enterprises lack the resources or expertise to 87 operate on-premise attack prevention solutions themselves, or simply 88 find themselves constrained by local bandwidth limitations. To 89 address such gaps, security service providers have begun to offer on- 90 demand traffic scrubbing services. Each service offers its own 91 interface for subscribers to request attack mitigation, tying 92 subscribers to proprietary implementations while also limiting the 93 subset of network elements capable of participating in the attack 94 response. As a result of incompatibility across services, attack 95 response may be fragmentary or otherwise incomplete, leaving key 96 players in the attack path unable to assist in the defense. 98 There are many ways to respond to an ongoing DDoS attack, some of 99 them better than others, but the lack of a common method to 100 coordinate a real-time response across layers and network domains 101 inhibits the speed and effectiveness of DDoS attack mitigation. 103 DOTS was formed to address this lack. The DOTS protocols are 104 therefore not concerned with the form of response, but rather with 105 communicating the need for a response, supplementing the call for 106 help with pertinent details about the detected attack. To achieve 107 this aim, the protocol must permit the DOTS client to request or 108 withdraw a request for coordinated mitigation; to set the scope of 109 mitigation, restricted to the client's network space; and to supply 110 summarized attack information and additional hints the DOTS server 111 elements can use to increase the accuracy and speed of the attack 112 response. 114 The protocol must also continue to operate even in extreme network 115 conditions. It must be resilient enough to ensure a high probability 116 of signal delivery in spite of high packet loss rates. As such, 117 elements should be in regular, bidirectional contact to measure peer 118 health, provide mitigation-related feedback, and allow for active 119 mitigation adjustments. 121 Lastly, the protocol must take care to ensure the confidentiality, 122 integrity and authenticity of messages passed between peers to 123 prevent the protocol from being repurposed to contribute to the very 124 attacks it's meant to deflect. 126 Drawing on the DOTS use cases [I-D.ietf-dots-use-cases] for 127 reference, this document details the requirements for protocols 128 achieving the DOTS goal of standards-based open threat signaling. 130 1.2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 The following terms are used to define relationships between 137 elements, the data they exchange, and methods of communication among 138 them: 140 attack telemetry: collected network traffic characteristics defining 141 the nature of a DDoS attack. 143 mitigation: A defensive response against a detected DDoS attack, 144 performed by an entity in the network path between attack sources 145 and the attack target, either through inline deployment or some 146 form of traffic diversion. The form mitigation takes is out of 147 scope for this document. 149 mitigator: A network element capable of performing mitigation of a 150 detected DDoS attack. 152 DOTS client: A DOTS-aware network element requesting attack response 153 coordination with another DOTS-aware element, with the expectation 154 that the remote element is capable of helping fend off the attack 155 against the client. 157 DOTS server: A DOTS-aware network element handling and responding to 158 messages from a DOTS client. The DOTS server MAY enable 159 mitigation on behalf of the DOTS client, if requested, by 160 communicating the DOTS client's request to the mitigator and 161 relaying any mitigator feedback to the client. A DOTS server may 162 also be a mitigator. 164 DOTS relay: A DOTS-aware network element positioned between a DOTS 165 server and a DOTS client. A DOTS relay receives messages from a 166 DOTS client and relays them to a DOTS server, and similarly passes 167 messages from the DOTS server to the DOTS client. 169 DOTS agents: A collective term for DOTS clients, servers and relays. 171 signal channel: A bidirectional, mutually authenticated 172 communication layer between DOTS agents characterized by 173 resilience even in conditions leading to severe packet loss, such 174 as a volumetric DDoS attack causing network congestion. 176 DOTS signal: A concise authenticated status/control message 177 transmitted between DOTS agents, used to indicate client's need 178 for mitigation, as well as to convey the status of any requested 179 mitigation. 181 heartbeat: A keep-alive message transmitted between DOTS agents over 182 the signal channel, used to measure peer health. Heartbeat 183 functionality is not required to be distinct from signal. 185 client signal: A message sent from a DOTS client to a DOTS server 186 over the signal channel, possibly traversing a DOTS relay, 187 indicating the DOTS client's need for mitigation, as well as the 188 scope of any requested mitigation, optionally including detected 189 attack telemetry to supplement server-initiated mitigation. 191 server signal: A message sent from a DOTS server to a DOTS client 192 over the signal channel. Note that a server signal is not a 193 response to client signal, but a DOTS server-initiated status 194 message sent to the DOTS client, containing information about the 195 status of any requested mitigation and its efficacy. 197 data channel: A secure communication layer between client and server 198 used for infrequent bulk exchange of data not easily or 199 appropriately communicated through the signal channel under attack 200 conditions. 202 blacklist: a list of source addresses or prefixes from which traffic 203 should be blocked. 205 whitelist: a list of source addresses or prefixes from which traffic 206 should always be allowed, regardless of contradictory data gleaned 207 in a detected attack. 209 2. Requirements 211 This section describes the required features and characteristics of 212 the DOTS protocols. The requirements are informed by the use cases 213 described in [I-D.ietf-dots-use-cases]. 215 DOTS must at a minimum make it possible for a DOTS client to request 216 a DOTS server's aid in mounting a coordinated defense against a 217 detected attack, by signaling inter- or intra-domain using the DOTS 218 protocol. DOTS clients should similarly be able to withdraw aid 219 requests arbitrarily. Regular feedback between DOTS client and 220 server supplement the defensive alliance by maintaining a common 221 understanding of DOTS peer health and activity. Bidirectional 222 communication between DOTS client and server is therefore critical. 224 Yet the DOTS protocol must also work with a set of competing 225 operational goals. On the one hand, the protocol must be resilient 226 under extremely hostile network conditions, providing continued 227 contact between DOTS agents even as attack traffic saturates the 228 link. Such resiliency may be developed several ways, but 229 characteristics such as small message size, asynchronous, redundant 230 message delivery and minimal connection overhead (when possible given 231 local network policy) with a given network will tend to contribute to 232 the robustness demanded by a viable DOTS protocol. 234 On the other hand, DOTS must have adequate message confidentiality, 235 integrity and authenticity to keep the protocol from becoming another 236 vector for the very attacks it's meant to help fight off. The DOTS 237 client must be authenticated to the DOTS server, and vice versa, for 238 DOTS to operate safely, meaning the DOTS agents must have a way to 239 negotiate and agree upon the terms of protocol security. Attacks 240 against the transport protocol should not offer a means of attack 241 against the message confidentiality, integrity and authenticity. 243 The DOTS server and client must also have some common method of 244 defining the scope of any mitigation performed by the mitigator, as 245 well as making adjustments to other commonly configurable features, 246 such as listen ports, exchanging black- and white-lists, and so on. 248 Finally, DOTS should provide sufficient extensibility to meet local, 249 vendor or future needs in coordinated attack defense, although this 250 consideration is necessarily superseded by the other operational 251 requirements. 253 2.1. General Requirements 255 G-001 Interoperability: DOTS's objective is to develop a standard 256 mechanism for signaling detected ongoing DDoS attacks. That 257 objective is unattainable without well-defined specifications for 258 any protocols or data models emerging from DOTS. All protocols, 259 data models and interfaces MUST be detailed enough to ensure 260 interoperable implementations. 262 G-002 Extensibility: Any protocols or data models developed as part 263 of DOTS MUST be designed to support future extensions. Provided 264 they do not undermine the interoperability and backward 265 compatibility requirements, extensions are a critical part of 266 keeping DOTS adaptable to changing operational and proprietary 267 needs to keep pace with evolving DDoS attack methods. 269 G-003 Resilience: The signaling protocol MUST be designed to 270 maximize the probability of signal delivery even under the 271 severely constrained network conditions imposed by the attack 272 traffic. The protocol SHOULD be resilient, that is, continue 273 operating despite message loss and out-of-order or redundant 274 signal delivery. 276 G-004 Bidirectionality: To support peer health detection, to 277 maintain an open signal channel, and to increase the probability 278 of signal delivery during attack, the signal channel MUST be 279 bidirectional, with client and server transmitting signals to each 280 other at regular intervals, regardless of any client request for 281 mitigation. 283 G-005 Sub-MTU Message Size: To avoid message fragmentation and the 284 consequently decreased probability of message delivery, signaling 285 protocol message size MUST be kept under signaling path Maximum 286 Transmission Unit (MTU), including the byte overhead of any 287 encapsulation, transport headers, and transport- or message-level 288 security. 290 G-006 Message Integrity: DOTS protocols MUST take steps to protect 291 the confidentiality, integrity and authenticity of messages sent 292 between client and server. While specific transport- and message- 293 level security options are not specified, the protocols MUST 294 follow current industry best practices for encryption and message 295 authentication. 297 In order for DOTS protocols to remain secure despite advancements 298 in cryptanalysis, DOTS agents MUST be able to negotiate the terms 299 and mechanisms of protocol security, subject to the 300 interoperability and signal message size requirements above. 302 G-007 Message Replay Protection: In order to prevent a passive 303 attacker from capturing and replaying old messages, DOTS protocols 304 MUST provide a method for replay detection, such as including a 305 timestamp or sequence number in every heartbeat and signal sent 306 between DOTS agents. 308 G-008 Bulk Data Exchange: Infrequent bulk data exchange between DOTS 309 client and server can also significantly augment attack response 310 coordination, permitting such tasks as population of black- or 311 white-listed source addresses; address group aliasing; exchange of 312 incident reports; and other hinting or configuration supplementing 313 attack response. 315 As the resilience requirements for DOTS mandate small signal 316 message size, a separate, secure data channel utilizing an 317 established reliable protocol SHOULD be used for bulk data 318 exchange. The mechanism for bulk data exchange is not yet 319 specified, but the nature of the data involved suggests use of a 320 reliable, adaptable protocol with established and configurable 321 conventions for authentication and authorization. 323 2.2. Operational requirements 325 OP-001 Use of Common Transports: DOTS MUST operate over common 326 standardized transport protocols. While the protocol resilience 327 requirement strongly RECOMMENDS the use of connectionless 328 protocols, in particular the User Datagram Protocol (UDP) 329 [RFC0768], use of a standardized, connection-oriented protocol 330 like the Transmission Control Protocol (TCP) [RFC0793] MAY be 331 necessary due to network policy or middleware limitations. 333 OP-002 Peer Mutual Authentication: The client and server MUST 334 authenticate each other before a DOTS session is considered 335 active. The method of authentication is not specified, but should 336 follow current industry best practices with respect to any 337 cryptographic mechanisms to authenticate the remote peer. 339 OP-003 Session Health Monitoring: The client and server MUST 340 regularly send heartbeats to each other after mutual 341 authentication in order to keep the DOTS session open. A session 342 MUST be considered active until a client or server explicitly ends 343 the session, or either DOTS agent fails to receive heartbeats from 344 the other after a mutually negotiated timeout period has elapsed. 346 OP-004 Mitigation Capability Opacity: DOTS is a threat signaling 347 protocol. The server and mitigator MUST NOT make any assumption 348 about the attack detection, classification, or mitigation 349 capabilities of the client. While the server and mitigator MAY 350 take hints from any attack telemetry included in client signals, 351 the server and mitigator cannot depend on the client for 352 authoritative attack classification. Similarly, the mitigator 353 cannot assume the client can or will mitigate attack traffic on 354 its own. 356 The client likewise MUST NOT make any assumptions about the 357 capabilities of the server or mitigator with respect to detection, 358 classification, and mitigation of DDoS attacks. The form of any 359 attack response undertaken by the mitigator is not in scope. 361 OP-005 Mitigation Status: DOTS clients MUST be able to request or 362 withdraw a request for mitigation from the DOTS server. The DOTS 363 server MUST acknowledge a DOTS client's request to withdraw from 364 coordinated attack response in subsequent signals, and MUST cease 365 mitigation activity as quickly as possible. However, a DOTS 366 client rapidly toggling active mitigation may result in 367 undesirable side-effects for the network path, such as route or 368 DNS flapping. A DOTS server therefore MAY continue mitigating for 369 a mutually negotiated period after receiving the DOTS client's 370 request to stop. 372 A server MAY refuse to engage in coordinated attack response with 373 a client. To make the status of a client's request clear, the 374 server MUST indicate in server signals whether client-initiated 375 mitigation is active. When a client-initiated mitigation is 376 active, and threat handling details such as mitigation scope and 377 statistics are available to the server, the server SHOULD include 378 those details in server signals sent to the client. DOTS clients 379 SHOULD take mitigation statistics into account when deciding 380 whether to request the DOTS server cease mitigation. 382 OP-006 Mitigation Scope: DOTS clients MUST indicate the desired 383 address space coverage of any mitigation, for example by using 384 Classless Internet Domain Routing (CIDR) [RFC1518],[RFC1519] 385 prefixes, [RFC2373] for IPv6 prefixes, the length/prefix 386 convention established in the Border Gateway Protocol (BGP) 387 [RFC4271], or by a prefix group alias agreed upon with the server 388 through the data channel. If there is additional information 389 available narrowing the scope of any requested attack response, 390 such as targeted port range, protocol, or service, clients SHOULD 391 include that information in client signals. 393 As an active attack evolves, clients MUST be able to adjust as 394 necessary the scope of requested mitigation by refining the 395 address space requiring intervention. 397 2.3. Data channel requirements 399 The data channel is intended to be used for bulk data exchanges 400 between DOTS agents. Unlike the signal channel, which must operate 401 nominally even when confronted with despite signal degradation due to 402 packet loss, the data channel is not expected to be constructed to 403 deal with attack conditions. As the primary function of the data 404 channel is data exchange, a reliable transport is required in order 405 for DOTS agents to detect data delivery success or failure. 407 The data channel should be adaptable and extensible. We anticipate 408 the data channel will be used for such purposes as configuration or 409 resource discovery. For example, a DOTS client may submit to the 410 DOTS server a collection of prefixes it wants to refer to by alias 411 when requesting mitigation, to which the server would respond with a 412 success status and the new prefix group alias, or an error status and 413 message in the event the DOTS client's data channel request failed. 414 The transactional nature of such data exchanges suggests a separate 415 set of requirements for the data channel, while the potentially 416 sensitive content sent between DOTS agents requires extra precautions 417 to ensure data privacy and authenticity. 419 DATA-001 Reliable transport: Transmissions over the data channel may 420 be transactional, requiring reliable, in-order packet delivery. 422 DATA-002 Data privacy and integrity: Transmissions over the data 423 channel may contain sensitive information or instructions from the 424 remote DOTS agent. Theft or modification of data channel 425 transmissions could lead to information leaks or malicious 426 transactions on behalf of the sending agent. (See Security 427 Considerations below.) Consequently data sent over the data 428 channel MUST be encrypted and authenticated using current industry 429 best practices. 431 DATA-003 Mutual authentication: DOTS agents MUST mutually 432 authenticate each other before data may be exchanged over the data 433 channel. DOTS agents MAY take additional steps to authorize data 434 exchange, as in the prefix group example above, before accepting 435 data over the data channel. The form of authentication and 436 authorization is unspecified. 438 DATA-004 Black- and whitelist management: DOTS servers SHOULD 439 provide methods for DOTS clients to manage black- and white-lists 440 of source addresses of traffic destined for addresses belonging to 441 a client. 443 For example, a DOTS client should be able to create a black- or 444 whitelist entry; retrieve a list of current entries from either 445 list; update the content of either list; and delete entries as 446 necessary. 448 How the DOTS server determines client ownership of address space 449 is not in scope. 451 2.4. Data model requirements 453 TODO 455 3. Congestion Control Considerations 457 The DOTS signal channel will not contribute measurably to link 458 congestion, as the protocol's transmission rate will be negligible 459 regardless of network conditions. Bulk data transfers are performed 460 over the data channel, which should use a reliable transport with 461 built-in congestion control mechanisms, such as TCP. 463 4. Security Considerations 465 DOTS is at risk from three primary attacks: DOTS agent impersonation, 466 traffic injection, and signaling blocking. The DOTS protocol MUST be 467 designed for minimal data transfer to address the blocking risk. 468 Impersonation and traffic injection mitigation can be managed through 469 current secure communications best practices. DOTS is not subject to 470 anything new in this area. One consideration could be to minimize 471 the security technologies in use at any one time. The more needed, 472 the greater the risk of failures coming from assumptions on one 473 technology providing protection that it does not in the presence of 474 another technology. 476 5. Change Log 478 5.1. 00 revision 480 2015-10-15 482 5.2. Initial revision 484 2015-09-24 Andrew Mortensen 486 6. References 488 6.1. Normative References 490 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 491 10.17487/RFC0768, August 1980, 492 . 494 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 495 793, DOI 10.17487/RFC0793, September 1981, 496 . 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 500 RFC2119, March 1997, 501 . 503 6.2. Informative References 505 [RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address 506 Allocation with CIDR", RFC 1518, DOI 10.17487/RFC1518, 507 September 1993, . 509 [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless 510 Inter-Domain Routing (CIDR): an Address Assignment and 511 Aggregation Strategy", RFC 1519, DOI 10.17487/RFC1519, 512 September 1993, . 514 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 515 Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998, 516 . 518 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 519 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 520 10.17487/RFC4271, January 2006, 521 . 523 Authors' Addresses 525 Andrew Mortensen 526 Arbor Networks, Inc. 527 2727 S. State St 528 Ann Arbor, MI 48104 529 United States 531 Email: amortensen@arbor.net 533 Robert Moskowitz 534 HTT Consulting 535 Oak Park, MI 42837 536 United States 538 Email: rgm@htt-consult.com 540 Tirumaleswar Reddy 541 Cisco Systems, Inc. 542 Cessna Business Park, Varthur Hobli 543 Sarjapur Marathalli Outer Ring Road 544 Bangalore, Karnataka 560103 545 India 547 Email: tireddy@cisco.com