--- 1/draft-ietf-dots-requirements-19.txt 2019-02-28 22:13:09.414023271 -0800 +++ 2/draft-ietf-dots-requirements-20.txt 2019-02-28 22:13:09.462024436 -0800 @@ -1,21 +1,21 @@ DOTS A. Mortensen Internet-Draft Arbor Networks Intended status: Informational T. Reddy -Expires: August 29, 2019 McAfee +Expires: September 2, 2019 McAfee R. Moskowitz Huawei - February 25, 2019 + March 1, 2019 Distributed Denial of Service (DDoS) Open Threat Signaling Requirements - draft-ietf-dots-requirements-19 + draft-ietf-dots-requirements-20 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 August 29, 2019. + This Internet-Draft will expire on September 2, 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 @@ -352,30 +352,28 @@ signaling Path Maximum Transmission Unit (PMTU), including the byte overhead of any encapsulation, transport headers, and transport- or message-level security. If the total message size exceeds the path MTU, the DOTS agent MUST split the message into separate messages; for example, the list of mitigation scope types could be split into multiple lists and each list conveyed in a new message. 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 the PMTU cannot be discovered, DOTS agents MUST assume a - PMTU of 1280 bytes, as IPv6 requires that every link in the - Internet have an MTU of 1280 octets or greater as specified in - [RFC8200]. If IPv4 support on legacy or otherwise unusual - networks is a consideration and the PMTU is unknown, DOTS - implementations MAY assume on a PMTU of 576 bytes for IPv4 - datagrams, as every IPv4 host must be capable of receiving a - packet whose length is equal to 576 bytes as discussed in - [RFC0791] and [RFC1122]. + be discovered, DOTS agents MUST assume a PMTU of 1280 bytes, as + IPv6 requires that every link in the Internet have an MTU of 1280 + octets or greater as specified in [RFC8200]. If IPv4 support on + legacy or otherwise unusual networks is a consideration and the + PMTU is unknown, DOTS implementations MAY assume on a PMTU of 576 + bytes for IPv4 datagrams, as every IPv4 host must be capable of + receiving a packet whose length is equal to 576 bytes 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. @@ -428,23 +426,22 @@ 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 - target DOTS server MUST be the same as the authentication domain - of the redirecting DOTS server. + target DOTS server. The redirection DOTS server and redirecting + DOTS server MUST belong to the same administrative domain. 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-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