--- 1/draft-ietf-dots-requirements-07.txt 2017-12-05 10:13:11.078740335 -0800 +++ 2/draft-ietf-dots-requirements-08.txt 2017-12-05 10:13:11.126741473 -0800 @@ -1,21 +1,21 @@ DOTS A. Mortensen Internet-Draft Arbor Networks Intended status: Informational R. Moskowitz -Expires: May 3, 2018 Huawei +Expires: June 8, 2018 Huawei T. Reddy McAfee, Inc. - October 30, 2017 + December 05, 2017 Distributed Denial of Service (DDoS) Open Threat Signaling Requirements - draft-ietf-dots-requirements-07 + draft-ietf-dots-requirements-08 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,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 May 3, 2018. + This Internet-Draft will expire on June 8, 2018. Copyright Notice Copyright (c) 2017 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 @@ -48,41 +48,34 @@ 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 . . . . . . . . . . . . . . . . . . 7 - 2.2. Signal Channel Requirements . . . . . . . . . . . . . . . 8 + 2.2. Signal Channel Requirements . . . . . . . . . . . . . . . 7 2.3. Data Channel Requirements . . . . . . . . . . . . . . . . 12 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. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 7.1. 04 revision . . . . . . . . . . . . . . . . . . . . . . . 17 - 7.2. 03 revision . . . . . . . . . . . . . . . . . . . . . . . 18 - 7.3. 02 revision . . . . . . . . . . . . . . . . . . . . . . . 18 - 7.4. 01 revision . . . . . . . . . . . . . . . . . . . . . . . 18 - 7.5. 00 revision . . . . . . . . . . . . . . . . . . . . . . . 19 - 7.6. Initial revision . . . . . . . . . . . . . . . . . . . . 19 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 - 8.2. Informative References . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 + 7.2. Informative References . . . . . . . . . . . . . . . . . 18 + 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. @@ -362,22 +355,23 @@ interval during active mitigation is not specified, but SHOULD be frequent enough to maintain any on-path NAT 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 - delay or cease heartbeat exchanges when an active DOTS client has - not requested mitigation, in order to control load. + 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 timeout period has elapsed. 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. DOTS servers SHOULD monitor @@ -782,106 +776,23 @@ Dave Dolson Sandvine ddolson@sandvine.com 6. Acknowledgments Thanks to Roman Danyliw and Matt Richardson for careful reading and feedback. -7. Change Log - -7.1. 04 revision - - 2017-03-13 - - o Establish required and optional mitigation scope types - - o Specify message size for DOTS signal channel - - o Recast mitigation lifetime as a DOTS server requirement - - o Clarify DOTS server's responsibilities after client request to end - mitigation - - o Specify security state handling on redirection - - o Signal channel should use transport not susceptible to HOL - blocking - - o Expanded list of DDoS types to include network links - -7.2. 03 revision - - 2016-10-30 - - o Extended SEC-003 to require secure interfaces within DOTS - gateways. - - o Changed DATA-003 to Resource Configuration, delegating control of - acceptable signal loss, heartbeat intervals, and mitigation - lifetime to DOTS client. - - o Added data model requirements reflecting client control over the - above. - -7.3. 02 revision - -7.4. 01 revision - - 2016-03-21 - - o Reconciled terminology with -00 revision of - [I-D.ietf-dots-use-cases]. - - o Terminology clarification based on working group feedback. - - o Moved security-related requirements to separate section. - - o Made resilience/robustness primary general requirement to align - with charter. - - o Clarified support for unidirectional communication within the - bidirectional signal channel. - - o Added proposed operational requirement to support session - redirection. - - o Added proposed operational requirement to support conflict - notification. - - o Added proposed operational requirement to support mitigation - lifetime in mitigation requests. - - o Added proposed operational requirement to support mitigation - efficacy reporting from DOTS clients. - - o Added proposed operational requirement to cache lookups of all - kinds. - - o Added proposed operational requirement regarding NAT traversal. - - o Removed redundant mutual authentication requirement from data - channel requirements. - -7.5. 00 revision - - 2015-10-15 - -7.6. Initial revision - - 2015-09-24 Andrew Mortensen - -8. References +7. References -8.1. Normative References +7.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, @@ -931,34 +842,34 @@ [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, . -8.2. Informative References +7.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-04 (work in progress), July 2017. + architecture-05 (work in progress), October 2017. [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-07 (work - in progress), July 2017. + Open Threat Signaling", draft-ietf-dots-use-cases-09 (work + in progress), November 2017. [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,