idnits 2.17.1 draft-ietf-dots-requirements-07.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 30, 2017) is 2362 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-04 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-07 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS A. Mortensen 3 Internet-Draft Arbor Networks 4 Intended status: Informational R. Moskowitz 5 Expires: May 3, 2018 Huawei 6 T. Reddy 7 McAfee, Inc. 8 October 30, 2017 10 Distributed Denial of Service (DDoS) Open Threat Signaling Requirements 11 draft-ietf-dots-requirements-07 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 https://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 May 3, 2018. 36 Copyright Notice 38 Copyright (c) 2017 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 (https://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. Signal Channel Requirements . . . . . . . . . . . . . . . 8 59 2.3. Data Channel Requirements . . . . . . . . . . . . . . . . 12 60 2.4. Security requirements . . . . . . . . . . . . . . . . . . 13 61 2.5. Data Model Requirements . . . . . . . . . . . . . . . . . 15 62 3. Congestion Control Considerations . . . . . . . . . . . . . . 16 63 3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 16 64 3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 16 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 66 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 68 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 7.1. 04 revision . . . . . . . . . . . . . . . . . . . . . . . 17 70 7.2. 03 revision . . . . . . . . . . . . . . . . . . . . . . . 18 71 7.3. 02 revision . . . . . . . . . . . . . . . . . . . . . . . 18 72 7.4. 01 revision . . . . . . . . . . . . . . . . . . . . . . . 18 73 7.5. 00 revision . . . . . . . . . . . . . . . . . . . . . . . 19 74 7.6. Initial revision . . . . . . . . . . . . . . . . . . . . 19 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 77 8.2. Informative References . . . . . . . . . . . . . . . . . 20 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 80 1. Introduction 82 1.1. Context and Motivation 84 Distributed Denial of Service (DDoS) attacks continue to plague 85 network operators around the globe, from Tier-1 service providers on 86 down to enterprises and small businesses. Attack scale and frequency 87 similarly have continued to increase, in part as a result of software 88 vulnerabilities leading to reflection and amplification attacks. 89 Once-staggering attack traffic volume is now the norm, and the impact 90 of larger-scale attacks attract the attention of international press 91 agencies. 93 The greater impact of contemporary DDoS attacks has led to increased 94 focus on coordinated attack response. Many institutions and 95 enterprises lack the resources or expertise to operate on-premises 96 attack mitigation solutions themselves, or simply find themselves 97 constrained by local bandwidth limitations. To address such gaps, 98 security service providers have begun to offer on-demand traffic 99 scrubbing services, which aim to separate the DDoS traffic from 100 legitimate traffic and forward only the latter. Today each such 101 service offers a proprietary invocation interface for subscribers to 102 request attack mitigation, tying subscribers to proprietary signaling 103 implementations while also limiting the subset of network elements 104 capable of participating in the attack mitigation. As a result of 105 signaling interface incompatibility, attack responses may be 106 fragmentary or otherwise incomplete, leaving key players in the 107 attack path unable to assist in the defense. 109 The lack of a common method to coordinate a real-time response among 110 involved actors and network domains inhibits the speed and 111 effectiveness of DDoS attack mitigation. This document describes the 112 required characteristics of protocols enabling requests for DDoS 113 attack mitigation, reducing attack impact and leading to more 114 efficient defensive strategies. 116 DDoS Open Threat Signaling (DOTS) communicates the need for defensive 117 action in anticipation of or in response to an attack, but does not 118 dictate the form any defensive action takes. DOTS supplements calls 119 for help with pertinent details about the detected attack, allowing 120 entities participating in DOTS to form ad hoc, adaptive alliances 121 against DDoS attacks as described in the DOTS use cases 122 [I-D.ietf-dots-use-cases]. The requirements in this document are 123 derived from those use cases and [I-D.ietf-dots-architecture]. 125 1.2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 This document adopts the following terms: 133 DDoS: A distributed denial-of-service attack, in which traffic 134 originating from multiple sources are directed at a target on a 135 network. DDoS attacks are intended to cause a negative impact on 136 the availability of servers, services, applications, and/or other 137 functionality of an attack target. Denial-of-service 138 considerations are discussed in detail in [RFC4732]. 140 DDoS attack target: A network connected entity with a finite set of 141 resources, such as network bandwidth, memory or CPU, that is the 142 focus of a DDoS attack. Potential targets include (but not 143 limited to) network elements, network links, servers, and 144 services. 146 DDoS attack telemetry: Collected measurements and behavioral 147 characteristics defining the nature of a DDoS attack. 149 Countermeasure: An action or set of actions taken to recognize and 150 filter out DDoS attack traffic while passing legitimate traffic to 151 the attack target. 153 Mitigation: A set of countermeasures enforced against traffic 154 destined for the target or targets of a detected or reported DDoS 155 attack, where countermeasure enforcement is managed by an entity 156 in the network path between attack sources and the attack target. 157 Mitigation methodology is out of scope for this document. 159 Mitigator: An entity, typically a network element, capable of 160 performing mitigation of a detected or reported DDoS attack. For 161 the purposes of this document, this entity is a black box capable 162 of mitigation, making no assumptions about availability or design 163 of countermeasures, nor about the programmable interface(s) 164 between this entity and other network elements. The mitigator and 165 invoked DOTS server are assumed to belong to the same 166 administrative entity. 168 DOTS client: A DOTS-aware software module responsible for requesting 169 attack response coordination with other DOTS-aware elements. 171 DOTS server: A DOTS-aware software module handling and responding to 172 messages from DOTS clients. The DOTS server enables mitigation on 173 behalf of the DOTS client, if requested, by communicating the DOTS 174 client's request to the mitigator and returning selected mitigator 175 feedback to the requesting DOTS client. A DOTS server may also be 176 colocated with a mitigator. 178 DOTS agent: Any DOTS-aware software module capable of participating 179 in a DOTS signal or data channel. It can be a DOTS client, DOTS 180 server, or, as a logical agent, a DOTS gateway. 182 DOTS gateway: A DOTS-aware software module resulting from the 183 logical concatenation of a DOTS server and a DOTS client, 184 analogous to a Session Initiation Protocol (SIP) [RFC3261] Back- 185 to-Back User Agent (B2BUA) [RFC7092]. Client-side DOTS gateways 186 are DOTS gateways that are in the DOTS client's domain, while 187 server-side DOTS gateways denote DOTS gateways that are in the 188 DOTS server's domain. DOTS gateways are discussed in detail in 189 [I-D.ietf-dots-architecture]. 191 Signal channel: A bidirectional, mutually authenticated 192 communication channel between two DOTS agents characterized by 193 resilience even in conditions leading to severe packet loss, such 194 as a volumetric DDoS attack causing network congestion. 196 DOTS signal: A concise authenticated status/control message 197 transmitted between DOTS agents, used to indicate client's need 198 for mitigation, as well as to convey the status of any requested 199 mitigation. 201 Heartbeat: A message transmitted between DOTS agents over the signal 202 channel, used as a keep-alive and to measure peer health. 204 Data channel: A secure communication layer between two DOTS agents 205 used for infrequent bulk exchange of data not easily or 206 appropriately communicated through the signal channel under attack 207 conditions. 209 Filter: A specification of a matching network traffic flow or set of 210 flows. The filter will typically have a policy associated with 211 it, e.g., rate-limiting or discarding matching traffic. 213 Blacklist: A filter list of addresses, prefixes, and/or other 214 identifiers indicating sources from which traffic should be 215 blocked, regardless of traffic content. 217 Whitelist: A list of addresses, prefixes, and/or other identifiers 218 indicating sources from which traffic should always be allowed, 219 regardless of contradictory data gleaned in a detected attack. 221 Multi-homed DOTS client: A DOTS client exchanging messages with 222 multiple DOTS servers, each in a separate administrative domain. 224 2. Requirements 226 This section describes the required features and characteristics of 227 the DOTS protocol. 229 DOTS is an advisory protocol. An active DDoS attack against the 230 entity controlling the DOTS client need not be present before 231 establishing a communication channel between DOTS agents. Indeed, 232 establishing a relationship with peer DOTS agents during normal 233 network conditions provides the foundation for more rapid attack 234 response against future attacks, as all interactions setting up DOTS, 235 including any business or service level agreements, are already 236 complete. Peer DOTS agents are provisioned to a DOTS client using a 237 variety of manual or dynamic methods. 239 The DOTS protocol must at a minimum make it possible for a DOTS 240 client to request a mitigator's aid mounting a defense, coordinated 241 by a DOTS server, against a suspected attack, signaling within or 242 between domains as requested by local operators. DOTS clients should 243 similarly be able to withdraw aid requests. DOTS requires no 244 justification from DOTS clients for requests for help, nor do DOTS 245 clients need to justify withdrawing help requests: the decision is 246 local to the DOTS clients' domain. Multi-homed DOTS clients must be 247 able to select the appropriate DOTS server(s) to which a mitigation 248 request is to be sent. Further multi-homing considerations are out 249 of scope. 251 Regular feedback between DOTS clients and DOTS servers supplement the 252 defensive alliance by maintaining a common understanding of the DOTS 253 agents' health and activity. Bidirectional communication between 254 DOTS clients and DOTS servers is therefore critical. 256 DOTS protocol implementations face competing operational goals when 257 maintaining this bidirectional communication stream. On the one 258 hand, the protocol must be resilient under extremely hostile network 259 conditions, providing continued contact between DOTS agents even as 260 attack traffic saturates the link. Such resiliency may be developed 261 several ways, but characteristics such as small message size, 262 asynchronous, redundant message delivery and minimal connection 263 overhead (when possible given local network policy) will tend to 264 contribute to the robustness demanded by a viable DOTS protocol. 265 Operators of peer DOTS-enabled domains may enable quality- or class- 266 of-service traffic tagging to increase the probability of successful 267 DOTS signal delivery, but DOTS does not require such policies be in 268 place. The DOTS solution indeed must be viable especially in their 269 absence. 271 On the other hand, DOTS must include protections ensuring message 272 confidentiality, integrity and authenticity to keep the protocol from 273 becoming another vector for the very attacks it's meant to help fight 274 off. DOTS clients must be able to authenticate DOTS servers, and 275 vice versa, to avoid exposing new attack surfaces when deploying 276 DOTS; specifically, to prevent DDoS mitigation in response to DOTS 277 signaling from becoming a new form of attack. In order to provide 278 this level of protection, DOTS agents must have a way to negotiate 279 and agree upon the terms of protocol security. Attacks against the 280 transport protocol should not offer a means of attack against the 281 message confidentiality, integrity and authenticity. 283 The DOTS server and client must also have some common method of 284 defining the scope of any mitigation performed by the mitigator, as 285 well as making adjustments to other commonly configurable features, 286 such as listen port numbers, exchanging black- and white-lists, and 287 so on. 289 Finally, DOTS should be sufficiently extensible to meet future needs 290 in coordinated attack defense, although this consideration is 291 necessarily superseded by the other operational requirements. 293 2.1. General Requirements 295 GEN-001 Extensibility: Protocols and data models developed as part 296 of DOTS MUST be extensible in order to keep DOTS adaptable to 297 operational and proprietary DDoS defenses. Future extensions MUST 298 be backward compatible. DOTS protocols MUST use a version number 299 system to distinguish protocol revisions. Implementations of 300 older protocol versions SHOULD ignore information added to DOTS 301 messages as part of newer protocol versions. 303 GEN-002 Resilience and Robustness: The signaling protocol MUST be 304 designed to maximize the probability of signal delivery even under 305 the severely constrained network conditions imposed by particular 306 attack traffic. The protocol MUST be resilient, that is, continue 307 operating despite message loss and out-of-order or redundant 308 message delivery. In support of signaling protocol robustness, 309 DOTS signals SHOULD be conveyed over a transport not susceptible 310 to Head of Line Blocking. 312 GEN-003 Bidirectionality: To support peer health detection, to 313 maintain an open signal channel, and to increase the probability 314 of signal delivery during attack, the signal channel MUST be 315 bidirectional, with client and server transmitting signals to each 316 other at regular intervals, regardless of any client request for 317 mitigation. Unidirectional messages MUST be supported within the 318 bidirectional signal channel to allow for unsolicited message 319 delivery, enabling asynchronous notifications between agents. 321 GEN-004 Bulk Data Exchange: Infrequent bulk data exchange between 322 DOTS agents can also significantly augment attack response 323 coordination, permitting such tasks as population of black- or 324 white-listed source addresses; address or prefix group aliasing; 325 exchange of incident reports; and other hinting or configuration 326 supplementing attack response. 328 As the resilience requirements for the DOTS signal channel mandate 329 small signal message size, a separate, secure data channel 330 utilizing a reliable transport protocol MUST be used for bulk data 331 exchange. 333 2.2. Signal Channel Requirements 335 SIG-001 Use of Common Transport Protocols: DOTS MUST operate over 336 common widely deployed and standardized transport protocols. 337 While connectionless transport such as the User Datagram Protocol 338 (UDP) [RFC0768] SHOULD be used for the signal channel, the 339 Transmission Control Protocol (TCP) [RFC0793] MAY be used if 340 necessary due to network policy or middlebox capabilities or 341 configurations. 343 SIG-002 Sub-MTU Message Size: To avoid message fragmentation and the 344 consequently decreased probability of message delivery over a 345 congested link, signaling protocol message size MUST be kept under 346 signaling Path Maximum Transmission Unit (PMTU), including the 347 byte overhead of any encapsulation, transport headers, and 348 transport- or message-level security. 350 DOTS agents SHOULD attempt to learn the PMTU through mechanisms 351 such as Path MTU Discovery [RFC1191] or Packetization Layer Path 352 MTU Discovery [RFC4821]. If the PMTU cannot be discovered, DOTS 353 agents SHOULD assume a PMTU of 1280 bytes. If IPv4 support on 354 legacy or otherwise unusual networks is a consideration and PMTU 355 is unknown, DOTS implementations MAY rely on a PMTU of 576 bytes, 356 as discussed in [RFC0791] and [RFC1122]. 358 SIG-003 Channel Health Monitoring: DOTS agents MUST support exchange 359 of heartbeat messages over the signal channel to monitor channel 360 health. Peer DOTS agents SHOULD regularly send heartbeats to each 361 other while a mitigation request is active. The heartbeat 362 interval during active mitigation is not specified, but SHOULD be 363 frequent enough to maintain any on-path NAT bindings during 364 mitigation. 366 To support scenarios in which loss of heartbeat is used to trigger 367 mitigation, and to keep the channel active, DOTS clients MAY 368 solicit heartbeat exchanges after successful mutual 369 authentication. When DOTS agents are exchanging heartbeats and no 370 mitigation request is active, either agent MAY request changes to 371 the heartbeat rate. For example, a DOTS server might want to 372 delay or cease heartbeat exchanges when an active DOTS client has 373 not requested mitigation, in order to control load. 375 Following mutual authentication, a signal channel MUST be 376 considered active until a DOTS agent explicitly ends the session, 377 or either DOTS agent fails to receive heartbeats from the other 378 after a mutually agreed upon timeout period has elapsed. Because 379 heartbeat loss is much more likely during volumetric attack, DOTS 380 agents SHOULD avoid signal channel termination when mitigation is 381 active and heartbeats are not received by either DOTS agent for an 382 extended period. In such circumstances, DOTS clients MAY attempt 383 to reestablish the signal channel. DOTS servers SHOULD monitor 384 the attack, using feedback from the mitigator and other available 385 sources, and MAY use the absence of attack traffic and lack of 386 client heartbeats as an indication the signal channel is defunct. 388 SIG-004 Channel Redirection: In order to increase DOTS operational 389 flexibility and scalability, DOTS servers SHOULD be able to 390 redirect DOTS clients to another DOTS server at any time. DOTS 391 clients MUST NOT assume the redirection target DOTS server shares 392 security state with the redirecting DOTS server. DOTS clients MAY 393 attempt abbreviated security negotiation methods supported by the 394 protocol, such as DTLS session resumption, but MUST be prepared to 395 negotiate new security state with the redirection target DOTS 396 server. 398 Due to the increased likelihood of packet loss caused by link 399 congestion during an attack, DOTS servers SHOULD NOT redirect 400 while mitigation is enabled during an active attack against a 401 target in the DOTS client's domain. 403 SIG-005 Mitigation Requests and Status: Authorized DOTS clients MUST 404 be able to request scoped mitigation from DOTS servers. DOTS 405 servers MUST send mitigation request status in response to DOTS 406 clients requests for mitigation, and SHOULD accept scoped 407 mitigation requests from authorized DOTS clients. DOTS servers 408 MAY reject authorized requests for mitigation, but MUST include a 409 reason for the rejection in the status message sent to the client. 411 Due to the higher likelihood of packet loss during a DDoS attack, 412 DOTS servers SHOULD regularly send mitigation status to authorized 413 DOTS clients which have requested and been granted mitigation, 414 regardless of client requests for mitigation status. 416 When DOTS client-requested mitigation is active, DOTS server 417 status messages SHOULD include the following mitigation metrics: 419 * Total number of packets blocked by the mitigation 421 * Current number of packets per second blocked 423 * Total number of bytes blocked 425 * Current number of bytes per second blocked 427 DOTS clients MAY take these metrics into account when determining 428 whether to ask the DOTS server to cease mitigation. 430 Once a DOTS client requests mitigation, the client MAY withdraw 431 that request at any time, regardless of whether mitigation is 432 currently active. The DOTS server MUST immediately acknowledge a 433 DOTS client's request to stop mitigation. 435 To protect against route or DNS flapping caused by a client 436 rapidly toggling mitigation, and to dampen the effect of 437 oscillating attacks, DOTS servers MAY allow mitigation to continue 438 for a limited period after acknowledging a DOTS client's 439 withdrawal of a mitigation request. During this period, DOTS 440 server status messages SHOULD indicate that mitigation is active 441 but terminating. 443 The initial active-but-terminating period is implementation- 444 specific, but SHOULD be sufficiently long to absorb latency 445 incurred by route propagation. If the client requests mitigation 446 again before the initial active-but-terminating period elapses, 447 the DOTS server MAY exponentially increase the active-but- 448 terminating period up to a maximum of 300 seconds (5 minutes). 449 After the active-but-terminating period elapses, the DOTS server 450 MUST treat the mitigation as terminated, as the DOTS client is no 451 longer responsible for the mitigation. For example, if there is a 452 financial relationship between the DOTS client and server domains, 453 the DOTS client ceases incurring cost at this point. 455 SIG-006 Mitigation Lifetime: DOTS servers MUST support mitigation 456 lifetimes, and MUST terminate a mitigation when the lifetime 457 elapses. DOTS servers also MUST support renewal of mitigation 458 lifetimes in mitigation requests from DOTS clients, allowing 459 clients to extend mitigation as necessary for the duration of an 460 attack. 462 DOTS servers MUST treat a mitigation terminated due to lifetime 463 expiration exactly as if the DOTS client originating the 464 mitigation had asked to end the mitigation, including the active- 465 but-terminating period, as described above in SIG-005. 467 DOTS clients SHOULD include a mitigation lifetime in all 468 mitigation requests. If a DOTS client does not include a 469 mitigation lifetime in requests for help sent to the DOTS server, 470 the DOTS server will use a reasonable default as defined by the 471 protocol. 473 DOTS servers SHOULD support indefinite mitigation lifetimes, 474 enabling architectures in which the mitigator is always in the 475 traffic path to the resources for which the DOTS client is 476 requesting protection. DOTS clients MUST be prepared to not be 477 granted mitigations with indefinite lifetimes. DOTS servers MAY 478 refuse mitigations with indefinite lifetimes, for policy reasons. 479 The reasons themselves are out of scope. If the DOTS server does 480 not grant a mitigation request with an indefinite mitigation 481 lifetime, it MUST set the lifetime to a value that is configured 482 locally. That value MUST be returned in a reply to the requesting 483 DOTS client. 485 SIG-007 Mitigation Scope: DOTS clients MUST indicate desired 486 mitigation scope. The scope type will vary depending on the 487 resources requiring mitigation. All DOTS agent implementations 488 MUST support the following required scope types: 490 * IPv4 addresses in dotted quad format 492 * IPv4 prefixes in CIDR notation [RFC4632] 494 * IPv6 addresses [RFC4291][RFC5952] 496 * IPv6 prefixes [RFC4291][RFC5952] 498 * Domain names [RFC1035] 500 The following mitigation scope types are OPTIONAL: 502 * Uniform Resource Identifiers [RFC3986] 504 DOTS agents MUST support mitigation scope aliases, allowing DOTS 505 clients and servers to refer to collections of protected resources 506 by an opaque identifier created through the data channel, direct 507 configuration, or other means. Domain name and URI mitigation 508 scopes may be thought of as a form of scope alias, in which the 509 addresses to which the domain name or URI resolve represent the 510 full scope of the mitigation. 512 If there is additional information available narrowing the scope 513 of any requested attack response, such as targeted port range, 514 protocol, or service, DOTS clients SHOULD include that information 515 in client signals. DOTS clients MAY also include additional 516 attack details. Such supplemental information is OPTIONAL, and 517 DOTS servers MAY ignore it when enabling countermeasures on the 518 mitigator. 520 As an active attack evolves, clients MUST be able to adjust as 521 necessary the scope of requested mitigation by refining the scope 522 of resources requiring mitigation. 524 The DOTS client may obtain the mitigation scope through direct 525 provisioning or through implementation-specific methods of 526 discovery. DOTS clients MUST support at least one mechanism to 527 obtain mitigiation scope. 529 SIG-008 Mitigation Efficacy: When a mitigation request by a DOTS 530 client is active, DOTS clients SHOULD transmit a metric of 531 perceived mitigation efficacy to the DOTS server. DOTS servers 532 MAY use the efficacy metric to adjust countermeasures activated on 533 a mitigator on behalf of a DOTS client. 535 SIG-009 Conflict Detection and Notification: Multiple DOTS clients 536 controlled by a single administrative entity may send conflicting 537 mitigation requests for pools of protected resources as a result 538 of misconfiguration, operator error, or compromised DOTS clients. 539 DOTS servers in the same administrative domain attempting to honor 540 conflicting requests may flap network route or DNS information, 541 degrading the networks attempting to participate in attack 542 response with the DOTS clients. DOTS servers in a single 543 administrative domain SHALL detect such conflicting requests, and 544 SHALL notify the DOTS clients in conflict. The notification 545 SHOULD indicate the nature and scope of the conflict, for example, 546 the overlapping prefix range in a conflicting mitigation request. 548 SIG-010: Network Address Translator Traversal: DOTS clients may be 549 deployed behind a Network Address Translator (NAT), and need to 550 communicate with DOTS servers through the NAT. DOTS protocols 551 MUST therefore be capable of traversing NATs. 553 If UDP is used as the transport for the DOTS signal channel, all 554 considerations in "Middlebox Traversal Guidelines" in [RFC8085] 555 apply to DOTS. Regardless of transport, DOTS protocols MUST 556 follow established best common practices (BCPs) for NAT traversal. 558 2.3. Data Channel Requirements 560 The data channel is intended to be used for bulk data exchanges 561 between DOTS agents. Unlike the signal channel, which must operate 562 nominally even when confronted with signal degradation due to packet 563 loss, the data channel is not expected to be constructed to deal with 564 attack conditions. As the primary function of the data channel is 565 data exchange, a reliable transport is required in order for DOTS 566 agents to detect data delivery success or failure. 568 The data channel must be extensible. We anticipate the data channel 569 will be used for such purposes as configuration or resource 570 discovery. For example, a DOTS client may submit to the DOTS server 571 a collection of prefixes it wants to refer to by alias when 572 requesting mitigation, to which the server would respond with a 573 success status and the new prefix group alias, or an error status and 574 message in the event the DOTS client's data channel request failed. 575 The transactional nature of such data exchanges suggests a separate 576 set of requirements for the data channel, while the potentially 577 sensitive content sent between DOTS agents requires extra precautions 578 to ensure data privacy and authenticity. 580 DATA-001 Reliable transport: Messages sent over the data channel 581 MUST be delivered reliably, in order sent. 583 DATA-002 Data privacy and integrity: Transmissions over the data 584 channel are likely to contain operationally or privacy-sensitive 585 information or instructions from the remote DOTS agent. Theft or 586 modification of data channel transmissions could lead to 587 information leaks or malicious transactions on behalf of the 588 sending agent (see Section 4 below). Consequently data sent over 589 the data channel MUST be encrypted and authenticated using current 590 industry best practices. DOTS servers MUST enable means to 591 prevent leaking operationally or privacy-sensitive data. Although 592 administrative entities participating in DOTS may detail what data 593 may be revealed to third-party DOTS agents, such considerations 594 are not in scope for this document. 596 DATA-003 Resource Configuration: To help meet the general and signal 597 channel requirements in this document, DOTS server implementations 598 MUST provide an interface to configure resource identifiers, as 599 described in SIG-007. DOTS server implementations MAY expose 600 additional configurability. Additional configurability is 601 implementation-specific. 603 DATA-004 Black- and whitelist management: DOTS servers MUST provide 604 methods for DOTS clients to manage black- and white-lists of 605 traffic destined for resources belonging to a client. 607 For example, a DOTS client should be able to create a black- or 608 whitelist entry; retrieve a list of current entries from either 609 list; update the content of either list; and delete entries as 610 necessary. 612 How the DOTS server authorizes DOTS client management of black- 613 and white-list entries is implementation-specific. 615 2.4. Security requirements 617 DOTS must operate within a particularly strict security context, as 618 an insufficiently protected signal or data channel may be subject to 619 abuse, enabling or supplementing the very attacks DOTS purports to 620 mitigate. 622 SEC-001 Peer Mutual Authentication: DOTS agents MUST authenticate 623 each other before a DOTS signal or data channel is considered 624 valid. The method of authentication is not specified, but should 625 follow current industry best practices with respect to any 626 cryptographic mechanisms to authenticate the remote peer. 628 SEC-002 Message Confidentiality, Integrity and Authenticity: DOTS 629 protocols MUST take steps to protect the confidentiality, 630 integrity and authenticity of messages sent between client and 631 server. While specific transport- and message-level security 632 options are not specified, the protocols MUST follow current 633 industry best practices for encryption and message authentication. 635 In order for DOTS protocols to remain secure despite advancements 636 in cryptanalysis and traffic analysis, DOTS agents MUST be able to 637 negotiate the terms and mechanisms of protocol security, subject 638 to the interoperability and signal message size requirements 639 above. 641 While the interfaces between downstream DOTS server and upstream 642 DOTS client within a DOTS gateway are implementation-specific, 643 those interfaces nevertheless MUST provide security equivalent to 644 that of the signal channels bridged by gateways in the signaling 645 path. For example, when a DOTS gateway consisting of a DOTS 646 server and DOTS client is running on the same logical device, they 647 must be within the same process security boundary. 649 SEC-003 Message Replay Protection: To prevent a passive attacker 650 from capturing and replaying old messages, and thereby potentially 651 disrupting or influencing the network policy of the receiving DOTS 652 agent's domain, DOTS protocols MUST provide a method for replay 653 detection and prevention. 655 Within the signal channel, messages MUST be uniquely identified 656 such that replayed or duplicated messages may be detected and 657 discarded. Unique mitigation requests MUST be processed at most 658 once. 660 SEC-004 Authorization: DOTS servers MUST authorize all messages from 661 DOTS clients which pertain to mitigation, configuration, 662 filtering, or status. 664 DOTS servers MUST reject mitigation requests with scopes which the 665 DOTS client is not authorized to manage. 667 Likewise, DOTS servers MUST refuse to allow creation, modification 668 or deletion of scope aliases and black-/white-lists when the DOTS 669 client is unauthorized. 671 The modes of authorization are implementation-specific. 673 2.5. Data Model Requirements 675 The value of DOTS is in standardizing a mechanism to permit elements, 676 networks or domains under threat of DDoS attack to request aid 677 mitigating the effects of any such attack. A well-structured DOTS 678 data model is therefore critical to the development of a successful 679 DOTS protocol. 681 DM-001: Structure: The data model structure for the DOTS protocol 682 may be described by a single module, or be divided into related 683 collections of hierarchical modules and sub-modules. If the data 684 model structure is split across modules, those distinct modules 685 MUST allow references to describe the overall data model's 686 structural dependencies. 688 DM-002: Versioning: To ensure interoperability between DOTS protocol 689 implementations, data models MUST be versioned. The version 690 number of the initial data model SHALL be 1. Each published 691 change to the initial published DOTS data model SHALL increment 692 the data model version by 1. 694 How the protocol represents data model versions is not defined in 695 this document. 697 DM-003: Mitigation Status Representation: The data model MUST 698 provide the ability to represent a request for mitigation and the 699 withdrawal of such a request. The data model MUST also support a 700 representation of currently requested mitigation status, including 701 failures and their causes. 703 DM-004: Mitigation Scope Representation: The data model MUST support 704 representation of a requested mitigation's scope. As mitigation 705 scope may be represented in several different ways, per SIG-007 706 above, the data model MUST be capable of flexible representation 707 of mitigation scope. 709 DM-005: Mitigation Lifetime Representation: The data model MUST 710 support representation of a mitigation request's lifetime, 711 including mitigations with no specified end time. 713 DM-006: Mitigation Efficacy Representation: The data model MUST 714 support representation of a DOTS client's understanding of the 715 efficacy of a mitigation enabled through a mitigation request. 717 DM-007: Acceptable Signal Loss Representation: The data model MUST 718 be able to represent the DOTS agent's preference for acceptable 719 signal loss when establishing a signal channel, as described in 720 GEN-002. 722 DM-008: Heartbeat Interval Representation: The data model MUST be 723 able to represent the DOTS agent's preferred heartbeat interval, 724 which the client may include when establishing the signal channel, 725 as described in SIG-003. 727 DM-009: Relationship to Transport: The DOTS data model MUST NOT 728 depend on the specifics of any transport to represent fields in 729 the model. 731 3. Congestion Control Considerations 733 3.1. Signal Channel 735 As part of a protocol expected to operate over links affected by DDoS 736 attack traffic, the DOTS signal channel MUST NOT contribute 737 significantly to link congestion. To meet the signal channel 738 requirements above, DOTS signal channel implementations SHOULD 739 support connectionless transports. However, some connectionless 740 transports when deployed naively can be a source of network 741 congestion, as discussed in [RFC5405]. Signal channel 742 implementations using such connectionless transports, such as UDP, 743 therefore MUST include a congestion control mechanism. 745 Signal channel implementations using TCP may rely on built-in TCP 746 congestion control support. 748 3.2. Data Channel 750 As specified in DATA-001, the data channel requires reliable, in- 751 order message delivery. Data channel implementations using TCP may 752 rely on the TCP implementation's built-in congestion control 753 mechanisms. 755 4. Security Considerations 757 DOTS is at risk from three primary attacks: 759 o DOTS agent impersonation 761 o Traffic injection 763 o Signaling blocking 765 The DOTS protocol MUST be designed for minimal data transfer to 766 address the blocking risk. Impersonation and traffic injection 767 mitigation can be managed through current secure communications best 768 practices. See Section 2.4 above for a detailed discussion. 770 5. Contributors 772 Mohamed Boucadair 773 Orange 775 mohamed.boucadair@orange.com 777 Flemming Andreasen 778 Cisco Systems, Inc. 780 fandreas@cisco.com 782 Dave Dolson 783 Sandvine 785 ddolson@sandvine.com 787 6. Acknowledgments 789 Thanks to Roman Danyliw and Matt Richardson for careful reading and 790 feedback. 792 7. Change Log 794 7.1. 04 revision 796 2017-03-13 798 o Establish required and optional mitigation scope types 800 o Specify message size for DOTS signal channel 802 o Recast mitigation lifetime as a DOTS server requirement 804 o Clarify DOTS server's responsibilities after client request to end 805 mitigation 807 o Specify security state handling on redirection 809 o Signal channel should use transport not susceptible to HOL 810 blocking 812 o Expanded list of DDoS types to include network links 814 7.2. 03 revision 816 2016-10-30 818 o Extended SEC-003 to require secure interfaces within DOTS 819 gateways. 821 o Changed DATA-003 to Resource Configuration, delegating control of 822 acceptable signal loss, heartbeat intervals, and mitigation 823 lifetime to DOTS client. 825 o Added data model requirements reflecting client control over the 826 above. 828 7.3. 02 revision 830 7.4. 01 revision 832 2016-03-21 834 o Reconciled terminology with -00 revision of 835 [I-D.ietf-dots-use-cases]. 837 o Terminology clarification based on working group feedback. 839 o Moved security-related requirements to separate section. 841 o Made resilience/robustness primary general requirement to align 842 with charter. 844 o Clarified support for unidirectional communication within the 845 bidirectional signal channel. 847 o Added proposed operational requirement to support session 848 redirection. 850 o Added proposed operational requirement to support conflict 851 notification. 853 o Added proposed operational requirement to support mitigation 854 lifetime in mitigation requests. 856 o Added proposed operational requirement to support mitigation 857 efficacy reporting from DOTS clients. 859 o Added proposed operational requirement to cache lookups of all 860 kinds. 862 o Added proposed operational requirement regarding NAT traversal. 864 o Removed redundant mutual authentication requirement from data 865 channel requirements. 867 7.5. 00 revision 869 2015-10-15 871 7.6. Initial revision 873 2015-09-24 Andrew Mortensen 875 8. References 877 8.1. Normative References 879 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 880 DOI 10.17487/RFC0768, August 1980, 881 . 883 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 884 DOI 10.17487/RFC0791, September 1981, 885 . 887 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 888 RFC 793, DOI 10.17487/RFC0793, September 1981, 889 . 891 [RFC1035] Mockapetris, P., "Domain names - implementation and 892 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 893 November 1987, . 895 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 896 Communication Layers", STD 3, RFC 1122, 897 DOI 10.17487/RFC1122, October 1989, 898 . 900 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 901 DOI 10.17487/RFC1191, November 1990, 902 . 904 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 905 Requirement Levels", BCP 14, RFC 2119, 906 DOI 10.17487/RFC2119, March 1997, 907 . 909 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 910 Resource Identifier (URI): Generic Syntax", STD 66, 911 RFC 3986, DOI 10.17487/RFC3986, January 2005, 912 . 914 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 915 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 916 2006, . 918 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 919 (CIDR): The Internet Address Assignment and Aggregation 920 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 921 2006, . 923 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 924 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 925 . 927 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 928 for Application Designers", RFC 5405, 929 DOI 10.17487/RFC5405, November 2008, 930 . 932 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 933 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 934 March 2017, . 936 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 937 Address Text Representation", RFC 5952, 938 DOI 10.17487/RFC5952, August 2010, 939 . 941 8.2. Informative References 943 [I-D.ietf-dots-architecture] 944 Mortensen, A., Andreasen, F., Reddy, T., 945 christopher_gray3@cable.comcast.com, c., Compton, R., and 946 N. Teague, "Distributed-Denial-of-Service Open Threat 947 Signaling (DOTS) Architecture", draft-ietf-dots- 948 architecture-04 (work in progress), July 2017. 950 [I-D.ietf-dots-use-cases] 951 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 952 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 953 Open Threat Signaling", draft-ietf-dots-use-cases-07 (work 954 in progress), July 2017. 956 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 957 A., Peterson, J., Sparks, R., Handley, M., and E. 958 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 959 DOI 10.17487/RFC3261, June 2002, 960 . 962 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 963 Initiation Protocol (SIP) Back-to-Back User Agents", 964 RFC 7092, DOI 10.17487/RFC7092, December 2013, 965 . 967 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 968 Denial-of-Service Considerations", RFC 4732, 969 DOI 10.17487/RFC4732, December 2006, 970 . 972 Authors' Addresses 974 Andrew Mortensen 975 Arbor Networks 976 2727 S. State St 977 Ann Arbor, MI 48104 978 United States 980 Email: amortensen@arbor.net 982 Robert Moskowitz 983 Huawei 984 Oak Park, MI 42837 985 United States 987 Email: rgm@htt-consult.com 989 Tirumaleswar Reddy 990 McAfee, Inc. 991 Embassy Golf Link Business Park 992 Bangalore, Karnataka 560071 993 India 995 Email: TirumaleswarReddy_Konda@McAfee.com