--- 1/draft-ietf-dots-requirements-11.txt 2018-01-25 13:13:15.990748168 -0800 +++ 2/draft-ietf-dots-requirements-12.txt 2018-01-25 13:13:16.034749213 -0800 @@ -1,21 +1,21 @@ DOTS A. Mortensen Internet-Draft Arbor Networks Intended status: Informational R. Moskowitz -Expires: July 27, 2018 Huawei +Expires: July 29, 2018 Huawei T. Reddy McAfee, Inc. - January 23, 2018 + January 25, 2018 Distributed Denial of Service (DDoS) Open Threat Signaling Requirements - draft-ietf-dots-requirements-11 + draft-ietf-dots-requirements-12 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 July 27, 2018. + This Internet-Draft will expire on July 29, 2018. Copyright Notice 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 @@ -56,26 +56,27 @@ 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. General Requirements . . . . . . . . . . . . . . . . . . 6 2.2. Signal Channel Requirements . . . . . . . . . . . . . . . 7 2.3. Data Channel Requirements . . . . . . . . . . . . . . . . 12 2.4. Security Requirements . . . . . . . . . . . . . . . . . . 13 2.5. Data Model Requirements . . . . . . . . . . . . . . . . . 14 3. Congestion Control Considerations . . . . . . . . . . . . . . 15 3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 15 3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 - 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 7.2. Informative References . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 + 8.2. Informative References . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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. @@ -239,37 +240,37 @@ 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 which a mitigation request is to be sent. The method for selecting the appropriate DOTS server in a multi-homed environment is out of scope. DOTS protocol implementations face competing operational goals when maintaining this bidirectional communication stream. On the one hand, DOTS must include protections ensuring message confidentiality, integrity and authenticity to keep the protocols from becoming - additional vectors for the very attadcks it is meant to help fight + additional vectors for the very attacks it is meant to help fight off. On the other hand, the protocol must be resilient under extremely hostile network conditions, providing continued contact between DOTS agents even as attack traffic saturates the link. Such resiliency may be developed several ways, but characteristics such as small message size, asynchronous, redundant message delivery and minimal connection overhead (when possible given local network policy) will tend to contribute to the robustness demanded by a viable DOTS protocol. Operators of peer DOTS-enabled domains may enable quality- or class-of-service traffic tagging to increase the probability of successful DOTS signal delivery, but DOTS does not require such policies be in place, and should be viable in their absence. The DOTS server and client must also have some standardized method of - defining the scope of any mitigation, and negotiating related - mitigation communication and actions and communications. + defining the scope of any mitigation, as well as managing other + 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 @@ -425,25 +426,25 @@ deployment- specific, but SHOULD be sufficiently long to absorb latency incurred by route propagation. If the client requests mitigation again before the initial active-but-terminating period elapses, the DOTS server MAY exponentially increase the active- but-terminating period up to a maximum of 300 seconds (5 minutes). After the active-but-terminating period elapses, the DOTS server MUST treat the mitigation as terminated, as the DOTS client is no longer responsible for the mitigation. SIG-006 Mitigation Lifetime: DOTS servers MUST support mitigations - for a negotiated time interval or lifetime, and MUST terminate a - mitigation when the lifetime elapses. DOTS servers also MUST - support renewal of mitigation lifetimes in mitigation requests - from DOTS clients, allowing clients to extend mitigation as - necessary for the duration of an attack. + for a negotiated time interval, and MUST terminate a mitigation + when the lifetime elapses. DOTS servers also MUST support renewal + of mitigation lifetimes in mitigation requests from DOTS clients, + allowing clients to extend mitigation as necessary for the + duration of an attack. DOTS servers MUST treat a mitigation terminated due to lifetime expiration exactly as if the DOTS client originating the mitigation had asked to end the mitigation, including the active- but-terminating period, as described above in SIG-005. DOTS clients MUST include a mitigation lifetime in all mitigation requests. DOTS servers SHOULD support indefinite mitigation lifetimes, @@ -514,21 +515,21 @@ error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. - SIG-010: Network Address Translator Traversal: DOTS clients may be + SIG-010 Network Address Translator Traversal: DOTS clients may be deployed behind a Network Address Translator (NAT), and need to communicate with DOTS servers through the NAT. DOTS protocols MUST therefore be capable of traversing NATs. 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 established in BCP 127 for NAT traversal [RFC4787][RFC6888][RFC7857]. @@ -640,162 +641,158 @@ or deletion of scope aliases and black-/white-lists when the DOTS client is unauthorized. The modes of authorization are implementation-specific. 2.5. Data Model Requirements A well-structured DOTS data model is critical to the development of successful DOTS protocols. - DM-001: Structure: The data model structure for the DOTS protocol - MAY be described by a single module, or be divided into related + DM-001 Structure: The data model structure for the DOTS protocol MAY + be described by a single module, or be divided into related collections of hierarchical modules and sub-modules. If the data model structure is split across modules, those distinct modules MUST allow references to describe the overall data model's structural dependencies. - DM-002: Versioning: To ensure interoperability between DOTS protocol + DM-002 Versioning: To ensure interoperability between DOTS protocol implementations, data models MUST be versioned. How the protocols 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 + 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 + 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 above, the data model MUST be capable of flexible representation of mitigation scope. - DM-005: Mitigation Lifetime Representation: The data model MUST + 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 + 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 + 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. - DM-008: Heartbeat Interval Representation: The data model MUST be + 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 + DM-009 Relationship to Transport: The DOTS data model MUST NOT depend on the specifics of any transport to represent fields in the model. 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 transports when deployed naively can be a source of network - congestion, as discussed in [RFC5405]. Signal channel + congestion, as discussed in [RFC8085]. Signal channel implementations using such connectionless transports, such as UDP, therefore MUST include a congestion control mechanism. Signal channel implementations using TCP may rely on built-in TCP congestion control support. 3.2. Data Channel As specified in DATA-001, the data channel requires reliable, in- order message delivery. Data channel implementations using TCP may rely on the TCP implementation's built-in congestion control mechanisms. 4. Security Considerations This document informs future protocols under development, and so does - not have its security considerations of its own. However, naive DOTS - deployment potentially exposes networks to new attack vectors. The - three primary attack vectors are DOTS agent impersonation, traffic - injection, and signal blocking. + not have security considerations of its own. However, operators + should be aware of potential risks involved in deploying DOTS. DOTS + agent impersonation and signal blocking are discussed here. + Additional DOTS security considerations may be found in + [I-D.ietf-dots-architecture] and DOTS protocol documents. Impersonation of either DOTS server or DOTS client could have - catastrophic impact on operations in either domain. Should an - attacker develop the ability to impersonate a DOTS client, that - attacker can affect policy on the network path to the DOTS client's - domain, up to and including instantiation of blacklists blocking all - inbound traffic to networks for which the DOTS client is authorized - to 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, modifying them to inflict - the desired impact on traffic to or from the DOTS client's domain. - Among other things, this malicious DOTS gateway might receive - mitigation requests from the DOTS client, and simply discard them, - ensuring no mitigation is ever applied. - - Traffic injection into a naive DOTS deployment could allow an - attacker to affect DOTS operations selectively. Rather than - impersonating a DOTS agent directly, the attacker crafts DOTS signal - or data channel messages in such a way that the targeted DOTS agent - treats them as if they originated with a legitimate DOTS agent, for - example, by spoofing the sender's IP address. As with agent - impersonation, the attacker capable of injecting traffic can affect - the network path to addresses for which the DOTS client is authorized - to request mitigation. + catastrophic impact on operations in either domain. If an attacker + has the ability to impersonate a DOTS client, that attacker can + affect policy on the network path to the DOTS client's domain, up to + and including instantiation of blacklists blocking all inbound + traffic to networks for which the DOTS client is authorized to + request mitigation. - Blocking communication between DOTS agents-signal blocking-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 - blocking. + 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 - and traffic injection more difficult. However, impersonation or - traffic injection may still be possible as a result of credential - theft, implementation flaws, or compromise of DOTS agents. Operators - should take steps to reduce attack surfaces through current secure - network communications best practices. + 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. -5. Contributors + 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 blocking. + +5. IANA Considerations + + This document does not require any IANA action. + +6. Contributors Mohamed Boucadair Orange mohamed.boucadair@orange.com Flemming Andreasen Cisco Systems, Inc. fandreas@cisco.com Dave Dolson Sandvine ddolson@sandvine.com -6. Acknowledgments +7. Acknowledgments Thanks to Roman Danyliw and Matt Richardson for careful reading and feedback. -7. References +8. References -7.1. Normative 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, DOI 10.17487/RFC0791, September 1981, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, @@ -836,46 +833,41 @@ [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, . [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, . - [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines - for Application Designers", RFC 5405, - DOI 10.17487/RFC5405, November 2008, - . - [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, . [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, S., and K. Naito, "Updates to Network Address Translation (NAT) Behavioral Requirements", BCP 127, RFC 7857, DOI 10.17487/RFC7857, April 2016, . [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . -7.2. Informative References +8.2. Informative References [I-D.ietf-dots-architecture] Mortensen, A., Andreasen, F., Reddy, T., christopher_gray3@cable.comcast.com, c., Compton, R., and N. Teague, "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture", draft-ietf-dots- architecture-05 (work in progress), October 2017. [I-D.ietf-dots-use-cases] Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,