--- 1/draft-ietf-dots-requirements-16.txt 2019-01-30 23:13:10.131009729 -0800 +++ 2/draft-ietf-dots-requirements-17.txt 2019-01-30 23:13:10.179010893 -0800 @@ -1,21 +1,21 @@ DOTS A. Mortensen Internet-Draft Arbor Networks Intended status: Informational R. Moskowitz -Expires: April 25, 2019 Huawei +Expires: August 4, 2019 Huawei T. Reddy McAfee - October 22, 2018 + January 31, 2019 Distributed Denial of Service (DDoS) Open Threat Signaling Requirements - draft-ietf-dots-requirements-16 + draft-ietf-dots-requirements-17 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,59 +24,59 @@ 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 April 25, 2019. + This Internet-Draft will expire on August 4, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + 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 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Context and Motivation . . . . . . . . . . . . . . . . . 2 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 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.2. Signal Channel Requirements . . . . . . . . . . . . . . . 8 + 2.3. Data Channel Requirements . . . . . . . . . . . . . . . . 13 + 2.4. Security Requirements . . . . . . . . . . . . . . . . . . 14 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 + 3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 17 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 - 8.2. Informative References . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 + 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. @@ -209,22 +209,25 @@ 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 - This section describes the required features and characteristics of - the DOTS protocols. + 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 @@ -273,31 +275,37 @@ 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 SHOULD ignore information added to DOTS messages as part - of newer protocol versions. + 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. 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. + 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 + over transport and application protocols not susceptible to Head + of Line Blocking. These requirements are at SHOULD strength to + handle middle-boxes and firewall traversal. GEN-003 Bulk Data Exchange: Infrequent bulk data exchange between DOTS agents can also significantly augment attack response coordination, permitting such tasks as population of drop- or accept-listed source addresses; address or prefix group aliasing; exchange of incident reports; and other hinting or configuration supplementing attack response. As the resilience requirements for the DOTS signal channel mandate small signal message size, a separate, secure data channel @@ -333,70 +341,81 @@ necessary due to network policy or middlebox capabilities or configurations. SIG-002 Sub-MTU Message Size: To avoid message fragmentation and the consequently decreased probability of message delivery over a congested link, signaling protocol message size MUST be kept under signaling Path Maximum Transmission Unit (PMTU), including the byte overhead of any encapsulation, transport headers, and transport- or message-level security. - DOTS agents SHOULD attempt to learn the PMTU through mechanisms - such as Path MTU Discovery [RFC1191] or Packetization Layer Path - MTU Discovery [RFC4821]. If the PMTU cannot be discovered, DOTS - agents SHOULD assume a PMTU of 1280 bytes. If IPv4 support on - legacy or otherwise unusual networks is a consideration and the - PMTU is unknown, DOTS implementations MAY rely on a PMTU of 576 - bytes, as discussed in [RFC0791] and [RFC1122]. + DOTS agents can attempt to learn PMTU using the procedures + discussed in [I-D.ietf-intarea-frag-fragile]. If the PMTU cannot + be discovered, DOTS agents MUST assume a PMTU of 1280 bytes for + IPv6. If IPv4 support on legacy or otherwise unusual networks is + a consideration and the PMTU is unknown, DOTS implementations MAY + rely on a PMTU of 576 bytes for IPv4 datagrams, as discussed in + [RFC0791] and [RFC1122]. SIG-003 Bidirectionality: To support peer health detection, to maintain an active signal channel, and to increase the probability 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. The bidirectional signal channel MUST support unidirectional messaging to enable notifications between DOTS agents. SIG-004 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 could be negotiable, but SHOULD - be frequent enough to maintain any on-path NAT or Firewall - bindings during mitigation. + health. The heartbeat interval during active mitigation could be + negotiable, but MUST be frequent enough to maintain any on-path + NAT or Firewall bindings during mitigation. When TCP is used as + transport, the DOTS signal channel heartbeat messages need to be + frequent enough to maintain the TCP connection state. To support scenarios in which loss of heartbeat is used to trigger - mitigation, and to keep the channel active, DOTS clients MAY + mitigation, and to keep the channel active, DOTS server MUST 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. 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 alive. DOTS servers are assumed - to have the ability to 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. + considered active until a DOTS agent explicitly ends the session. + During peace time, signal channel MUST be considered active until + either DOTS agent fails to receive heartbeats from the other after + a mutually agreed upon retransmission procedure has been + exhausted. Peer DOTS agents MUST regularly send heartbeats to + each other while a mitigation request is active. 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. The exception circumstances to terminate the + signal channel session during active mitigation are discussed + below: + + * To handle possible DOTS server restart or crash, the DOTS + clients MAY attempt to establish a new signal channel session, + but MUST continue to send heartbeats on the current session so + that the DOTS server knows the session is still alive. If the + new session is successfully established, the DOTS client can + terminate the current session. + + * DOTS servers are assumed to have the ability to 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-005 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 are free to 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. The authentication domain of the redirection @@ -409,34 +428,35 @@ target in the DOTS client's domain. SIG-006 Mitigation Requests and Status: Authorized DOTS clients MUST be able to request scoped mitigation from DOTS servers. DOTS servers MUST send status to the DOTS clients about mitigation requests. If a DOTS server rejects an authorized request for mitigation, the DOTS server MUST include a reason for the rejection in the status message sent to the client. Due to the higher likelihood of packet loss during a DDoS attack, - DOTS servers SHOULD regularly send mitigation status to authorized + DOTS servers MUST regularly send mitigation status to authorized DOTS clients which have requested and been granted mitigation, regardless of client requests for mitigation status. When DOTS client-requested mitigation is active, DOTS server - status messages SHOULD include the following mitigation metrics: + status messages MUST include the following mitigation metrics: * Total number of packets blocked by the mitigation * Current number of packets per second blocked * Total number of bytes blocked * Current number of bytes per second blocked + DOTS clients MAY take these metrics into account when determining whether to ask the DOTS server to cease mitigation. A DOTS client MAY withdraw a mitigation request at any time, regardless of whether mitigation is currently active. The DOTS server MUST immediately acknowledge a DOTS client's request to stop mitigation. To protect against route or DNS flapping caused by a client rapidly toggling mitigation, and to dampen the effect of @@ -525,35 +545,35 @@ As an active attack evolves, DOTS clients MUST be able to adjust as necessary the scope of requested mitigation by refining the scope of resources requiring mitigation. A DOTS client may obtain the mitigation scope through direct provisioning or through implementation-specific methods of discovery. DOTS clients MUST support at least one mechanism to obtain mitigation scope. SIG-009 Mitigation Efficacy: When a mitigation request is active, - DOTS clients SHOULD transmit a metric of perceived mitigation + DOTS clients MUST transmit a metric of perceived mitigation efficacy to the DOTS server. DOTS servers MAY use the efficacy metric to adjust countermeasures activated on a mitigator on behalf of a DOTS client. SIG-010 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests as a result of misconfiguration, operator 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 + clients in conflict. The notification MUST indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. SIG-011 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] @@ -579,26 +599,26 @@ DATA-001 Reliable transport: Messages sent over the data channel MUST be delivered reliably, in order sent. DATA-002 Data privacy and integrity: Transmissions over the data channel are likely to contain operationally or privacy-sensitive information or instructions from the remote DOTS agent. Theft, modification, or replay of data channel transmissions could lead to information leaks or malicious transactions on behalf of the sending agent (see Section 4 below). Consequently data sent over - the data channel MUST be encrypted and authenticated using current - IETF best practices. DOTS servers MUST enable means to prevent - leaking operationally or privacy-sensitive data. Although - administrative entities participating in DOTS may detail what data - may be revealed to third-party DOTS agents, such considerations - are not in scope for this document. + the data channel MUST be encrypted using a secure transport (like + TLS). DOTS servers MUST enable means to prevent leaking + operationally or privacy-sensitive data. Although administrative + entities participating in DOTS may detail what data may be + revealed to third-party DOTS agents, such considerations are not + in scope for this document. DATA-003 Resource Configuration: To help meet the general and signal channel requirements in Section 2.1 and Section 2.2, DOTS server implementations MUST provide an interface to configure resource identifiers, as described in SIG-008. DOTS server implementations MAY expose additional configurability. Additional configurability is implementation-specific. DATA-004 Policy management: DOTS servers MUST provide methods for DOTS clients to manage drop- and accept-lists of traffic destined @@ -731,29 +751,30 @@ 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 [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. + Signal channel implementations using a IETF standard congestion- + controlled transport protocol (like TCP) may rely on built-in + transport 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. + order message delivery. Data channel implementations using a IETF + standard congestion-controlled transport protocol may rely on the + transport implementation's built-in congestion control mechanisms. 4. Security Considerations This document informs future protocols under development, and so does 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. @@ -804,22 +825,22 @@ fandreas@cisco.com Dave Dolson Sandvine ddolson@sandvine.com 7. Acknowledgments - Thanks to Roman Danyliw, Matt Richardson, and Jon Shallow for careful - reading and feedback. + Thanks to Roman Danyliw, Matt Richardson, Joe Touch, Scott Bradner + 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, @@ -832,24 +853,20 @@ [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . - [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, - DOI 10.17487/RFC1191, November 1990, - . - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . @@ -860,24 +877,20 @@ [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, . [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, - . - [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . [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, . @@ -891,31 +904,37 @@ Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [I-D.ietf-dots-architecture] - Mortensen, A., Andreasen, F., K, R., - christopher_gray3@cable.comcast.com, c., Compton, R., and - N. Teague, "Distributed-Denial-of-Service Open Threat - Signaling (DOTS) Architecture", draft-ietf-dots- - architecture-07 (work in progress), September 2018. + Mortensen, A., Andreasen, F., K, R., Teague, N., Compton, + R., and c. christopher_gray3@cable.comcast.com, + "Distributed-Denial-of-Service Open Threat Signaling + (DOTS) Architecture", draft-ietf-dots-architecture-10 + (work in progress), December 2018. [I-D.ietf-dots-use-cases] Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS - Open Threat Signaling", draft-ietf-dots-use-cases-16 (work - in progress), July 2018. + Open Threat Signaling", draft-ietf-dots-use-cases-17 (work + in progress), January 2019. + + [I-D.ietf-intarea-frag-fragile] + Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., + and F. Gont, "IP Fragmentation Considered Fragile", draft- + ietf-intarea-frag-fragile-08 (work in progress), January + 2019. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013,