--- 1/draft-ietf-dots-requirements-09.txt 2018-01-02 21:13:08.013614009 -0800 +++ 2/draft-ietf-dots-requirements-10.txt 2018-01-02 21:13:08.057615057 -0800 @@ -1,21 +1,21 @@ DOTS A. Mortensen Internet-Draft Arbor Networks Intended status: Informational R. Moskowitz -Expires: June 22, 2018 Huawei +Expires: July 6, 2018 Huawei T. Reddy McAfee, Inc. - December 19, 2017 + January 02, 2018 Distributed Denial of Service (DDoS) Open Threat Signaling Requirements - draft-ietf-dots-requirements-09 + draft-ietf-dots-requirements-10 Abstract This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols coordinating attack response against DDoS attacks. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -24,25 +24,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 22, 2018. + This Internet-Draft will expire on July 6, 2018. Copyright Notice - Copyright (c) 2017 IETF Trust and the persons identified as the + Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -60,35 +60,35 @@ 2.4. Security Requirements . . . . . . . . . . . . . . . . . . 13 2.5. Data Model Requirements . . . . . . . . . . . . . . . . . 15 3. Congestion Control Considerations . . . . . . . . . . . . . . 16 3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 16 3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 7.2. Informative References . . . . . . . . . . . . . . . . . 18 + 7.2. Informative References . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction 1.1. Context and Motivation Distributed Denial of Service (DDoS) attacks continue to plague network operators around the globe, from Tier-1 service providers on down to enterprises and small businesses. Attack scale and frequency similarly have continued to increase, in part as a result of software vulnerabilities leading to reflection and amplification attacks. - Once-staggering attack traffic volume is now the norm, and the impact - of larger-scale attacks attract the attention of international press - agencies. + High-volume attacks saturating inbound links are now common, and the + impact of larger-scale attacks attract the attention of international + press agencies. The greater impact of contemporary DDoS attacks has led to increased focus on coordinated attack response. Many institutions and enterprises lack the resources or expertise to operate on-premises attack mitigation solutions themselves, or simply find themselves constrained by local bandwidth limitations. To address such gaps, security service providers have begun to offer on-demand traffic scrubbing services, which aim to separate the DDoS traffic from legitimate traffic and forward only the latter. Today each such service offers a proprietary invocation interface for subscribers to @@ -125,21 +125,21 @@ DDoS: A distributed denial-of-service attack, in which traffic originating from multiple sources are directed at a target on a network. DDoS attacks are intended to cause a negative impact on the availability of servers, services, applications, and/or other functionality of an attack target. Denial-of-service considerations are discussed in detail in [RFC4732]. DDoS attack target: A network connected entity with a finite set of resources, such as network bandwidth, memory or CPU, that is the - focus of a DDoS attack. Potential targets include (but not + target of a DDoS attack. Potential targets include (but are not limited to) network elements, network links, servers, and services. DDoS attack telemetry: Collected measurements and behavioral characteristics defining the nature of a DDoS attack. Countermeasure: An action or set of actions taken to recognize and filter out DDoS attack traffic while passing legitimate traffic to the attack target. @@ -168,35 +168,38 @@ feedback to the requesting DOTS client. A DOTS server may also be colocated with a mitigator. DOTS agent: Any DOTS-aware software module capable of participating in a DOTS signal or data channel. It can be a DOTS client, DOTS server, or, as a logical agent, a DOTS gateway. DOTS gateway: A DOTS-aware software module resulting from the logical concatenation of a DOTS server and a DOTS client, analogous to a Session Initiation Protocol (SIP) [RFC3261] Back- - to-Back User Agent (B2BUA) [RFC7092]. Client-side DOTS gateways - are DOTS gateways that are in the DOTS client's domain, while - server-side DOTS gateways denote DOTS gateways that are in the - DOTS server's domain. DOTS gateways are discussed in detail in + to-Back User Agent (B2BUA) [RFC7092]. A DOTS gateway has a + client-facing side, which behaves as a DOTS server for downstream + clients, and a server-facing side, which performs the role of DOTS + client to upstream DOTS servers. Client-domain DOTS gateways are + DOTS gateways that are in the DOTS client's domain, while server- + domain DOTS gateways denote DOTS gateways that are in the DOTS + server's domain. DOTS gateways are described further in [I-D.ietf-dots-architecture]. Signal channel: A bidirectional, mutually authenticated communication channel between two DOTS agents characterized by resilience even in conditions leading to severe packet loss, such as a volumetric DDoS attack causing network congestion. DOTS signal: A concise authenticated status/control message - transmitted between DOTS agents, used to indicate client's need - for mitigation, as well as to convey the status of any requested - mitigation. + transmitted between DOTS agents, used to indicate the client's + need for mitigation, as well as to convey the status of any + requested mitigation. Heartbeat: A message transmitted between DOTS agents over the signal channel, used as a keep-alive and to measure peer health. Data channel: A secure communication layer between two DOTS agents used for infrequent bulk exchange of data not easily or appropriately communicated through the signal channel under attack conditions. Filter: A specification of a matching network traffic flow or set of @@ -271,21 +274,21 @@ DOTS; specifically, to prevent DDoS mitigation in response to DOTS signaling from becoming a new form of attack. In order to provide this level of protection, DOTS agents must have a way to negotiate and agree upon the terms of protocol security. Attacks against the transport protocol should not offer a means of attack against the message confidentiality, integrity and authenticity. The DOTS server and client must also have some common method of defining the scope of any mitigation performed by a mitigator, as well as making adjustments to other commonly configurable features, - such as listen port numbers, exchanging black- and white-lists, and + such as targeted port numbers, exchanging black- and white-lists, and so on. Finally, DOTS should be sufficiently extensible to meet future needs in coordinated attack defense, although this consideration is necessarily superseded by the other operational requirements. 2.1. General Requirements GEN-001 Extensibility: Protocols and data models developed as part of DOTS MUST be extensible in order to keep DOTS adaptable to @@ -299,21 +302,21 @@ designed to maximize the probability of signal delivery even under the severely constrained network conditions imposed by particular attack traffic. The protocol MUST be resilient, that is, continue operating despite message loss and out-of-order or redundant message delivery. In support of signaling protocol robustness, DOTS signals SHOULD be conveyed over a transport not susceptible to Head of Line Blocking. GEN-003 Bidirectionality: To support peer health detection, to maintain an open signal channel, and to increase the probability - of signal delivery during attack, the signal channel MUST be + of signal delivery during an attack, the signal channel MUST be bidirectional, with client and server transmitting signals to each other at regular intervals, regardless of any client request for mitigation. Unidirectional messages MUST be supported within the bidirectional signal channel to allow for unsolicited message delivery, enabling asynchronous notifications between DOTS agents. GEN-004 Bulk Data Exchange: Infrequent bulk data exchange between DOTS agents can also significantly augment attack response coordination, permitting such tasks as population of black- or white-listed source addresses; address or prefix group aliasing; @@ -348,22 +351,22 @@ agents SHOULD assume a PMTU of 1280 bytes. If IPv4 support on legacy or otherwise unusual networks is a consideration and PMTU is unknown, DOTS implementations MAY rely on a PMTU of 576 bytes, as discussed in [RFC0791] and [RFC1122]. SIG-003 Channel Health Monitoring: DOTS agents MUST support exchange of heartbeat messages over the signal channel to monitor channel health. Peer DOTS agents SHOULD regularly send heartbeats to each other while a mitigation request is active. The heartbeat interval during active mitigation is not specified, but SHOULD be - frequent enough to maintain any on-path NAT bindings during - mitigation. + frequent enough to maintain any on-path NAT or Firewall bindings + during mitigation. To support scenarios in which loss of heartbeat is used to trigger mitigation, and to keep the channel active, DOTS clients MAY solicit heartbeat exchanges after successful mutual authentication. When DOTS agents are exchanging heartbeats and no mitigation request is active, either agent MAY request changes to the heartbeat rate. For example, a DOTS server might want to reduce heartbeat frequency or cease heartbeat exchanges when an active DOTS client has not requested mitigation, in order to control load. @@ -371,25 +374,25 @@ Following mutual authentication, a signal channel MUST be considered active until a DOTS agent explicitly ends the session, or either DOTS agent fails to receive heartbeats from the other after a mutually agreed upon retransmission procedure has been exhausted. Because heartbeat loss is much more likely during volumetric attack, DOTS agents SHOULD avoid signal channel termination when mitigation is active and heartbeats are not received by either DOTS agent for an extended period. In such circumstances, DOTS clients MAY attempt to reestablish the signal channel, but SHOULD continue to send heartbeats so that the DOTS - server knows the session is still partially alive. DOTS servers - SHOULD monitor the attack, using feedback from the mitigator and - other available sources, and MAY use the absence of attack traffic - and lack of client heartbeats as an indication the signal channel - is defunct. + server knows the session is still alive. DOTS servers SHOULD + monitor the attack, using feedback from the mitigator and other + available sources, and MAY use the absence of attack traffic and + lack of client heartbeats as an indication the signal channel is + defunct. SIG-004 Channel Redirection: In order to increase DOTS operational flexibility and scalability, DOTS servers SHOULD be able to redirect DOTS clients to another DOTS server at any time. DOTS clients MUST NOT assume the redirection target DOTS server shares security state with the redirecting DOTS server. DOTS clients MAY attempt abbreviated security negotiation methods supported by the protocol, such as DTLS session resumption, but MUST be prepared to negotiate new security state with the redirection target DOTS server. @@ -484,23 +487,23 @@ * IPv4 prefixes in CIDR notation [RFC4632] * IPv6 prefixes [RFC4291][RFC5952] * Domain names [RFC1035] The following mitigation scope types are OPTIONAL: * Uniform Resource Identifiers [RFC3986] - DOTS servers MUST be able to resolve domain names and URIs. How - name resolution is managed on the DOTS server is implementation- - specific. + DOTS servers MUST be able to resolve domain names and (when + supported) URIs. How name resolution is managed on the DOTS + server is implementation-specific. DOTS agents MUST support mitigation scope aliases, allowing DOTS clients and servers to refer to collections of protected resources by an opaque identifier created through the data channel, direct configuration, or other means. Domain name and URI mitigation scopes may be thought of as a form of scope alias, in which the addresses to which the domain name or URI resolve represent the full scope of the mitigation. If there is additional information available narrowing the scope @@ -546,25 +549,26 @@ If UDP is used as the transport for the DOTS signal channel, all considerations in "Middlebox Traversal Guidelines" in [RFC8085] apply to DOTS. Regardless of transport, DOTS protocols MUST follow established best common practices (BCPs) for NAT traversal. 2.3. Data Channel Requirements The data channel is intended to be used for bulk data exchanges between DOTS agents. Unlike the signal channel, which must operate - nominally even when confronted with signal degradation due to packet - loss, the data channel is not expected to be constructed to deal with - attack conditions. As the primary function of the data channel is - data exchange, a reliable transport is required in order for DOTS - agents to detect data delivery success or failure. + nominally even when confronted with signal degradation due to + significant packet loss, the data channel is not expected to be + constructed to deal with attack conditions. As the primary function + of the data channel is data exchange, a reliable transport is + required in order for DOTS agents to detect data delivery success or + failure. The DOTS data channel protocol MUST be extensible. We anticipate the data channel will be used for such purposes as configuration or resource discovery. For example, a DOTS client may submit to a DOTS server a collection of prefixes it wants to refer to by alias when requesting mitigation, to which the server would respond with a success status and the new prefix group alias, or an error status and message in the event the DOTS client's data channel request failed. The transactional nature of such data exchanges suggests a separate set of requirements for the data channel, while the potentially @@ -630,31 +634,32 @@ in cryptanalysis and traffic analysis, DOTS agents MUST be able to negotiate the terms and mechanisms of protocol security, subject to the interoperability and signal message size requirements above. While the interfaces between downstream DOTS server and upstream DOTS client within a DOTS gateway are implementation-specific, those interfaces nevertheless MUST provide security equivalent to that of the signal channels bridged by gateways in the signaling path. For example, when a DOTS gateway consisting of a DOTS - server and DOTS client is running on the same logical device, they - must be within the same process security boundary. + server and DOTS client is running on the same logical device, the + two DOTS agents could be implemented within the same process + security boundary. SEC-003 Message Replay Protection: To prevent a passive attacker from capturing and replaying old messages, and thereby potentially disrupting or influencing the network policy of the receiving DOTS agent's domain, DOTS protocols MUST provide a method for replay detection and prevention. Within the signal channel, messages MUST be uniquely identified - such that replayed or duplicated messages may be detected and + such that replayed or duplicated messages can be detected and discarded. Unique mitigation requests MUST be processed at most once. SEC-004 Authorization: DOTS servers MUST authorize all messages from DOTS clients which pertain to mitigation, configuration, filtering, or status. DOTS servers MUST reject mitigation requests with scopes which the DOTS client is not authorized to manage.