idnits 2.17.1 draft-ietf-dots-requirements-02.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 (July 08, 2016) is 2842 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-00 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-01 -- Obsolete informational reference (is this intentional?): RFC 1519 (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 2373 (Obsoleted by RFC 3513) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 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: January 9, 2017 HTT Consulting 6 T. Reddy 7 Cisco Systems, Inc. 8 July 08, 2016 10 Distributed Denial of Service (DDoS) Open Threat Signaling Requirements 11 draft-ietf-dots-requirements-02 13 Abstract 15 This document defines the requirements for the Distributed Denial of 16 Service (DDoS) Open Threat Signaling (DOTS) protocols coordinating 17 attack response against 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 January 9, 2017. 36 Copyright Notice 38 Copyright (c) 2016 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. Context and Motivation . . . . . . . . . . . . . . . . . 2 55 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. General Requirements . . . . . . . . . . . . . . . . . . 7 58 2.2. Operational Requirements . . . . . . . . . . . . . . . . 8 59 2.3. Data Channel Requirements . . . . . . . . . . . . . . . . 10 60 2.4. Security requirements . . . . . . . . . . . . . . . . . . 11 61 2.5. Data Model Requirements . . . . . . . . . . . . . . . . . 12 62 3. Congestion Control Considerations . . . . . . . . . . . . . . 13 63 3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 13 64 3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 13 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 66 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 68 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 7.1. 02 revision . . . . . . . . . . . . . . . . . . . . . . . 14 70 7.2. 01 revision . . . . . . . . . . . . . . . . . . . . . . . 14 71 7.3. 00 revision . . . . . . . . . . . . . . . . . . . . . . . 15 72 7.4. Initial revision . . . . . . . . . . . . . . . . . . . . 15 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 75 8.2. Informative References . . . . . . . . . . . . . . . . . 16 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 78 1. Introduction 80 1.1. Context and Motivation 82 Distributed Denial of Service (DDoS) attacks continue to plague 83 networks around the globe, from Tier-1 service providers on down to 84 enterprises and small businesses. Attack scale and frequency 85 similarly have continued to increase, in part as a result of software 86 vulnerabilities leading to reflection and amplification attacks. 87 Once staggering attack traffic volume is now the norm, and the impact 88 of larger-scale attacks attract the attention of international press 89 agencies. 91 The greater impact of contemporary DDoS attacks has led to increased 92 focus on coordinated attack response. Many institutions and 93 enterprises lack the resources or expertise to operate on-premise 94 attack mitigation solutions themselves, or simply find themselves 95 constrained by local bandwidth limitations. To address such gaps, 96 security service providers have begun to offer on-demand traffic 97 scrubbing services, which aim to separate the DDoS traffic from 98 legitimate traffic and forward only the latter. Today each such 99 service offers its own interface for subscribers to request attack 100 mitigation, tying subscribers to proprietary implementations while 101 also limiting the subset of network elements capable of participating 102 in the attack response. As a result of incompatibility across 103 services, attack responses may be fragmentary or otherwise 104 incomplete, leaving key players in the attack path unable to assist 105 in the defense. 107 The lack of a common method to coordinate a real-time response among 108 involved actors and network domains inhibits the speed and 109 effectiveness of DDoS attack mitigation. This document describes the 110 required characteristics of a DOTS protocol enabling requests for 111 DDoS attack mitigation, reducing attack impact and leading to more 112 efficient defensive strategies. 114 DOTS communicates the need for defensive action in anticipation of or 115 in response to an attack, but does not dictate the form any defensive 116 action takes. DOTS supplements calls for help with pertinent details 117 about the detected attack, allowing entities participating in DOTS to 118 form ad hoc, adaptive alliances against DDoS attacks as described in 119 the DOTS use cases [I-D.ietf-dots-use-cases]. The requirements in 120 this document are derived from those use cases and 121 [I-D.ietf-dots-architecture]. 123 1.2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 This document adopts the following terms: 131 DDoS: A distributed denial-of-service attack, in which traffic 132 originating from multiple sources are directed at a target on a 133 network. DDoS attacks are intended to cause a negative impact on 134 the availability of servers, services, applications, and/or other 135 functionality of an attack target. Denial-of-service 136 considerations are discussed in detail in [RFC4732]. 138 DDoS attack target: A network connected entity with a finite set of 139 resources, such as network bandwidth, memory or CPU, that is the 140 focus of a DDoS attack. Potential targets include servers, 141 services and applications. 143 DDoS attack telemetry: Collected behavioral characteristics defining 144 the nature of a DDoS attack. This document makes no assumptions 145 regarding telemetry collection methodology. 147 Countermeasure: An action or set of actions taken to recognize and 148 filter out DDoS attack traffic while passing legitimate traffic to 149 the attack target. 151 Mitigation: A set of countermeasures enforced against traffic 152 destined for the target or targets of a detected or reported DDoS 153 attack, where countermeasure enforcement is managed by an entity 154 in the network path between attack sources and the attack target. 155 Mitigation methodology is out of scope for this document. 157 Mitigator: An entity, typically a network element, capable of 158 performing mitigation of a detected or reported DDoS attack. For 159 the purposes of this document, this entity is a black box capable 160 of mitigation, making no assumptions about availability or design 161 of countermeasures, nor about the programmable interface between 162 this entity and other network elements. The mitigator and DOTS 163 server are assumed to belong to the same administrative entity. 165 DOTS client: A DOTS-aware software module responsible for requesting 166 attack response coordination with other DOTS-aware elements. 168 DOTS server: A DOTS-aware software module handling and responding to 169 messages from DOTS clients. The DOTS server SHOULD enable 170 mitigation on behalf of the DOTS client, if requested, by 171 communicating the DOTS client's request to the mitigator and 172 returning selected mitigator feedback to the requesting DOTS 173 client. A DOTS server MAY also be a mitigator. 175 DOTS agent: Any DOTS-aware software module capable of participating 176 in a DOTS siganling session. 178 DOTS gateway: A logical DOTS agent resulting from the logical 179 concatenation of a DOTS server and a DOTS client, analogous to a 180 SIP Back-to-Back User Agent (B2BUA) [RFC3261]. DOTS gateways are 181 discussed in detail in [I-D.ietf-dots-architecture]. 183 Signal channel: A bidirectional, mutually authenticated 184 communication channel between DOTS agents characterized by 185 resilience even in conditions leading to severe packet loss, such 186 as a volumetric DDoS attack causing network congestion. 188 DOTS signal: A concise authenticated status/control message 189 transmitted between DOTS agents, used to indicate client's need 190 for mitigation, as well as to convey the status of any requested 191 mitigation. 193 Heartbeat: A message transmitted between DOTS agents over the signal 194 channel, used as a keep-alive and to measure peer health. 196 Client signal: A message sent from a DOTS client to a DOTS server 197 over the signal channel, indicating the DOTS client's need for 198 mitigation, as well as the scope of any requested mitigation, 199 optionally including additional attack details to supplement 200 server-initiated mitigation. 202 Server signal: A message sent from a DOTS server to a DOTS client 203 over the signal channel. Note that a server signal is not a 204 response to client signal, but a DOTS server-initiated status 205 message sent to DOTS clients with which the server has established 206 signaling sessions. 208 Data channel: A secure communication layer between DOTS clients and 209 DOTS servers used for infrequent bulk exchange of data not easily 210 or appropriately communicated through the signal channel under 211 attack conditions. 213 Filter: A policy matching a network traffic flow or set of flows and 214 rate-limiting or discarding matching traffic. 216 Blacklist: A filter list of addresses, prefixes and/or other 217 identifiers indicating sources from which traffic should be 218 blocked, regardless of traffic content. 220 Whitelist: A list of addresses, prefixes and/or other identifiers 221 from indicating sources from which traffic should always be 222 allowed, regardless of contradictory data gleaned in a detected 223 attack. 225 Multi-homed DOTS client: A DOTS client exchanging messages with 226 multiple DOTS servers, each in a separate administrative domain. 228 2. Requirements 230 This section describes the required features and characteristics of 231 the DOTS protocol. 233 DOTS is an advisory protocol. An active DDoS attack against the 234 entity controlling the DOTS client need not be present before 235 establishing DOTS communication between DOTS agents. Indeed, 236 establishing a relationship with peer DOTS agents during normal 237 network conditions provides the foundation for more rapid attack 238 response against future attacks, as all interactions setting up DOTS, 239 including any business or service level agreements, are already 240 complete. 242 DOTS must at a minimum make it possible for a DOTS client to request 243 a DOTS server's aid in mounting a coordinated defense against a 244 suspected attack, signaling within or between domains as requested by 245 local operators. DOTS clients should similarly be able to withdraw 246 aid requests. DOTS requires no justification from DOTS clients for 247 requests for help, nor do DOTS clients need to justify withdrawing 248 help requests: the decision is local to the DOTS clients' domain. 249 Regular feedback between DOTS clients and DOTS server supplement the 250 defensive alliance by maintaining a common understanding of DOTS peer 251 health and activity. Bidirectional communication between DOTS 252 clients and DOTS servers is therefore critical. 254 Yet DOTS must also work with a set of competing operational goals. 255 On the one hand, the protocol must be resilient under extremely 256 hostile network conditions, providing continued contact between DOTS 257 agents even as attack traffic saturates the link. Such resiliency 258 may be developed several ways, but characteristics such as small 259 message size, asynchronous, redundant message delivery and minimal 260 connection overhead (when possible given local network policy) will 261 tend to contribute to the robustness demanded by a viable DOTS 262 protocol. Operators of peer DOTS-enabled domains may enable quality- 263 or class-of-service traffic tagging to increase the probability of 264 successful DOTS signal delivery, but DOTS requires no such policies 265 be in place. The DOTS solution indeed must be viable especially in 266 their absence. 268 On the other hand, DOTS must include protections ensuring message 269 confidentiality, integrity and authenticity to keep the protocol from 270 becoming another vector for the very attacks it's meant to help fight 271 off. DOTS clients must be able to authenticate DOTS servers, and 272 vice versa, for DOTS to operate safely, meaning the DOTS agents must 273 have a way to negotiate and agree upon the terms of protocol 274 security. Attacks against the transport protocol should not offer a 275 means of attack against the message confidentiality, integrity and 276 authenticity. 278 The DOTS server and client must also have some common method of 279 defining the scope of any mitigation performed by the mitigator, as 280 well as making adjustments to other commonly configurable features, 281 such as listen ports, exchanging black- and white-lists, and so on. 283 Finally, DOTS should provide sufficient extensibility to meet local, 284 vendor or future needs in coordinated attack defense, although this 285 consideration is necessarily superseded by the other operational 286 requirements. 288 2.1. General Requirements 290 GEN-001 Extensibility: Protocols and data models developed as part 291 of DOTS MUST be extensible in order to keep DOTS adaptable to 292 operational and proprietary DDoS defenses. Future extensions MUST 293 be backward compatible. 295 GEN-002 Resilience and Robustness: The signaling protocol MUST be 296 designed to maximize the probability of signal delivery even under 297 the severely constrained network conditions imposed by particular 298 attack traffic. The protocol MUST be resilient, that is, continue 299 operating despite message loss and out-of-order or redundant 300 message delivery. 302 GEN-003 Bidirectionality: To support peer health detection, to 303 maintain an open signal channel, and to increase the probability 304 of signal delivery during attack, the signal channel MUST be 305 bidirectional, with client and server transmitting signals to each 306 other at regular intervals, regardless of any client request for 307 mitigation. Unidirectional messages MUST be supported within the 308 bidirectional signal channel to allow for unsolicited message 309 delivery, enabling asynchronous notifications between agents. 311 GEN-004 Sub-MTU Message Size: To avoid message fragmentation and the 312 consequently decreased probability of message delivery, signaling 313 protocol message size MUST be kept under signaling path Maximum 314 Transmission Unit (MTU), including the byte overhead of any 315 encapsulation, transport headers, and transport- or message-level 316 security. 318 GEN-005 Bulk Data Exchange: Infrequent bulk data exchange between 319 DOTS agents can also significantly augment attack response 320 coordination, permitting such tasks as population of black- or 321 white-listed source addresses; address or prefix group aliasing; 322 exchange of incident reports; and other hinting or configuration 323 supplementing attack response. 325 As the resilience requirements for the DOTS signal channel mandate 326 small signal message size, a separate, secure data channel 327 utilizing an established reliable transport protocol MUST be used 328 for bulk data exchange. 330 2.2. Operational Requirements 332 OP-001 Use of Common Transport Protocols: DOTS MUST operate over 333 common widely deployed and standardized transport protocols. 334 While the User Datagram Protocol (UDP) [RFC0768] SHOULD be used 335 for the signal channel, the Transmission Control Protocol (TCP) 336 [RFC0793] MAY be used if necessary due to network policy or 337 middlebox capabilities or configurations. The data channel MUST 338 use TCP; see Section 2.3 below. 340 OP-002 Session Health Monitoring: Peer DOTS agents MUST regularly 341 send heartbeats to each other after mutual authentication in order 342 to keep the DOTS session open. A session MUST be considered 343 active until a DOTS agent explicitly ends the session, or either 344 DOTS agent fails to receive heartbeats from the other after a 345 mutually agreed upon timeout period has elapsed. 347 OP-003 Session Redirection: In order to increase DOTS operational 348 flexibility and scalability, DOTS servers SHOULD be able to 349 redirect DOTS clients to another DOTS server at any time. Due to 350 the decreased probability of DOTS server signal delivery due to 351 link congestion, it is RECOMMENDED DOTS servers avoid redirecting 352 while mitigation is enabled during an active attack against a 353 target in the DOTS client's domain. Either the DOTS servers have 354 to fate-share the security state, the client MUST have separate 355 security state with each potential redirectable server, or be able 356 to negotiate new state as part of redirection. 358 OP-004 Mitigation Status: DOTS MUST provide a means to report the 359 status of an action requested by a DOTS client. In particular, 360 DOTS clients MUST be able to request or withdraw a request for 361 mitigation from the DOTS server. The DOTS server MUST acknowledge 362 a DOTS client's request to withdraw from coordinated attack 363 response in subsequent signals, and MUST cease mitigation activity 364 as quickly as possible. However, a DOTS client rapidly toggling 365 active mitigation may result in undesirable side-effects for the 366 network path, such as route or DNS [RFC1034] flapping. A DOTS 367 server therefore MAY continue mitigating for a mutually negotiated 368 period after receiving the DOTS client's request to stop. 370 A server MAY refuse to engage in coordinated attack response with 371 a client. To make the status of a client's request clear, the 372 server MUST indicate in server signals whether client-initiated 373 mitigation is active. When a client-initiated mitigation is 374 active, and threat handling details such as mitigation scope and 375 statistics are available to the server, the server SHOULD include 376 those details in server signals sent to the client. DOTS clients 377 SHOULD take mitigation statistics into account when deciding 378 whether to request the DOTS server cease mitigation. 380 OP-005 Mitigation Lifetime: A DOTS client SHOULD indicate the 381 desired lifetime of any mitigation requested from the DOTS server. 382 As DDoS attack duration is unpredictable, the DOTS client SHOULD 383 be able to extend mitigation lifetime with periodic renewed 384 requests for help. When the mitigation lifetime comes to an end, 385 the DOTS server SHOULD delay session termination for a protocol- 386 defined grace period to allow for delivery of delayed mitigation 387 renewals over the signal channel. After the grace period elapses, 388 the DOTS server MAY terminate the session at any time. 390 If a DOTS client does not include a mitigation lifetime in 391 requests for help sent to the DOTS server, the DOTS server will 392 use a reasonable default as defined by the protocol. As above, 393 the DOTS client MAY extend a current mitigation request's lifetime 394 trivially with renewed requests for help. 396 A DOTS client MAY also request an indefinite mitigation lifetime, 397 enabling architectures in which the mitigator is always in the 398 traffic path to the resources for which the DOTS client is 399 requesting protection. DOTS servers MAY refuse such requests for 400 any reason. The reasons themselves are not in scope. 402 OP-006 Mitigation Scope: DOTS clients MUST indicate the desired 403 scope of any mitigation, for example by using Classless Internet 404 Domain Routing (CIDR) [RFC1518],[RFC1519] prefixes, [RFC2373] for 405 IPv6 [RFC2460] prefixes, the length/prefix convention established 406 in the Border Gateway Protocol (BGP) [RFC4271], SIP URIs 407 [RFC3261], E.164 numbers, DNS names, or by a resource group alias 408 agreed upon with the server through the data channel. 410 If there is additional information available narrowing the scope 411 of any requested attack response, such as targeted port range, 412 protocol, or service, DOTS clients SHOULD include that information 413 in client signals. DOTS clients MAY also include additional 414 attack details. Such supplemental information is OPTIONAL, and 415 DOTS servers MAY ignore it when enabling countermeasures on the 416 mitigator. 418 As an active attack evolves, clients MUST be able to adjust as 419 necessary the scope of requested mitigation by refining the scope 420 of resources requiring mitigation. 422 OP-007 Mitigation Efficacy: When a mitigation request by a DOTS 423 client is active, DOTS clients SHOULD transmit a metric of 424 perceived mitigation efficacy to the DOTS server, per "Automatic 425 or Operator-Assisted CPE or PE Mitigators Request Upstream DDoS 426 Mitigation Services" in [I-D.ietf-dots-use-cases]. DOTS servers 427 MAY use the efficacy metric to adjust countermeasures activated on 428 a mitigator on behalf of a DOTS client. 430 OP-008 Conflict Detection and Notification: Multiple DOTS clients 431 controlled by a single administrative entity may send conflicting 432 mitigation requests for pool of protected resources , as a result 433 of misconfiguration, operator error, or compromised DOTS clients. 434 DOTS servers attempting to honor conflicting requests may flap 435 network route or DNS information, degrading the networks 436 attempting to participate in attack response with the DOTS 437 clients. DOTS servers SHALL detect such conflicting requests, and 438 SHALL notify the DOTS clients in conflict. The notification 439 SHOULD indicate the nature and scope of the conflict, for example, 440 the overlapping prefix range in a conflicting mitigation request. 442 OP-009: Network Address Translator Traversal: The DOTS protocol MUST 443 operate over networks in which Network Address Translation (NAT) 444 is deployed. As UDP is the recommended transport for DOTS, all 445 considerations in "Middlebox Traversal Guidelines" in [RFC5405] 446 apply to DOTS. Regardless of transport, DOTS protocols MUST 447 follow established best common practices (BCPs) for NAT traversal. 449 2.3. Data Channel Requirements 451 The data channel is intended to be used for bulk data exchanges 452 between DOTS agents. Unlike the signal channel, which must operate 453 nominally even when confronted with despite signal degradation due to 454 packet loss, the data channel is not expected to be constructed to 455 deal with attack conditions. As the primary function of the data 456 channel is data exchange, a reliable transport is required in order 457 for DOTS agents to detect data delivery success or failure. 459 The data channel must be extensible. We anticipate the data channel 460 will be used for such purposes as configuration or resource 461 discovery. For example, a DOTS client may submit to the DOTS server 462 a collection of prefixes it wants to refer to by alias when 463 requesting mitigation, to which the server would respond with a 464 success status and the new prefix group alias, or an error status and 465 message in the event the DOTS client's data channel request failed. 466 The transactional nature of such data exchanges suggests a separate 467 set of requirements for the data channel, while the potentially 468 sensitive content sent between DOTS agents requires extra precautions 469 to ensure data privacy and authenticity. 471 DATA-001 Reliable transport: Messages sent over the data channel 472 MUST be delivered reliably, in send order. 474 DATA-002 Data privacy and integrity: Transmissions over the data 475 channel is likely to contain operationally or privacy-sensitive 476 information or instructions from the remote DOTS agent. Theft or 477 modification of data channel transmissions could lead to 478 information leaks or malicious transactions on behalf of the 479 sending agent (see Section 4 below). Consequently data sent over 480 the data channel MUST be encrypted and authenticated using current 481 industry best practices. DOTS servers MUST enable means to 482 prevent leaking operationally or privacy-sensitive data. Although 483 administrative entities participating in DOTS may detail what data 484 may be revealed to third-party DOTS agents, such considerations 485 are not in scope for this document. 487 DATA-003 Session configuration: To help meet the general and 488 operational requirements in this document, DOTS servers MUST 489 provide methods for DOTS client operators to configure DOTS 490 session behavior using the data channel. DOTS server 491 implementations MUST have mechanisms to configure the following: 493 * Acceptable signal lossiness, as described in GEN-002. 495 * Heartbeat intervals, as described in OP-002. 497 * Maximum mitigation lifetime, as described in OP-005. 499 * Resource identifiers, as described in OP-006. 501 DOTS server implementations MAY expose additional configurability. 502 Additional configurability is implementation-specific. 504 DATA-004 Black- and whitelist management: DOTS servers SHOULD 505 provide methods for DOTS clients to manage black- and white-lists 506 of traffic destined for resources belonging to a client. 508 For example, a DOTS client should be able to create a black- or 509 whitelist entry; retrieve a list of current entries from either 510 list; update the content of either list; and delete entries as 511 necessary. 513 How the DOTS server determines client ownership of address space 514 is not in scope. 516 2.4. Security requirements 518 DOTS must operate within a particularly strict security context, as 519 an insufficiently protected signal or data channel may be subject to 520 abuse, enabling or supplementing the very attacks DOTS purports to 521 mitigate. 523 SEC-001 Peer Mutual Authentication: DOTS agents MUST authenticate 524 each other before a DOTS session is considered valid. The method 525 of authentication is not specified, but should follow current 526 industry best practices with respect to any cryptographic 527 mechanisms to authenticate the remote peer. 529 SEC-002 Message Confidentiality, Integrity and Authenticity: DOTS 530 protocols MUST take steps to protect the confidentiality, 531 integrity and authenticity of messages sent between client and 532 server. While specific transport- and message-level security 533 options are not specified, the protocols MUST follow current 534 industry best practices for encryption and message authentication. 536 In order for DOTS protocols to remain secure despite advancements 537 in cryptanalysis and traffic analysis, DOTS agents MUST be able to 538 negotiate the terms and mechanisms of protocol security, subject 539 to the interoperability and signal message size requirements 540 above. 542 SEC-003 Message Replay Protection: In order to prevent a passive 543 attacker from capturing and replaying old messages, DOTS protocols 544 MUST provide a method for replay detection. 546 2.5. Data Model Requirements 548 The value of DOTS is in standardizing a mechanism to permit elements, 549 networks or domains under or under threat of DDoS attack to request 550 aid mitigating the effects of any such attack. A well-structured 551 DOTS data model is therefore critical to the development of a 552 successful DOTS protocol. 554 DM-001: Structure: The data model structure for the DOTS protocol 555 may be described by a single module, or be divided into related 556 collections of hierarchical modules and sub-modules. If the data 557 model structure is split across modules, those distinct modules 558 MUST allow references to describe the overall data model's 559 structural dependencies. 561 DM-002: Versioning: To ensure interoperability between DOTS protocol 562 implementations, data models MUST be versioned. The version 563 number of the initial data model SHALL be 1. Each published 564 change to the initial published DOTS data model SHALL increment 565 the data model version by 1. 567 How the protocol represents data model versions is not defined in 568 this document. 570 DM-003: Mitigation Status Representation: The data model MUST 571 provide the ability to represent a request for mitigation and the 572 withdrawal of such a request. The data model MUST also support a 573 representation of currently requested mitigation status, including 574 failures and their causes. 576 DM-004: Mitigation Scope Representation: The data model MUST support 577 representation of a requested mitigation's scope. As mitigation 578 scope may be represented in several different ways, per OP-006 579 above, the data model MUST be capable of flexible representation 580 of mitigation scope. 582 DM-005: Mitigation Lifetime Representation: The data model MUST 583 support representation of a mitigation request's lifetime, 584 including mitigations with no specified end time. 586 DM-006: Mitigation Efficacy Representation: The data model MUST 587 support representation of a DOTS client's understanding of the 588 efficacy of a mitigation enabled through a mitigation request. 589 TBD: how do we represent the efficacy? 591 DM-007: Relationship to Transport: The DOTS data model MUST NOT 592 depend on the specifics of any transport to represent fields in 593 the model. 595 3. Congestion Control Considerations 597 3.1. Signal Channel 599 As part of a protocol expected to operate over links affected by DDoS 600 attack traffic, the DOTS signal channel MUST NOT contribute 601 significantly to link congestion. To meet the operational 602 requirements above, DOTS signal channel implementations MUST support 603 UDP. However, UDP when deployed naively can be a source of network 604 congestion, as discussed in [RFC5405]. Signal channel 605 implementations using UDP MUST therefore include a congestion control 606 mechanism. The form of that congestion control is implementation- 607 specific. 609 Signal channel implementations using TCP may rely on built-in TCP 610 congestion control support. 612 3.2. Data Channel 614 As specified in DATA-001, the data channel requires reliable, in- 615 order message delivery. Data channel implementations using TCP may 616 rely on the TCP implementation's built-in congestion control 617 mechanisms. 619 4. Security Considerations 621 DOTS is at risk from three primary attacks: 623 o DOTS agent impersonation 625 o Traffic injection 627 o Signaling blocking 629 The DOTS protocol MUST be designed for minimal data transfer to 630 address the blocking risk. Impersonation and traffic injection 631 mitigation can be managed through current secure communications best 632 practices. See Section 2.4 above for a detailed discussion. 634 5. Contributors 636 Med Boucadair Flemming Andreasen 638 6. Acknowledgments 640 Thanks to Roman Danyliw and Matt Richardson for careful reading and 641 feedback. 643 7. Change Log 645 7.1. 02 revision 647 7.2. 01 revision 649 2016-03-21 651 o Reconciled terminology with -00 revision of 652 [I-D.ietf-dots-use-cases]. 654 o Terminology clarification based on working group feedback. 656 o Moved security-related requirements to separate section. 658 o Made resilience/robustness primary general requirement to align 659 with charter. 661 o Clarified support for unidirectional communication within the 662 bidirection signal channel. 664 o Added proposed operational requirement to support session 665 redirection. 667 o Added proposed operational requirement to support conflict 668 notification. 670 o Added proposed operational requirement to support mitigation 671 lifetime in mitigation requests. 673 o Added proposed operational requirement to support mitigation 674 efficacy reporting from DOTS clients. 676 o Added proposed operational requirement to cache lookups of all 677 kinds. 679 o Added proposed operational requirement regarding NAT traversal. 681 o Removed redundant mutual authentication requirement from data 682 channel requirements. 684 7.3. 00 revision 686 2015-10-15 688 7.4. Initial revision 690 2015-09-24 Andrew Mortensen 692 8. References 694 8.1. Normative References 696 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 697 DOI 10.17487/RFC0768, August 1980, 698 . 700 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 701 RFC 793, DOI 10.17487/RFC0793, September 1981, 702 . 704 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 705 Requirement Levels", BCP 14, RFC 2119, 706 DOI 10.17487/RFC2119, March 1997, 707 . 709 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 710 for Application Designers", BCP 145, RFC 5405, 711 DOI 10.17487/RFC5405, November 2008, 712 . 714 8.2. Informative References 716 [I-D.ietf-dots-architecture] 717 Mortensen, A., Andreasen, F., Reddy, T., 718 christopher_gray3@cable.comcast.com, c., Compton, R., and 719 N. Teague, "Distributed-Denial-of-Service Open Threat 720 Signaling (DOTS) Architecture", draft-ietf-dots- 721 architecture-00 (work in progress), July 2016. 723 [I-D.ietf-dots-use-cases] 724 Dobbins, R., Fouant, S., Migault, D., Moskowitz, R., 725 Teague, N., and L. Xia, "Use cases for DDoS Open Threat 726 Signaling", draft-ietf-dots-use-cases-01 (work in 727 progress), March 2016. 729 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 730 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 731 . 733 [RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address 734 Allocation with CIDR", RFC 1518, DOI 10.17487/RFC1518, 735 September 1993, . 737 [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless 738 Inter-Domain Routing (CIDR): an Address Assignment and 739 Aggregation Strategy", RFC 1519, DOI 10.17487/RFC1519, 740 September 1993, . 742 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 743 Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998, 744 . 746 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 747 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 748 December 1998, . 750 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 751 A., Peterson, J., Sparks, R., Handley, M., and E. 752 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 753 DOI 10.17487/RFC3261, June 2002, 754 . 756 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 757 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 758 DOI 10.17487/RFC4271, January 2006, 759 . 761 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 762 Denial-of-Service Considerations", RFC 4732, 763 DOI 10.17487/RFC4732, December 2006, 764 . 766 Authors' Addresses 768 Andrew Mortensen 769 Arbor Networks, Inc. 770 2727 S. State St 771 Ann Arbor, MI 48104 772 United States 774 Email: amortensen@arbor.net 776 Robert Moskowitz 777 HTT Consulting 778 Oak Park, MI 42837 779 United States 781 Email: rgm@htt-consult.com 783 Tirumaleswar Reddy 784 Cisco Systems, Inc. 785 Cessna Business Park, Varthur Hobli 786 Sarjapur Marathalli Outer Ring Road 787 Bangalore, Karnataka 560103 788 India 790 Email: tireddy@cisco.com