--- 1/draft-ietf-dots-requirements-17.txt 2019-02-04 01:13:09.254907488 -0800 +++ 2/draft-ietf-dots-requirements-18.txt 2019-02-04 01:13:09.302908650 -0800 @@ -1,21 +1,21 @@ DOTS A. Mortensen Internet-Draft Arbor Networks -Intended status: Informational R. Moskowitz -Expires: August 4, 2019 Huawei - T. Reddy - McAfee - January 31, 2019 +Intended status: Informational T. Reddy +Expires: August 6, 2019 McAfee + R. Moskowitz + Huawei + February 2, 2019 Distributed Denial of Service (DDoS) Open Threat Signaling Requirements - draft-ietf-dots-requirements-17 + draft-ietf-dots-requirements-18 Abstract This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -24,21 +24,21 @@ 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 August 4, 2019. + This Internet-Draft will expire on August 6, 2019. Copyright Notice Copyright (c) 2019 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 @@ -68,42 +68,42 @@ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction 1.1. Context and Motivation - Distributed Denial of Service (DDoS) attacks afflict networks of all - kinds, plaguing network operators at service providers and - enterprises around the world. High-volume attacks saturating inbound - links are now common, as attack scale and frequency continue to - increase. + Distributed Denial of Service (DDoS) attacks afflict networks + connected to the Internet, plaguing network operators at service + providers and enterprises around the world. High-volume attacks + saturating inbound links are now common, as attack scale and + frequency continue to increase. The prevalence and impact of these DDoS attacks has led to an increased focus on coordinated attack response. However, many enterprises lack the resources or expertise to operate on-premises attack mitigation solutions themselves, or are constrained by local bandwidth limitations. To address such gaps, service providers have begun to offer on-demand traffic scrubbing services, which are designed to separate the DDoS attack traffic from legitimate traffic and forward only the latter. Today, these services offer proprietary interfaces for subscribers to request attack mitigation. Such proprietary interfaces tie a - subscriber to a service while also limiting the network elements - capable of participating in the attack mitigation. As a result of - signaling interface incompatibility, attack responses may be - fragmented or otherwise incomplete, leaving operators in the attack - path unable to assist in the defense. + subscriber to a service and limit the abilities of network elements + that would otherwise be capable of participating in attack + mitigation. As a result of signaling interface incompatibility, + attack responses may be fragmented or otherwise incomplete, leaving + operators in the attack path unable to assist in the defense. A standardized method to coordinate a real-time response among involved operators will increase the speed and effectiveness of DDoS attack mitigation, and reduce the impact of these attacks. This document describes the required characteristics of protocols that enable attack response coordination and mitigation of DDoS attacks. DDoS Open Threat Signaling (DOTS) communicates the need for defensive action in anticipation of or in response to an attack, but does not dictate the implementation of these actions. The requirements in @@ -119,25 +119,23 @@ This document adopts the following terms: DDoS: A distributed denial-of-service attack, in which traffic originating from multiple sources is directed at a target on a network. DDoS attacks are intended to cause a negative impact on the availability 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 - target of a DDoS attack. Potential targets include (but are not - limited to) network elements, network links, servers, and - services. + DDoS attack target: A network connected entity that is the 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 focused on recognizing and filtering out specific types of DDoS attack traffic while passing legitimate traffic to the attack target. Distinct countermeasures can be layered to defend against attacks combining multiple DDoS attack types. @@ -170,29 +168,31 @@ DOTS gateway: A DOTS-aware software module resulting from the logical concatenation of the functionality of a DOTS server and a DOTS client into a single DOTS agent. This functionality is analogous to a Session Initiation Protocol (SIP) [RFC3261] Back- 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 for 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 + server's domain. A DOTS gateway may terminate multiple discrete + DOTS client connections and may aggregate these into a single or + multiple connections. DOTS gateways are described further in [I-D.ietf-dots-architecture]. Signal channel: A bidirectional, mutually authenticated communication channel between DOTS agents that is resilient even in conditions leading to severe packet loss, such as a volumetric DDoS attack causing network congestion. - DOTS signal: A concise status/control message transmitted over the + DOTS signal: A status/control message transmitted over the authenticated signal channel between DOTS agents, used to indicate the client's need for mitigation, or 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 bidirectional, mutually authenticated communication channel between two DOTS agents used for infrequent but reliable bulk exchange of data not easily or appropriately communicated @@ -209,40 +209,43 @@ Accept-list: A list of filters indicating sources from which traffic should always be allowed, regardless of contradictory data gleaned in a detected attack. Multi-homed DOTS client: A DOTS client exchanging messages with multiple DOTS servers, each in a separate administrative domain. 2. Requirements + The expected layout and interactions amongst DOTS entities is + described in the DOTS Architecture [I-D.ietf-dots-architecture]. + The goal of the DOTS requirements specification is to specify the requirements for DOTS signal channel and data channel protocols that have different application and transport layer requirements. This section describes the required features and characteristics of the DOTS protocols. - The DOTS protocols enable and manage mitigation on behalf of a - network domain or resource which is or may become the focus of a DDoS - attack. An active DDoS attack against the entity controlling the - DOTS client need not be present before establishing a communication - channel between DOTS agents. Indeed, establishing a relationship - with peer DOTS agents during normal network conditions provides the - foundation for more rapid attack response against future attacks, as - all interactions setting up DOTS, including any business or service - level agreements, are already complete. Reachability information of - peer DOTS agents is provisioned to a DOTS client using a variety of - manual or dynamic methods. Once a relationship between DOTS agents - is established, regular communication between DOTS clients and - servers enables a common understanding of the DOTS agents' health and - activity. + The goal of DOTS protocols is to enable and manage mitigation on + behalf of a network domain or resource which is or may become the + focus of a DDoS attack. An active DDoS attack against the entity + controlling the DOTS client need not be present before establishing a + communication channel between DOTS agents. Indeed, establishing a + relationship with peer DOTS agents during normal network conditions + provides the foundation for more rapid attack response against future + attacks, as all interactions setting up DOTS, including any business + or service level agreements, are already complete. Reachability + information of peer DOTS agents is provisioned to a DOTS client using + a variety of manual or dynamic methods. Once a relationship between + DOTS agents is established, regular communication between DOTS + clients and servers enables a common understanding of the DOTS + agents' health and activity. The DOTS protocol must at a minimum make it possible for a DOTS client to request aid mounting a defense against a suspected attack. This defense could be coordinated by a DOTS server and include signaling within or between domains as requested by local operators. DOTS clients should similarly be able to withdraw aid requests. DOTS requires no justification from DOTS clients for requests for help, nor do DOTS clients need to justify withdrawing help requests: the decision is local to the DOTS clients' domain. Multi-homed DOTS clients must be able to select the appropriate DOTS server(s) to @@ -273,26 +276,26 @@ mitigation-related configuration. 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 - operational and proprietary DDoS defenses. Future extensions MUST - be backward compatible. Implementations of older protocol - versions MUST ignore optional information added to DOTS messages - as part of newer protocol versions. Implementations of older - protocol versions MUST reject mandatory information added to DOTS - messages as part of newer protocol versions. + proprietary DDoS defenses. Future extensions MUST be backward + compatible. Implementations of older protocol versions MUST + ignore optional information added to DOTS messages as part of + newer protocol versions. Implementations of older protocol + versions MUST reject mandatory information added to DOTS messages + as part of newer protocol versions. GEN-002 Resilience and Robustness: The signaling protocol MUST be designed to maximize the probability of signal delivery even under the severely constrained network conditions caused by attack traffic. Additional means to enhance the resilience of DOTS protocols, including when multiple DOTS servers are provisioned to the DOTS clients, SHOULD be considered. 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 @@ -645,20 +648,25 @@ document, but should follow current industry best practices with respect to any cryptographic mechanisms to authenticate the remote peer. SEC-002 Message Confidentiality, Integrity and Authenticity: DOTS protocols MUST take steps to protect the confidentiality, integrity and authenticity of messages sent between client and server. While specific transport- and message-level security options are not specified, the protocols MUST follow current industry best practices for encryption and message authentication. + Client-domain DOTS gateways are more trusted than DOTS clients, + while server-domain DOTS gateways and DOTS servers share the same + level of trust. A security mechanism at the network layer (e.g., + TLS) is thus adequate to provide hop-by-hop security. In other + words, end-to-end security is not required for DOTS protocols. In order for DOTS protocols to remain secure despite advancements in cryptanalysis and traffic analysis, DOTS agents MUST support secure negotiation of the terms and mechanisms of protocol security, subject to the interoperability and signal message size requirements in Section 2.2. 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 @@ -709,47 +717,48 @@ represent data model versions is not defined in this document. DM-003 Mitigation Status Representation: The data model MUST provide the ability to represent a request for mitigation and the withdrawal of such a request. The data model MUST also support a representation of currently requested mitigation status, including failures and their causes. DM-004 Mitigation Scope Representation: The data model MUST support representation of a requested mitigation's scope. As mitigation - scope may be represented in several different ways, per SIG-007 + scope may be represented in several different ways, per SIG-008 above, the data model MUST include extensible representation of mitigation scope. DM-005 Mitigation Lifetime Representation: The data model MUST support representation of a mitigation request's lifetime, including mitigations with no specified end time. DM-006 Mitigation Efficacy Representation: The data model MUST support representation of a DOTS client's understanding of the efficacy of a mitigation enabled through a mitigation request. DM-007 Acceptable Signal Loss Representation: The data model MUST be able to represent the DOTS agent's preference for acceptable - signal loss when establishing a signal channel, as described in - GEN-002. Measurements of loss might include, but are not - restricted to, number of consecutive missed heartbeat messages, - retransmission count, or request timeouts. + signal loss when establishing a signal channel. Measurements of + loss might include, but are not restricted to, number of + consecutive missed heartbeat messages, retransmission count, or + request timeouts. DM-008 Heartbeat Interval Representation: The data model MUST be able to represent the DOTS agent's preferred heartbeat interval, which the client may include when establishing the signal channel, as described in SIG-003. - DM-009 Relationship to Transport: The DOTS data model MUST NOT - depend on the specifics of any transport to represent fields in - the model. + DM-009 Relationship to Transport: The DOTS data model MUST NOT make + any assumptions about specific characteristics of any given + transport into the data model, but instead, represent the fields + in the model explicitly. 3. Congestion Control Considerations 3.1. Signal Channel As part of a protocol expected to operate over links affected by DDoS attack traffic, the DOTS signal channel MUST NOT contribute significantly to link congestion. To meet the signal channel requirements above, DOTS signal channel implementations SHOULD support connectionless transports. However, some connectionless @@ -787,27 +796,30 @@ request mitigation. Similarly, an impersonated DOTS server may be able to act as a sort of malicious DOTS gateway, intercepting requests from the downstream DOTS client, and modifying them before transmission to the DOTS server to inflict the desired impact on traffic to or from the DOTS client's domain. Among other things, this malicious DOTS gateway might receive and discard mitigation requests from the DOTS client, ensuring no requested mitigation is ever applied. - As detailed in Section 2.4, DOTS implementations require mutual - authentication of DOTS agents in order to make agent impersonation - more difficult. However, impersonation may still be possible as a - result of credential theft, implementation flaws, or compromise of - DOTS agents. To detect misuse, DOTS operators should carefully - monitor and audit DOTS agents, while employing current secure network - communications best practices to reduce attack surface. + To detect misuse, as detailed in Section 2.4, DOTS implementations + require mutual authentication of DOTS agents in order to make agent + impersonation more difficult. However, impersonation may still be + possible as a result of credential theft, implementation flaws, or + compromise of DOTS agents. + + To detect compromised DOTS agents, DOTS operators should carefully + monitor and audit DOTS agents to detect misbehavior and to deter + misuse, while employing current secure network communications best + practices to reduce attack surface. Blocking communication between DOTS agents has the potential to disrupt the core function of DOTS, which is to request mitigation of active or expected DDoS attacks. The DOTS signal channel is expected to operate over congested inbound links, and, as described in Section 2.2, the signal channel protocol must be designed for minimal data transfer to reduce the incidence of signal loss. 5. IANA Considerations @@ -825,22 +837,23 @@ fandreas@cisco.com Dave Dolson Sandvine ddolson@sandvine.com 7. Acknowledgments - Thanks to Roman Danyliw, Matt Richardson, Joe Touch, Scott Bradner - and Jon Shallow for careful reading and feedback. + Thanks to Roman Danyliw, Matt Richardson, Joe Touch, Scott Bradner, + Robert Sparks, Brian Weis, Benjamin Kaduk and Jon Shallow for careful + reading and feedback. 8. References 8.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, @@ -950,26 +963,26 @@ . Authors' Addresses Andrew Mortensen Arbor Networks 2727 S. State St Ann Arbor, MI 48104 United States - Email: amortensen@arbor.net - - Robert Moskowitz - Huawei - Oak Park, MI 42837 - United States - - Email: rgm@htt-consult.com + Email: andrewmortensen@gmail.com Tirumaleswar Reddy McAfee Embassy Golf Link Business Park Bangalore, Karnataka 560071 India Email: TirumaleswarReddy_Konda@McAfee.com + + Robert Moskowitz + Huawei + Oak Park, MI 42837 + United States + + Email: rgm@htt-consult.com