--- 1/draft-ietf-dots-requirements-20.txt 2019-03-08 22:13:33.768089472 -0800 +++ 2/draft-ietf-dots-requirements-21.txt 2019-03-08 22:13:33.892092493 -0800 @@ -1,21 +1,21 @@ DOTS A. Mortensen Internet-Draft Arbor Networks Intended status: Informational T. Reddy -Expires: September 2, 2019 McAfee +Expires: September 10, 2019 McAfee R. Moskowitz Huawei - March 1, 2019 + March 9, 2019 Distributed Denial of Service (DDoS) Open Threat Signaling Requirements - draft-ietf-dots-requirements-20 + draft-ietf-dots-requirements-21 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 September 2, 2019. + This Internet-Draft will expire on September 10, 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 @@ -445,21 +445,21 @@ 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. DOTS servers MUST regularly send mitigation status updates to authorized DOTS clients which have requested and been granted mitigation. If unreliable transport is used for the signal channel protocol, due to the higher likelihood of packet loss - during a DDoS attack, DOTS servers MUST send mitigation status + during a DDoS attack, DOTS servers needs to send mitigation status multiple times at regular intervals following the the data transmission guidelines discussed in Section 3.1.3 of [RFC8085]. When DOTS client-requested mitigation is active, DOTS server status messages MUST include the following mitigation metrics: * Total number of packets blocked by the mitigation * Current number of packets per second blocked @@ -640,30 +640,30 @@ 2.4. Security Requirements DOTS must operate within a particularly strict security context, as an insufficiently protected signal or data channel may be subject to abuse, enabling or supplementing the very attacks DOTS purports to mitigate. SEC-001 Peer Mutual Authentication: DOTS agents MUST authenticate each other before a DOTS signal or data channel is considered valid. The method of authentication is not specified in this - document, but should follow current IETF best practices (like - [RFC7525]) with respect to any cryptographic mechanisms to - authenticate the remote peer. + document, but should follow current IETF best practices [RFC7525] + 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 IETF - best practices (like [RFC7525]) for encryption and message + best practices [RFC7525] 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 transport layer (e.g., TLS) is thus adequate to provide security between peer DOTS agents. 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 @@ -940,21 +940,21 @@ (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 8.2. Informative References [I-D.ietf-dots-architecture] 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-11 + (DOTS) Architecture", draft-ietf-dots-architecture-12 (work in progress), February 2019. [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-17 (work in progress), January 2019. [I-D.ietf-intarea-frag-fragile] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,