idnits 2.17.1 draft-ietf-dots-requirements-17.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 31, 2019) is 1910 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-10 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-17 == Outdated reference: A later version (-17) exists of draft-ietf-intarea-frag-fragile-08 Summary: 1 error (**), 0 flaws (~~), 5 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: August 4, 2019 Huawei 6 T. Reddy 7 McAfee 8 January 31, 2019 10 Distributed Denial of Service (DDoS) Open Threat Signaling Requirements 11 draft-ietf-dots-requirements-17 13 Abstract 15 This document defines the requirements for the Distributed Denial of 16 Service (DDoS) Open Threat Signaling (DOTS) protocols enabling 17 coordinated response to 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 August 4, 2019. 36 Copyright Notice 38 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . 6 58 2.2. Signal Channel Requirements . . . . . . . . . . . . . . . 8 59 2.3. Data Channel Requirements . . . . . . . . . . . . . . . . 13 60 2.4. Security Requirements . . . . . . . . . . . . . . . . . . 14 61 2.5. Data Model Requirements . . . . . . . . . . . . . . . . . 15 62 3. Congestion Control Considerations . . . . . . . . . . . . . . 16 63 3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 16 64 3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 17 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 67 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 71 8.2. Informative References . . . . . . . . . . . . . . . . . 20 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 74 1. Introduction 76 1.1. Context and Motivation 78 Distributed Denial of Service (DDoS) attacks afflict networks of all 79 kinds, plaguing network operators at service providers and 80 enterprises around the world. High-volume attacks saturating inbound 81 links are now common, as attack scale and frequency continue to 82 increase. 84 The prevalence and impact of these DDoS attacks has led to an 85 increased focus on coordinated attack response. However, many 86 enterprises lack the resources or expertise to operate on-premises 87 attack mitigation solutions themselves, or are constrained by local 88 bandwidth limitations. To address such gaps, service providers have 89 begun to offer on-demand traffic scrubbing services, which are 90 designed to separate the DDoS attack traffic from legitimate traffic 91 and forward only the latter. 93 Today, these services offer proprietary interfaces for subscribers to 94 request attack mitigation. Such proprietary interfaces tie a 95 subscriber to a service while also limiting the network elements 96 capable of participating in the attack mitigation. As a result of 97 signaling interface incompatibility, attack responses may be 98 fragmented or otherwise incomplete, leaving operators in the attack 99 path unable to assist in the defense. 101 A standardized method to coordinate a real-time response among 102 involved operators will increase the speed and effectiveness of DDoS 103 attack mitigation, and reduce the impact of these attacks. This 104 document describes the required characteristics of protocols that 105 enable attack response coordination and mitigation of DDoS attacks. 107 DDoS Open Threat Signaling (DOTS) communicates the need for defensive 108 action in anticipation of or in response to an attack, but does not 109 dictate the implementation of these actions. The requirements in 110 this document are derived from [I-D.ietf-dots-use-cases] and 111 [I-D.ietf-dots-architecture]. 113 1.2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in BCP14 [RFC2119] 118 [RFC8174], when, and only when, they appear in all capitals. 120 This document adopts the following terms: 122 DDoS: A distributed denial-of-service attack, in which traffic 123 originating from multiple sources is directed at a target on a 124 network. DDoS attacks are intended to cause a negative impact on 125 the availability and/or other functionality of an attack target. 126 Denial-of-service considerations are discussed in detail in 127 [RFC4732]. 129 DDoS attack target: A network connected entity with a finite set of 130 resources, such as network bandwidth, memory or CPU, that is the 131 target of a DDoS attack. Potential targets include (but are not 132 limited to) network elements, network links, servers, and 133 services. 135 DDoS attack telemetry: Collected measurements and behavioral 136 characteristics defining the nature of a DDoS attack. 138 Countermeasure: An action or set of actions focused on recognizing 139 and filtering out specific types of DDoS attack traffic while 140 passing legitimate traffic to the attack target. Distinct 141 countermeasures can be layered to defend against attacks combining 142 multiple DDoS attack types. 144 Mitigation: A set of countermeasures enforced against traffic 145 destined for the target or targets of a detected or reported DDoS 146 attack, where countermeasure enforcement is managed by an entity 147 in the network path between attack sources and the attack target. 148 Mitigation methodology is out of scope for this document. 150 Mitigator: An entity, typically a network element, capable of 151 performing mitigation of a detected or reported DDoS attack. The 152 means by which this entity performs these mitigations and how they 153 are requested of it are out of scope for this document. The 154 mitigator and DOTS server receiving a mitigation request are 155 assumed to belong to the same administrative entity. 157 DOTS client: A DOTS-aware software module responsible for requesting 158 attack response coordination with other DOTS-aware elements. 160 DOTS server: A DOTS-aware software module handling and responding to 161 messages from DOTS clients. The DOTS server enables mitigation on 162 behalf of the DOTS client, if requested, by communicating the DOTS 163 client's request to the mitigator and returning selected mitigator 164 feedback to the requesting DOTS client. 166 DOTS agent: Any DOTS-aware software module capable of participating 167 in a DOTS signal or data channel. It can be a DOTS client, DOTS 168 server, or, as a logical agent, a DOTS gateway. 170 DOTS gateway: A DOTS-aware software module resulting from the 171 logical concatenation of the functionality of a DOTS server and a 172 DOTS client into a single DOTS agent. This functionality is 173 analogous to a Session Initiation Protocol (SIP) [RFC3261] Back- 174 to-Back User Agent (B2BUA) [RFC7092]. A DOTS gateway has a 175 client-facing side, which behaves as a DOTS server for downstream 176 clients, and a server-facing side, which performs the role of DOTS 177 client for upstream DOTS servers. Client-domain DOTS gateways are 178 DOTS gateways that are in the DOTS client's domain, while server- 179 domain DOTS gateways denote DOTS gateways that are in the DOTS 180 server's domain. DOTS gateways are described further in 181 [I-D.ietf-dots-architecture]. 183 Signal channel: A bidirectional, mutually authenticated 184 communication channel between DOTS agents that is resilient even 185 in conditions leading to severe packet loss, such as a volumetric 186 DDoS attack causing network congestion. 188 DOTS signal: A concise status/control message transmitted over the 189 authenticated signal channel between DOTS agents, used to indicate 190 the client's need for mitigation, or to convey the status of any 191 requested 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 Data channel: A bidirectional, mutually authenticated communication 197 channel between two DOTS agents used for infrequent but reliable 198 bulk exchange of data not easily or appropriately communicated 199 through the signal channel. Reliable bulk data exchange may not 200 function well or at all during attacks causing network congestion. 201 The data channel is not expected to operate in such conditions. 203 Filter: A specification of a matching network traffic flow or set of 204 flows. The filter will typically have a policy associated with 205 it, e.g., rate-limiting or discarding matching traffic [RFC4949]. 207 Drop-list: A list of filters indicating sources from which traffic 208 should be blocked, regardless of traffic content. 210 Accept-list: A list of filters indicating sources from which traffic 211 should always be allowed, regardless of contradictory data gleaned 212 in a detected attack. 214 Multi-homed DOTS client: A DOTS client exchanging messages with 215 multiple DOTS servers, each in a separate administrative domain. 217 2. Requirements 219 The goal of the DOTS requirements specification is to specify the 220 requirements for DOTS signal channel and data channel protocols that 221 have different application and transport layer requirements. This 222 section describes the required features and characteristics of the 223 DOTS protocols. 225 The DOTS protocols enable and manage mitigation on behalf of a 226 network domain or resource which is or may become the focus of a DDoS 227 attack. An active DDoS attack against the entity controlling the 228 DOTS client need not be present before establishing a communication 229 channel between DOTS agents. Indeed, establishing a relationship 230 with peer DOTS agents during normal network conditions provides the 231 foundation for more rapid attack response against future attacks, as 232 all interactions setting up DOTS, including any business or service 233 level agreements, are already complete. Reachability information of 234 peer DOTS agents is provisioned to a DOTS client using a variety of 235 manual or dynamic methods. Once a relationship between DOTS agents 236 is established, regular communication between DOTS clients and 237 servers enables a common understanding of the DOTS agents' health and 238 activity. 240 The DOTS protocol must at a minimum make it possible for a DOTS 241 client to request aid mounting a defense against a suspected attack. 242 This defense could be coordinated by a DOTS server and include 243 signaling within or between domains as requested by local operators. 244 DOTS clients should similarly be able to withdraw aid requests. DOTS 245 requires no justification from DOTS clients for requests for help, 246 nor do DOTS clients need to justify withdrawing help requests: the 247 decision is local to the DOTS clients' domain. Multi-homed DOTS 248 clients must be able to select the appropriate DOTS server(s) to 249 which a mitigation request is to be sent. The method for selecting 250 the appropriate DOTS server in a multi-homed environment is out of 251 scope for this document. 253 DOTS protocol implementations face competing operational goals when 254 maintaining this bidirectional communication stream. On the one 255 hand, DOTS must include measures to ensure message confidentiality, 256 integrity, authenticity, and replay protection to keep the protocols 257 from becoming additional vectors for the very attacks it is meant to 258 help fight off. On the other hand, the protocol must be resilient 259 under extremely hostile network conditions, providing continued 260 contact between DOTS agents even as attack traffic saturates the 261 link. Such resiliency may be developed several ways, but 262 characteristics such as small message size, asynchronous, redundant 263 message delivery and minimal connection overhead (when possible given 264 local network policy) will tend to contribute to the robustness 265 demanded by a viable DOTS protocol. Operators of peer DOTS-enabled 266 domains may enable quality- or class-of-service traffic tagging to 267 increase the probability of successful DOTS signal delivery, but DOTS 268 does not require such policies be in place, and should be viable in 269 their absence. 271 The DOTS server and client must also have some standardized method of 272 defining the scope of any mitigation, as well as managing other 273 mitigation-related configuration. 275 Finally, DOTS should be sufficiently extensible to meet future needs 276 in coordinated attack defense, although this consideration is 277 necessarily superseded by the other operational requirements. 279 2.1. General Requirements 281 GEN-001 Extensibility: Protocols and data models developed as part 282 of DOTS MUST be extensible in order to keep DOTS adaptable to 283 operational and proprietary DDoS defenses. Future extensions MUST 284 be backward compatible. Implementations of older protocol 285 versions MUST ignore optional information added to DOTS messages 286 as part of newer protocol versions. Implementations of older 287 protocol versions MUST reject mandatory information added to DOTS 288 messages as part of newer protocol versions. 290 GEN-002 Resilience and Robustness: The signaling protocol MUST be 291 designed to maximize the probability of signal delivery even under 292 the severely constrained network conditions caused by attack 293 traffic. Additional means to enhance the resilience of DOTS 294 protocols, including when multiple DOTS servers are provisioned to 295 the DOTS clients, SHOULD be considered. The protocol MUST be 296 resilient, that is, continue operating despite message loss and 297 out-of-order or redundant message delivery. In support of 298 signaling protocol robustness, DOTS signals SHOULD be conveyed 299 over transport and application protocols not susceptible to Head 300 of Line Blocking. These requirements are at SHOULD strength to 301 handle middle-boxes and firewall traversal. 303 GEN-003 Bulk Data Exchange: Infrequent bulk data exchange between 304 DOTS agents can also significantly augment attack response 305 coordination, permitting such tasks as population of drop- or 306 accept-listed source addresses; address or prefix group aliasing; 307 exchange of incident reports; and other hinting or configuration 308 supplementing attack response. 310 As the resilience requirements for the DOTS signal channel mandate 311 small signal message size, a separate, secure data channel 312 utilizing a reliable transport protocol MUST be used for bulk data 313 exchange. However, reliable bulk data exchange may not be 314 possible during attacks causing network congestion. 316 GEN-004 Mitigation Hinting: DOTS clients may have access to attack 317 details which can be used to inform mitigation techniques. 318 Example attack details might include locally collected 319 fingerprints for an on-going attack, or anticipated or active 320 attack focal points based on other threat intelligence. DOTS 321 clients MAY send mitigation hints derived from attack details to 322 DOTS servers, in the full understanding that the DOTS server MAY 323 ignore mitigation hints. Mitigation hints MUST be transmitted 324 across the signal channel, as the data channel may not be 325 functional during an attack. DOTS server handling of mitigation 326 hints is implementation-specific. 328 GEN-005 Loop Handling: In certain scenarios, typically involving 329 misconfiguration of DNS or routing policy, it may be possible for 330 communication between DOTS agents to loop. Signal and data 331 channel implementations should be prepared to detect and terminate 332 such loops to prevent service disruption. 334 2.2. Signal Channel Requirements 336 SIG-001 Use of Common Transport Protocols: DOTS MUST operate over 337 common widely deployed and standardized transport protocols. 338 While connectionless transport such as the User Datagram Protocol 339 (UDP) [RFC0768] SHOULD be used for the signal channel, the 340 Transmission Control Protocol (TCP) [RFC0793] MAY be used if 341 necessary due to network policy or middlebox capabilities or 342 configurations. 344 SIG-002 Sub-MTU Message Size: To avoid message fragmentation and the 345 consequently decreased probability of message delivery over a 346 congested link, signaling protocol message size MUST be kept under 347 signaling Path Maximum Transmission Unit (PMTU), including the 348 byte overhead of any encapsulation, transport headers, and 349 transport- or message-level security. 351 DOTS agents can attempt to learn PMTU using the procedures 352 discussed in [I-D.ietf-intarea-frag-fragile]. If the PMTU cannot 353 be discovered, DOTS agents MUST assume a PMTU of 1280 bytes for 354 IPv6. If IPv4 support on legacy or otherwise unusual networks is 355 a consideration and the PMTU is unknown, DOTS implementations MAY 356 rely on a PMTU of 576 bytes for IPv4 datagrams, as discussed in 357 [RFC0791] and [RFC1122]. 359 SIG-003 Bidirectionality: To support peer health detection, to 360 maintain an active signal channel, and to increase the probability 361 of signal delivery during an attack, the signal channel MUST be 362 bidirectional, with client and server transmitting signals to each 363 other at regular intervals, regardless of any client request for 364 mitigation. The bidirectional signal channel MUST support 365 unidirectional messaging to enable notifications between DOTS 366 agents. 368 SIG-004 Channel Health Monitoring: DOTS agents MUST support exchange 369 of heartbeat messages over the signal channel to monitor channel 370 health. The heartbeat interval during active mitigation could be 371 negotiable, but MUST be frequent enough to maintain any on-path 372 NAT or Firewall bindings during mitigation. When TCP is used as 373 transport, the DOTS signal channel heartbeat messages need to be 374 frequent enough to maintain the TCP connection state. 376 To support scenarios in which loss of heartbeat is used to trigger 377 mitigation, and to keep the channel active, DOTS server MUST 378 solicit heartbeat exchanges after successful mutual 379 authentication. When DOTS agents are exchanging heartbeats and no 380 mitigation request is active, either agent MAY request changes to 381 the heartbeat rate. For example, a DOTS server might want to 382 reduce heartbeat frequency or cease heartbeat exchanges when an 383 active DOTS client has not requested mitigation, in order to 384 control load. 386 Following mutual authentication, a signal channel MUST be 387 considered active until a DOTS agent explicitly ends the session. 388 During peace time, signal channel MUST be considered active until 389 either DOTS agent fails to receive heartbeats from the other after 390 a mutually agreed upon retransmission procedure has been 391 exhausted. Peer DOTS agents MUST regularly send heartbeats to 392 each other while a mitigation request is active. Because 393 heartbeat loss is much more likely during volumetric attack, DOTS 394 agents SHOULD avoid signal channel termination when mitigation is 395 active and heartbeats are not received by either DOTS agent for an 396 extended period. The exception circumstances to terminate the 397 signal channel session during active mitigation are discussed 398 below: 400 * To handle possible DOTS server restart or crash, the DOTS 401 clients MAY attempt to establish a new signal channel session, 402 but MUST continue to send heartbeats on the current session so 403 that the DOTS server knows the session is still alive. If the 404 new session is successfully established, the DOTS client can 405 terminate the current session. 407 * DOTS servers are assumed to have the ability to monitor the 408 attack, using feedback from the mitigator and other available 409 sources, and MAY use the absence of attack traffic and lack of 410 client heartbeats as an indication the signal channel is 411 defunct. 413 SIG-005 Channel Redirection: In order to increase DOTS operational 414 flexibility and scalability, DOTS servers SHOULD be able to 415 redirect DOTS clients to another DOTS server at any time. DOTS 416 clients MUST NOT assume the redirection target DOTS server shares 417 security state with the redirecting DOTS server. DOTS clients are 418 free to attempt abbreviated security negotiation methods supported 419 by the protocol, such as DTLS session resumption, but MUST be 420 prepared to negotiate new security state with the redirection 421 target DOTS server. The authentication domain of the redirection 422 target DOTS server MUST be the same as the authentication domain 423 of the redirecting DOTS server. 425 Due to the increased likelihood of packet loss caused by link 426 congestion during an attack, DOTS servers SHOULD NOT redirect 427 while mitigation is enabled during an active attack against a 428 target in the DOTS client's domain. 430 SIG-006 Mitigation Requests and Status: Authorized DOTS clients MUST 431 be able to request scoped mitigation from DOTS servers. DOTS 432 servers MUST send status to the DOTS clients about mitigation 433 requests. If a DOTS server rejects an authorized request for 434 mitigation, the DOTS server MUST include a reason for the 435 rejection in the status message sent to the client. 437 Due to the higher likelihood of packet loss during a DDoS attack, 438 DOTS servers MUST regularly send mitigation status to authorized 439 DOTS clients which have requested and been granted mitigation, 440 regardless of client requests for mitigation status. 442 When DOTS client-requested mitigation is active, DOTS server 443 status messages MUST include the following mitigation metrics: 445 * Total number of packets blocked by the mitigation 447 * Current number of packets per second blocked 449 * Total number of bytes blocked 451 * Current number of bytes per second blocked 453 DOTS clients MAY take these metrics into account when determining 454 whether to ask the DOTS server to cease mitigation. 456 A DOTS client MAY withdraw a mitigation request at any time, 457 regardless of whether mitigation is currently active. The DOTS 458 server MUST immediately acknowledge a DOTS client's request to 459 stop mitigation. 461 To protect against route or DNS flapping caused by a client 462 rapidly toggling mitigation, and to dampen the effect of 463 oscillating attacks, DOTS servers MAY allow mitigation to continue 464 for a limited period after acknowledging a DOTS client's 465 withdrawal of a mitigation request. During this period, DOTS 466 server status messages SHOULD indicate that mitigation is active 467 but terminating. DOTS clients MAY reverse the mitigation 468 termination during this active-but-terminating period with a new 469 mitigation request for the same scope. The DOTS server MUST treat 470 this request as a mitigation lifetime extension (see SIG-007 471 below). 473 The initial active-but-terminating period is implementation- and 474 deployment- specific, but SHOULD be sufficiently long to absorb 475 latency incurred by route propagation. If a DOTS client refreshes 476 the mitigation before the active-but-terminating period elapses, 477 the DOTS server MAY increase the active-but-terminating period up 478 to a maximum of 300 seconds (5 minutes). After the active-but- 479 terminating period elapses, the DOTS server MUST treat the 480 mitigation as terminated, as the DOTS client is no longer 481 responsible for the mitigation. 483 SIG-007 Mitigation Lifetime: DOTS servers MUST support mitigations 484 for a negotiated time interval, and MUST terminate a mitigation 485 when the lifetime elapses. DOTS servers also MUST support renewal 486 of mitigation lifetimes in mitigation requests from DOTS clients, 487 allowing clients to extend mitigation as necessary for the 488 duration of an attack. 490 DOTS servers MUST treat a mitigation terminated due to lifetime 491 expiration exactly as if the DOTS client originating the 492 mitigation had asked to end the mitigation, including the active- 493 but-terminating period, as described above in SIG-005. 495 DOTS clients MUST include a mitigation lifetime in all mitigation 496 requests. 498 DOTS servers SHOULD support indefinite mitigation lifetimes, 499 enabling architectures in which the mitigator is always in the 500 traffic path to the resources for which the DOTS client is 501 requesting protection. DOTS clients MUST be prepared to not be 502 granted mitigations with indefinite lifetimes. DOTS servers MAY 503 refuse mitigations with indefinite lifetimes, for policy reasons. 504 The reasons themselves are out of scope. If the DOTS server does 505 not grant a mitigation request with an indefinite mitigation 506 lifetime, it MUST set the lifetime to a value that is configured 507 locally. That value MUST be returned in a reply to the requesting 508 DOTS client. 510 SIG-008 Mitigation Scope: DOTS clients MUST indicate desired 511 mitigation scope. The scope type will vary depending on the 512 resources requiring mitigation. All DOTS agent implementations 513 MUST support the following required scope types: 515 * IPv4 prefixes [RFC4632] 517 * IPv6 prefixes [RFC4291][RFC5952] 519 * Domain names [RFC1035] 521 The following mitigation scope types are OPTIONAL: 523 * Uniform Resource Identifiers [RFC3986] 525 DOTS servers MUST be able to resolve domain names and (when 526 supported) URIs. How name resolution is managed on the DOTS 527 server is implementation-specific. 529 DOTS agents MUST support mitigation scope aliases, allowing DOTS 530 clients and servers to refer to collections of protected resources 531 by an opaque identifier created through the data channel, direct 532 configuration, or other means. Domain name and URI mitigation 533 scopes may be thought of as a form of scope alias, in which the 534 addresses to which the domain name or URI resolve represent the 535 full scope of the mitigation. 537 If there is additional information available narrowing the scope 538 of any requested attack response, such as targeted port range, 539 protocol, or service, DOTS clients SHOULD include that information 540 in client mitigation requests. DOTS clients MAY also include 541 additional attack details. DOTS servers MAY ignore such 542 supplemental information when enabling countermeasures on the 543 mitigator. 545 As an active attack evolves, DOTS clients MUST be able to adjust 546 as necessary the scope of requested mitigation by refining the 547 scope of resources requiring mitigation. 549 A DOTS client may obtain the mitigation scope through direct 550 provisioning or through implementation-specific methods of 551 discovery. DOTS clients MUST support at least one mechanism to 552 obtain mitigation scope. 554 SIG-009 Mitigation Efficacy: When a mitigation request is active, 555 DOTS clients MUST transmit a metric of perceived mitigation 556 efficacy to the DOTS server. DOTS servers MAY use the efficacy 557 metric to adjust countermeasures activated on a mitigator on 558 behalf of a DOTS client. 560 SIG-010 Conflict Detection and Notification: Multiple DOTS clients 561 controlled by a single administrative entity may send conflicting 562 mitigation requests as a result of misconfiguration, operator 563 error, or compromised DOTS clients. DOTS servers in the same 564 administrative domain attempting to honor conflicting requests may 565 flap network route or DNS information, degrading the networks 566 attempting to participate in attack response with the DOTS 567 clients. DOTS servers in a single administrative domain SHALL 568 detect such conflicting requests, and SHALL notify the DOTS 569 clients in conflict. The notification MUST indicate the nature 570 and scope of the conflict, for example, the overlapping prefix 571 range in a conflicting mitigation request. 573 SIG-011 Network Address Translator Traversal: DOTS clients may be 574 deployed behind a Network Address Translator (NAT), and need to 575 communicate with DOTS servers through the NAT. DOTS protocols 576 MUST therefore be capable of traversing NATs. 578 If UDP is used as the transport for the DOTS signal channel, all 579 considerations in "Middlebox Traversal Guidelines" in [RFC8085] 580 apply to DOTS. Regardless of transport, DOTS protocols MUST 581 follow established best common practices established in BCP 127 582 for NAT traversal [RFC4787][RFC6888][RFC7857]. 584 2.3. Data Channel Requirements 586 The data channel is intended to be used for bulk data exchanges 587 between DOTS agents. Unlike the signal channel, the data channel is 588 not expected to be constructed to deal with attack conditions. As 589 the primary function of the data channel is data exchange, a reliable 590 transport is required in order for DOTS agents to detect data 591 delivery success or failure. 593 The data channel provides a protocol for DOTS configuration, 594 management. For example, a DOTS client may submit to a DOTS server a 595 collection of prefixes it wants to refer to by alias when requesting 596 mitigation, to which the server would respond with a success status 597 and the new prefix group alias, or an error status and message in the 598 event the DOTS client's data channel request failed. 600 DATA-001 Reliable transport: Messages sent over the data channel 601 MUST be delivered reliably, in order sent. 603 DATA-002 Data privacy and integrity: Transmissions over the data 604 channel are likely to contain operationally or privacy-sensitive 605 information or instructions from the remote DOTS agent. Theft, 606 modification, or replay of data channel transmissions could lead 607 to information leaks or malicious transactions on behalf of the 608 sending agent (see Section 4 below). Consequently data sent over 609 the data channel MUST be encrypted using a secure transport (like 610 TLS). DOTS servers MUST enable means to prevent leaking 611 operationally or privacy-sensitive data. Although administrative 612 entities participating in DOTS may detail what data may be 613 revealed to third-party DOTS agents, such considerations are not 614 in scope for this document. 616 DATA-003 Resource Configuration: To help meet the general and signal 617 channel requirements in Section 2.1 and Section 2.2, DOTS server 618 implementations MUST provide an interface to configure resource 619 identifiers, as described in SIG-008. DOTS server implementations 620 MAY expose additional configurability. Additional configurability 621 is implementation-specific. 623 DATA-004 Policy management: DOTS servers MUST provide methods for 624 DOTS clients to manage drop- and accept-lists of traffic destined 625 for resources belonging to a client. 627 For example, a DOTS client should be able to create a drop- or 628 accept-list entry, retrieve a list of current entries from either 629 list, update the content of either list, and delete entries as 630 necessary. 632 How a DOTS server authorizes DOTS client management of drop- and 633 accept-list entries is implementation-specific. 635 2.4. Security Requirements 637 DOTS must operate within a particularly strict security context, as 638 an insufficiently protected signal or data channel may be subject to 639 abuse, enabling or supplementing the very attacks DOTS purports to 640 mitigate. 642 SEC-001 Peer Mutual Authentication: DOTS agents MUST authenticate 643 each other before a DOTS signal or data channel is considered 644 valid. The method of authentication is not specified in this 645 document, but should follow current industry best practices with 646 respect to any cryptographic mechanisms to authenticate the remote 647 peer. 649 SEC-002 Message Confidentiality, Integrity and Authenticity: DOTS 650 protocols MUST take steps to protect the confidentiality, 651 integrity and authenticity of messages sent between client and 652 server. While specific transport- and message-level security 653 options are not specified, the protocols MUST follow current 654 industry best practices for encryption and message authentication. 656 In order for DOTS protocols to remain secure despite advancements 657 in cryptanalysis and traffic analysis, DOTS agents MUST support 658 secure negotiation of the terms and mechanisms of protocol 659 security, subject to the interoperability and signal message size 660 requirements in Section 2.2. 662 While the interfaces between downstream DOTS server and upstream 663 DOTS client within a DOTS gateway are implementation-specific, 664 those interfaces nevertheless MUST provide security equivalent to 665 that of the signal channels bridged by gateways in the signaling 666 path. For example, when a DOTS gateway consisting of a DOTS 667 server and DOTS client is running on the same logical device, the 668 two DOTS agents could be implemented within the same process 669 security boundary. 671 SEC-003 Message Replay Protection: To prevent a passive attacker 672 from capturing and replaying old messages, and thereby potentially 673 disrupting or influencing the network policy of the receiving DOTS 674 agent's domain, DOTS protocols MUST provide a method for replay 675 detection and prevention. 677 Within the signal channel, messages MUST be uniquely identified 678 such that replayed or duplicated messages can be detected and 679 discarded. Unique mitigation requests MUST be processed at most 680 once. 682 SEC-004 Authorization: DOTS servers MUST authorize all messages from 683 DOTS clients which pertain to mitigation, configuration, 684 filtering, or status. 686 DOTS servers MUST reject mitigation requests with scopes which the 687 DOTS client is not authorized to manage. 689 Likewise, DOTS servers MUST refuse to allow creation, modification 690 or deletion of scope aliases and drop-/accept-lists when the DOTS 691 client is unauthorized. 693 The modes of authorization are implementation-specific. 695 2.5. Data Model Requirements 697 A well-structured DOTS data model is critical to the development of 698 successful DOTS protocols. 700 DM-001 Structure: The data model structure for the DOTS protocol MAY 701 be described by a single module, or be divided into related 702 collections of hierarchical modules and sub-modules. If the data 703 model structure is split across modules, those distinct modules 704 MUST allow references to describe the overall data model's 705 structural dependencies. 707 DM-002 Versioning: To ensure interoperability between DOTS protocol 708 implementations, data models MUST be versioned. How the protocols 709 represent data model versions is not defined in this document. 711 DM-003 Mitigation Status Representation: The data model MUST provide 712 the ability to represent a request for mitigation and the 713 withdrawal of such a request. The data model MUST also support a 714 representation of currently requested mitigation status, including 715 failures and their causes. 717 DM-004 Mitigation Scope Representation: The data model MUST support 718 representation of a requested mitigation's scope. As mitigation 719 scope may be represented in several different ways, per SIG-007 720 above, the data model MUST include extensible representation of 721 mitigation scope. 723 DM-005 Mitigation Lifetime Representation: The data model MUST 724 support representation of a mitigation request's lifetime, 725 including mitigations with no specified end time. 727 DM-006 Mitigation Efficacy Representation: The data model MUST 728 support representation of a DOTS client's understanding of the 729 efficacy of a mitigation enabled through a mitigation request. 731 DM-007 Acceptable Signal Loss Representation: The data model MUST be 732 able to represent the DOTS agent's preference for acceptable 733 signal loss when establishing a signal channel, as described in 734 GEN-002. Measurements of loss might include, but are not 735 restricted to, number of consecutive missed heartbeat messages, 736 retransmission count, or request timeouts. 738 DM-008 Heartbeat Interval Representation: The data model MUST be 739 able to represent the DOTS agent's preferred heartbeat interval, 740 which the client may include when establishing the signal channel, 741 as described in SIG-003. 743 DM-009 Relationship to Transport: The DOTS data model MUST NOT 744 depend on the specifics of any transport to represent fields in 745 the model. 747 3. Congestion Control Considerations 749 3.1. Signal Channel 751 As part of a protocol expected to operate over links affected by DDoS 752 attack traffic, the DOTS signal channel MUST NOT contribute 753 significantly to link congestion. To meet the signal channel 754 requirements above, DOTS signal channel implementations SHOULD 755 support connectionless transports. However, some connectionless 756 transports when deployed naively can be a source of network 757 congestion, as discussed in [RFC8085]. Signal channel 758 implementations using such connectionless transports, such as UDP, 759 therefore MUST include a congestion control mechanism. 761 Signal channel implementations using a IETF standard congestion- 762 controlled transport protocol (like TCP) may rely on built-in 763 transport congestion control support. 765 3.2. Data Channel 767 As specified in DATA-001, the data channel requires reliable, in- 768 order message delivery. Data channel implementations using a IETF 769 standard congestion-controlled transport protocol may rely on the 770 transport implementation's built-in congestion control mechanisms. 772 4. Security Considerations 774 This document informs future protocols under development, and so does 775 not have security considerations of its own. However, operators 776 should be aware of potential risks involved in deploying DOTS. DOTS 777 agent impersonation and signal blocking are discussed here. 778 Additional DOTS security considerations may be found in 779 [I-D.ietf-dots-architecture] and DOTS protocol documents. 781 Impersonation of either a DOTS server or a DOTS client could have 782 catastrophic impact on operations in either domain. If an attacker 783 has the ability to impersonate a DOTS client, that attacker can 784 affect policy on the network path to the DOTS client's domain, up to 785 and including instantiation of drop-lists blocking all inbound 786 traffic to networks for which the DOTS client is authorized to 787 request mitigation. 789 Similarly, an impersonated DOTS server may be able to act as a sort 790 of malicious DOTS gateway, intercepting requests from the downstream 791 DOTS client, and modifying them before transmission to the DOTS 792 server to inflict the desired impact on traffic to or from the DOTS 793 client's domain. Among other things, this malicious DOTS gateway 794 might receive and discard mitigation requests from the DOTS client, 795 ensuring no requested mitigation is ever applied. 797 As detailed in Section 2.4, DOTS implementations require mutual 798 authentication of DOTS agents in order to make agent impersonation 799 more difficult. However, impersonation may still be possible as a 800 result of credential theft, implementation flaws, or compromise of 801 DOTS agents. To detect misuse, DOTS operators should carefully 802 monitor and audit DOTS agents, while employing current secure network 803 communications best practices to reduce attack surface. 805 Blocking communication between DOTS agents has the potential to 806 disrupt the core function of DOTS, which is to request mitigation of 807 active or expected DDoS attacks. The DOTS signal channel is expected 808 to operate over congested inbound links, and, as described in 809 Section 2.2, the signal channel protocol must be designed for minimal 810 data transfer to reduce the incidence of signal loss. 812 5. IANA Considerations 814 This document does not require any IANA action. 816 6. Contributors 818 Mohamed Boucadair 819 Orange 821 mohamed.boucadair@orange.com 823 Flemming Andreasen 824 Cisco Systems, Inc. 826 fandreas@cisco.com 828 Dave Dolson 829 Sandvine 831 ddolson@sandvine.com 833 7. Acknowledgments 835 Thanks to Roman Danyliw, Matt Richardson, Joe Touch, Scott Bradner 836 and Jon Shallow for careful reading and feedback. 838 8. References 840 8.1. Normative References 842 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 843 DOI 10.17487/RFC0768, August 1980, 844 . 846 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 847 DOI 10.17487/RFC0791, September 1981, 848 . 850 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 851 RFC 793, DOI 10.17487/RFC0793, September 1981, 852 . 854 [RFC1035] Mockapetris, P., "Domain names - implementation and 855 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 856 November 1987, . 858 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 859 Communication Layers", STD 3, RFC 1122, 860 DOI 10.17487/RFC1122, October 1989, 861 . 863 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 864 Requirement Levels", BCP 14, RFC 2119, 865 DOI 10.17487/RFC2119, March 1997, 866 . 868 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 869 Resource Identifier (URI): Generic Syntax", STD 66, 870 RFC 3986, DOI 10.17487/RFC3986, January 2005, 871 . 873 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 874 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 875 2006, . 877 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 878 (CIDR): The Internet Address Assignment and Aggregation 879 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 880 2006, . 882 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 883 Translation (NAT) Behavioral Requirements for Unicast 884 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 885 2007, . 887 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 888 Address Text Representation", RFC 5952, 889 DOI 10.17487/RFC5952, August 2010, 890 . 892 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 893 A., and H. Ashida, "Common Requirements for Carrier-Grade 894 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 895 April 2013, . 897 [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, 898 S., and K. Naito, "Updates to Network Address Translation 899 (NAT) Behavioral Requirements", BCP 127, RFC 7857, 900 DOI 10.17487/RFC7857, April 2016, 901 . 903 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 904 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 905 March 2017, . 907 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 908 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 909 May 2017, . 911 8.2. Informative References 913 [I-D.ietf-dots-architecture] 914 Mortensen, A., Andreasen, F., K, R., Teague, N., Compton, 915 R., and c. christopher_gray3@cable.comcast.com, 916 "Distributed-Denial-of-Service Open Threat Signaling 917 (DOTS) Architecture", draft-ietf-dots-architecture-10 918 (work in progress), December 2018. 920 [I-D.ietf-dots-use-cases] 921 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 922 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 923 Open Threat Signaling", draft-ietf-dots-use-cases-17 (work 924 in progress), January 2019. 926 [I-D.ietf-intarea-frag-fragile] 927 Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 928 and F. Gont, "IP Fragmentation Considered Fragile", draft- 929 ietf-intarea-frag-fragile-08 (work in progress), January 930 2019. 932 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 933 A., Peterson, J., Sparks, R., Handley, M., and E. 934 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 935 DOI 10.17487/RFC3261, June 2002, 936 . 938 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 939 Initiation Protocol (SIP) Back-to-Back User Agents", 940 RFC 7092, DOI 10.17487/RFC7092, December 2013, 941 . 943 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 944 Denial-of-Service Considerations", RFC 4732, 945 DOI 10.17487/RFC4732, December 2006, 946 . 948 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 949 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 950 . 952 Authors' Addresses 954 Andrew Mortensen 955 Arbor Networks 956 2727 S. State St 957 Ann Arbor, MI 48104 958 United States 960 Email: amortensen@arbor.net 962 Robert Moskowitz 963 Huawei 964 Oak Park, MI 42837 965 United States 967 Email: rgm@htt-consult.com 969 Tirumaleswar Reddy 970 McAfee 971 Embassy Golf Link Business Park 972 Bangalore, Karnataka 560071 973 India 975 Email: TirumaleswarReddy_Konda@McAfee.com