--- 1/draft-ietf-dots-requirements-12.txt 2018-02-07 09:13:34.953146531 -0800 +++ 2/draft-ietf-dots-requirements-13.txt 2018-02-07 09:13:35.089149743 -0800 @@ -1,21 +1,21 @@ DOTS A. Mortensen Internet-Draft Arbor Networks Intended status: Informational R. Moskowitz -Expires: July 29, 2018 Huawei +Expires: August 11, 2018 Huawei T. Reddy - McAfee, Inc. - January 25, 2018 + McAfee + February 07, 2018 Distributed Denial of Service (DDoS) Open Threat Signaling Requirements - draft-ietf-dots-requirements-12 + draft-ietf-dots-requirements-13 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 29, 2018. + This Internet-Draft will expire on August 11, 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 @@ -52,31 +52,31 @@ 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.5. Data Model Requirements . . . . . . . . . . . . . . . . . 14 - 3. Congestion Control Considerations . . . . . . . . . . . . . . 15 - 3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 15 - 3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 15 + 3. Congestion Control Considerations . . . . . . . . . . . . . . 16 + 3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 16 + 3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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. @@ -281,41 +281,50 @@ 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 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 active signal channel, and 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. 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 + 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 black- or white-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 utilizing a reliable transport protocol MUST be used for bulk data exchange. + GEN-004 Mitigation Hinting: DOTS clients may have access to attack + details which can be used to inform mitigation techniques. + Example attack details might include locally collected + fingerprints for an on-going attack, or anticipated or active + attack focal points based on other threat intelligence. DOTS + clients MAY send mitigation hints derived from attack details to + DOTS servers, in the full understanding that the DOTS server MAY + ignore mitigation hints. Mitigation hints MAY be transmitted + across either signal or data channel. DOTS server treatment of + mitigation hints, and how such hints shape mitigation, are + implementation-specific. + + GEN-005 Loop Handling: In specific scenarios, it may be possible for + communication between DOTS agents to loop, for example as a result + of misconfiguration or aggressive caching. Signal and data + channel implementations should be prepared to detect and terminate + such loops to prevent service disruption. + 2.2. Signal Channel Requirements SIG-001 Use of Common Transport Protocols: DOTS MUST operate over common widely deployed and standardized transport protocols. While connectionless transport such as the User Datagram Protocol (UDP) [RFC0768] SHOULD be used for the signal channel, the Transmission Control Protocol (TCP) [RFC0793] MAY be used if necessary due to network policy or middlebox capabilities or configurations. @@ -327,21 +336,30 @@ 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 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 + SIG-003 Bidirectionality: To support peer health detection, to + maintain an active signal channel, and 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. Unidirectional messages MUST be supported within the + bidirectional signal channel to allow for unsolicited message + delivery, enabling asynchronous 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. 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 @@ -361,36 +379,36 @@ 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. - SIG-004 Channel Redirection: In order to increase DOTS operational + 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. Due to the increased likelihood of packet loss caused by link congestion during an attack, DOTS servers SHOULD NOT redirect while mitigation is enabled during an active attack against a target in the DOTS client's domain. - SIG-005 Mitigation Requests and Status: Authorized DOTS clients MUST + 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 clients which have requested and been granted mitigation, regardless of client requests for mitigation status. @@ -425,21 +443,21 @@ The initial active-but-terminating period is implementation- and 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 + SIG-007 Mitigation Lifetime: DOTS servers MUST support mitigations 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. @@ -452,21 +470,21 @@ traffic path to the resources for which the DOTS client is requesting protection. DOTS clients MUST be prepared to not be granted mitigations with indefinite lifetimes. DOTS servers MAY refuse mitigations with indefinite lifetimes, for policy reasons. The reasons themselves are out of scope. If the DOTS server does not grant a mitigation request with an indefinite mitigation lifetime, it MUST set the lifetime to a value that is configured locally. That value MUST be returned in a reply to the requesting DOTS client. - SIG-007 Mitigation Scope: DOTS clients MUST indicate desired + SIG-008 Mitigation Scope: DOTS clients MUST indicate desired mitigation scope. The scope type will vary depending on the resources requiring mitigation. All DOTS agent implementations MUST support the following required scope types: * IPv4 prefixes in CIDR notation [RFC4632] * IPv6 prefixes [RFC4291][RFC5952] * Domain names [RFC1035] @@ -496,40 +514,40 @@ 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-008 Mitigation Efficacy: When a mitigation request is active, + SIG-009 Mitigation Efficacy: When a mitigation request is active, DOTS clients SHOULD 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-009 Conflict Detection and Notification: Multiple DOTS clients + 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 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-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] apply to DOTS. Regardless of transport, DOTS protocols MUST follow established best common practices established in BCP 127 for NAT traversal [RFC4787][RFC6888][RFC7857]. @@ -905,16 +924,16 @@ Email: amortensen@arbor.net Robert Moskowitz Huawei Oak Park, MI 42837 United States Email: rgm@htt-consult.com Tirumaleswar Reddy - McAfee, Inc. + McAfee Embassy Golf Link Business Park Bangalore, Karnataka 560071 India Email: TirumaleswarReddy_Konda@McAfee.com