draft-ietf-dots-requirements-19.txt   draft-ietf-dots-requirements-20.txt 
DOTS A. Mortensen DOTS A. Mortensen
Internet-Draft Arbor Networks Internet-Draft Arbor Networks
Intended status: Informational T. Reddy Intended status: Informational T. Reddy
Expires: August 29, 2019 McAfee Expires: September 2, 2019 McAfee
R. Moskowitz R. Moskowitz
Huawei Huawei
February 25, 2019 March 1, 2019
Distributed Denial of Service (DDoS) Open Threat Signaling Requirements Distributed Denial of Service (DDoS) Open Threat Signaling Requirements
draft-ietf-dots-requirements-19 draft-ietf-dots-requirements-20
Abstract Abstract
This document defines the requirements for the Distributed Denial of This document defines the requirements for the Distributed Denial of
Service (DDoS) Open Threat Signaling (DOTS) protocols enabling Service (DDoS) Open Threat Signaling (DOTS) protocols enabling
coordinated response to DDoS attacks. coordinated response to DDoS attacks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 8, line 34 skipping to change at page 8, line 34
signaling Path Maximum Transmission Unit (PMTU), including the signaling Path Maximum Transmission Unit (PMTU), including the
byte overhead of any encapsulation, transport headers, and byte overhead of any encapsulation, transport headers, and
transport- or message-level security. If the total message size transport- or message-level security. If the total message size
exceeds the path MTU, the DOTS agent MUST split the message into exceeds the path MTU, the DOTS agent MUST split the message into
separate messages; for example, the list of mitigation scope types separate messages; for example, the list of mitigation scope types
could be split into multiple lists and each list conveyed in a new could be split into multiple lists and each list conveyed in a new
message. message.
DOTS agents can attempt to learn PMTU using the procedures DOTS agents can attempt to learn PMTU using the procedures
discussed in [I-D.ietf-intarea-frag-fragile]. If the PMTU cannot discussed in [I-D.ietf-intarea-frag-fragile]. If the PMTU cannot
be discovered, DOTS agents MUST assume a PMTU of 1280 bytes for be discovered, DOTS agents MUST assume a PMTU of 1280 bytes, as
IPv6. If the PMTU cannot be discovered, DOTS agents MUST assume a IPv6 requires that every link in the Internet have an MTU of 1280
PMTU of 1280 bytes, as IPv6 requires that every link in the octets or greater as specified in [RFC8200]. If IPv4 support on
Internet have an MTU of 1280 octets or greater as specified in legacy or otherwise unusual networks is a consideration and the
[RFC8200]. If IPv4 support on legacy or otherwise unusual PMTU is unknown, DOTS implementations MAY assume on a PMTU of 576
networks is a consideration and the PMTU is unknown, DOTS bytes for IPv4 datagrams, as every IPv4 host must be capable of
implementations MAY assume on a PMTU of 576 bytes for IPv4 receiving a packet whose length is equal to 576 bytes as discussed
datagrams, as every IPv4 host must be capable of receiving a in [RFC0791] and [RFC1122].
packet whose length is equal to 576 bytes as discussed in
[RFC0791] and [RFC1122].
SIG-003 Bidirectionality: To support peer health detection, to SIG-003 Bidirectionality: To support peer health detection, to
maintain an active signal channel, and to increase the probability maintain an active signal channel, and to increase the probability
of signal delivery during an attack, the signal channel MUST be of signal delivery during an attack, the signal channel MUST be
bidirectional, with client and server transmitting signals to each bidirectional, with client and server transmitting signals to each
other at regular intervals, regardless of any client request for other at regular intervals, regardless of any client request for
mitigation. The bidirectional signal channel MUST support mitigation. The bidirectional signal channel MUST support
unidirectional messaging to enable notifications between DOTS unidirectional messaging to enable notifications between DOTS
agents. agents.
skipping to change at page 10, line 15 skipping to change at page 10, line 15
defunct. defunct.
SIG-005 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 flexibility and scalability, DOTS servers SHOULD be able to
redirect DOTS clients to another DOTS server at any time. DOTS redirect DOTS clients to another DOTS server at any time. DOTS
clients MUST NOT assume the redirection target DOTS server shares clients MUST NOT assume the redirection target DOTS server shares
security state with the redirecting DOTS server. DOTS clients are security state with the redirecting DOTS server. DOTS clients are
free to attempt abbreviated security negotiation methods supported free to attempt abbreviated security negotiation methods supported
by the protocol, such as DTLS session resumption, but MUST be by the protocol, such as DTLS session resumption, but MUST be
prepared to negotiate new security state with the redirection prepared to negotiate new security state with the redirection
target DOTS server. The authentication domain of the redirection target DOTS server. The redirection DOTS server and redirecting
target DOTS server MUST be the same as the authentication domain DOTS server MUST belong to the same administrative domain.
of the redirecting DOTS server.
Due to the increased likelihood of packet loss caused by link Due to the increased likelihood of packet loss caused by link
congestion during an attack, DOTS servers SHOULD NOT redirect congestion during an attack, DOTS servers SHOULD NOT redirect
while mitigation is enabled during an active attack against a while mitigation is enabled during an active attack against a
target in the DOTS client's domain. target in the DOTS client's domain.
SIG-006 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 be able to request scoped mitigation from DOTS servers. DOTS
servers MUST send status to the DOTS clients about mitigation servers MUST send status to the DOTS clients about mitigation
requests. If a DOTS server rejects an authorized request for requests. If a DOTS server rejects an authorized request for
 End of changes. 6 change blocks. 
17 lines changed or deleted 14 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/