draft-ietf-dots-requirements-03.txt   draft-ietf-dots-requirements-04.txt 
DOTS A. Mortensen DOTS A. Mortensen
Internet-Draft Arbor Networks, Inc. Internet-Draft Arbor Networks, Inc.
Intended status: Informational R. Moskowitz Intended status: Informational R. Moskowitz
Expires: May 3, 2017 HTT Consulting Expires: September 14, 2017 HTT Consulting
T. Reddy T. Reddy
Cisco Systems, Inc. Cisco Systems, Inc.
October 30, 2016 March 13, 2017
Distributed Denial of Service (DDoS) Open Threat Signaling Requirements Distributed Denial of Service (DDoS) Open Threat Signaling Requirements
draft-ietf-dots-requirements-03 draft-ietf-dots-requirements-04
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 coordinating Service (DDoS) Open Threat Signaling (DOTS) protocols coordinating
attack response against DDoS attacks. attack response against 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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 May 3, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Context and Motivation . . . . . . . . . . . . . . . . . 2 1.1. Context and Motivation . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. General Requirements . . . . . . . . . . . . . . . . . . 7 2.1. General Requirements . . . . . . . . . . . . . . . . . . 7
2.2. Operational Requirements . . . . . . . . . . . . . . . . 7 2.2. Operational Requirements . . . . . . . . . . . . . . . . 8
2.3. Data Channel Requirements . . . . . . . . . . . . . . . . 10 2.3. Data Channel Requirements . . . . . . . . . . . . . . . . 11
2.4. Security requirements . . . . . . . . . . . . . . . . . . 11 2.4. Security requirements . . . . . . . . . . . . . . . . . . 12
2.5. Data Model Requirements . . . . . . . . . . . . . . . . . 12 2.5. Data Model Requirements . . . . . . . . . . . . . . . . . 13
3. Congestion Control Considerations . . . . . . . . . . . . . . 13 3. Congestion Control Considerations . . . . . . . . . . . . . . 14
3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 13 3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 14
3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. 03 revision . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. 04 revision . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. 02 revision . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. 03 revision . . . . . . . . . . . . . . . . . . . . . . . 16
7.3. 01 revision . . . . . . . . . . . . . . . . . . . . . . . 15 7.3. 02 revision . . . . . . . . . . . . . . . . . . . . . . . 16
7.4. 00 revision . . . . . . . . . . . . . . . . . . . . . . . 16 7.4. 01 revision . . . . . . . . . . . . . . . . . . . . . . . 16
7.5. Initial revision . . . . . . . . . . . . . . . . . . . . 16 7.5. 00 revision . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.6. Initial revision . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
1.1. Context and Motivation 1.1. Context and Motivation
Distributed Denial of Service (DDoS) attacks continue to plague Distributed Denial of Service (DDoS) attacks continue to plague
networks around the globe, from Tier-1 service providers on down to networks around the globe, from Tier-1 service providers on down to
enterprises and small businesses. Attack scale and frequency enterprises and small businesses. Attack scale and frequency
similarly have continued to increase, in part as a result of software similarly have continued to increase, in part as a result of software
vulnerabilities leading to reflection and amplification attacks. vulnerabilities leading to reflection and amplification attacks.
Once staggering attack traffic volume is now the norm, and the impact Once-staggering attack traffic volume is now the norm, and the impact
of larger-scale attacks attract the attention of international press of larger-scale attacks attract the attention of international press
agencies. agencies.
The greater impact of contemporary DDoS attacks has led to increased The greater impact of contemporary DDoS attacks has led to increased
focus on coordinated attack response. Many institutions and focus on coordinated attack response. Many institutions and
enterprises lack the resources or expertise to operate on-premise enterprises lack the resources or expertise to operate on-premise
attack mitigation solutions themselves, or simply find themselves attack mitigation solutions themselves, or simply find themselves
constrained by local bandwidth limitations. To address such gaps, constrained by local bandwidth limitations. To address such gaps,
security service providers have begun to offer on-demand traffic security service providers have begun to offer on-demand traffic
scrubbing services, which aim to separate the DDoS traffic from scrubbing services, which aim to separate the DDoS traffic from
skipping to change at page 3, line 50 skipping to change at page 3, line 51
DDoS: A distributed denial-of-service attack, in which traffic DDoS: A distributed denial-of-service attack, in which traffic
originating from multiple sources are directed at a target on a originating from multiple sources are directed at a target on a
network. DDoS attacks are intended to cause a negative impact on network. DDoS attacks are intended to cause a negative impact on
the availability of servers, services, applications, and/or other the availability of servers, services, applications, and/or other
functionality of an attack target. Denial-of-service functionality of an attack target. Denial-of-service
considerations are discussed in detail in [RFC4732]. considerations are discussed in detail in [RFC4732].
DDoS attack target: A network connected entity with a finite set of DDoS attack target: A network connected entity with a finite set of
resources, such as network bandwidth, memory or CPU, that is the resources, such as network bandwidth, memory or CPU, that is the
focus of a DDoS attack. Potential targets include network focus of a DDoS attack. Potential targets include network
elements, servers, and services. elements, network links, servers, and services.
DDoS attack telemetry: Collected behavioral characteristics defining DDoS attack telemetry: Collected measurements and behavioral
the nature of a DDoS attack. characteristics defining the nature of a DDoS attack.
Countermeasure: An action or set of actions taken to recognize and Countermeasure: An action or set of actions taken to recognize and
filter out DDoS attack traffic while passing legitimate traffic to filter out DDoS attack traffic while passing legitimate traffic to
the attack target. the attack target.
Mitigation: A set of countermeasures enforced against traffic Mitigation: A set of countermeasures enforced against traffic
destined for the target or targets of a detected or reported DDoS destined for the target or targets of a detected or reported DDoS
attack, where countermeasure enforcement is managed by an entity attack, where countermeasure enforcement is managed by an entity
in the network path between attack sources and the attack target. in the network path between attack sources and the attack target.
Mitigation methodology is out of scope for this document. Mitigation methodology is out of scope for this document.
skipping to change at page 7, line 17 skipping to change at page 7, line 17
GEN-001 Extensibility: Protocols and data models developed as part GEN-001 Extensibility: Protocols and data models developed as part
of DOTS MUST be extensible in order to keep DOTS adaptable to of DOTS MUST be extensible in order to keep DOTS adaptable to
operational and proprietary DDoS defenses. Future extensions MUST operational and proprietary DDoS defenses. Future extensions MUST
be backward compatible. be backward compatible.
GEN-002 Resilience and Robustness: The signaling protocol MUST be GEN-002 Resilience and Robustness: The signaling protocol MUST be
designed to maximize the probability of signal delivery even under designed to maximize the probability of signal delivery even under
the severely constrained network conditions imposed by particular the severely constrained network conditions imposed by particular
attack traffic. The protocol MUST be resilient, that is, continue attack traffic. The protocol MUST be resilient, that is, continue
operating despite message loss and out-of-order or redundant operating despite message loss and out-of-order or redundant
message delivery. message delivery. In support 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 GEN-003 Bidirectionality: To support peer health detection, to
maintain an open signal channel, and to increase the probability maintain an open signal channel, and to increase the probability
of signal delivery during attack, the signal channel MUST be of signal delivery during 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. Unidirectional messages MUST be supported within the mitigation. Unidirectional messages MUST be supported within the
bidirectional signal channel to allow for unsolicited message bidirectional signal channel to allow for unsolicited message
delivery, enabling asynchronous notifications between agents. delivery, enabling asynchronous notifications between agents.
GEN-004 Sub-MTU Message Size: To avoid message fragmentation and the GEN-004 Sub-MTU Message Size: To avoid message fragmentation and the
consequently decreased probability of message delivery, signaling consequently decreased probability of message delivery, signaling
protocol message size MUST be kept under signaling path Maximum protocol message size MUST be kept under signaling Path Maximum
Transmission Unit (MTU), including the byte overhead of any Transmission Unit (PMTU), including the byte overhead of any
encapsulation, transport headers, and transport- or message-level encapsulation, transport headers, and transport- or message-level
security. 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].
GEN-005 Bulk Data Exchange: Infrequent bulk data exchange between GEN-005 Bulk Data Exchange: Infrequent bulk data exchange between
DOTS agents can also significantly augment attack response DOTS agents can also significantly augment attack response
coordination, permitting such tasks as population of black- or coordination, permitting such tasks as population of black- or
white-listed source addresses; address or prefix group aliasing; white-listed source addresses; address or prefix group aliasing;
exchange of incident reports; and other hinting or configuration exchange of incident reports; and other hinting or configuration
supplementing attack response. supplementing attack response.
As the resilience requirements for the DOTS signal channel mandate As the resilience requirements for the DOTS signal channel mandate
small signal message size, a separate, secure data channel small signal message size, a separate, secure data channel
utilizing a reliable transport protocol MUST be used for bulk data utilizing a reliable transport protocol MUST be used for bulk data
skipping to change at page 8, line 18 skipping to change at page 8, line 29
OP-002 Session Health Monitoring: Peer DOTS agents MUST regularly OP-002 Session Health Monitoring: Peer DOTS agents MUST regularly
send heartbeats to each other after mutual authentication in order send heartbeats to each other after mutual authentication in order
to keep the DOTS session active. A session MUST be considered to keep the DOTS session active. A session MUST be considered
active until a DOTS agent explicitly ends the session, or either active until a DOTS agent explicitly ends the session, or either
DOTS agent fails to receive heartbeats from the other after a DOTS agent fails to receive heartbeats from the other after a
mutually agreed upon timeout period has elapsed. mutually agreed upon timeout period has elapsed.
OP-003 Session Redirection: In order to increase DOTS operational OP-003 Session 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. Due to redirect DOTS clients to another DOTS server at any time. DOTS
the decreased probability of DOTS server signal delivery due to clients MUST NOT assume the redirection target DOTS server shares
link congestion, it is RECOMMENDED DOTS servers avoid redirecting security state with the redirecting DOTS server. DOTS clients MAY
while mitigation is enabled during an active attack against a attempt abbreviated security negotiation methods supported by the
target in the DOTS client's domain. Either the DOTS servers have protocol, such as DTLS session resumption, but MUST be prepared to
to fate-share the security state, the client MUST have separate negotiate new security state with the redirection target DOTS
security state with each potential redirectable server, or be able server.
to negotiate new state as part of redirection.
OP-004 Mitigation Status: DOTS MUST provide a means to report the Due to the increased likelihood of packet loss caused by link
status of an action requested by a DOTS client. In particular, congestion during an attack, it is RECOMMENDED DOTS servers avoid
DOTS clients MUST be able to request or withdraw a request for redirecting while mitigation is enabled during an active attack
mitigation from the DOTS server. The DOTS server MUST acknowledge against a target in the DOTS client's domain.
a DOTS client's request to withdraw from coordinated attack
response in subsequent signals, and MUST cease mitigation activity
as quickly as possible. However, a DOTS client rapidly toggling
active mitigation may result in undesirable side-effects for the
network path, such as route or DNS [RFC1034] flapping. A DOTS
server therefore MAY continue mitigating for a mutually negotiated
period after receiving the DOTS client's request to stop.
A server MAY refuse to engage in coordinated attack response with OP-004 Mitigation Requests and Status: Authorized DOTS clients MUST
a client. To make the status of a client's request clear, the be able to request scoped mitigation from DOTS servers. DOTS
server MUST indicate in server signals whether client-initiated servers MUST send mitigation request status in response to DOTS
mitigation is active. When a client-initiated mitigation is clients requests for mitigation, and SHOULD accept scoped
active, and threat handling details such as mitigation scope and mitigation requests from authorized DOTS clients. DOTS servers
statistics are available to the server, the server SHOULD include MAY reject authorized requests for mitigation, but MUST include a
those details in server signals sent to the client. DOTS clients reason for the rejection in the status message sent to the client.
SHOULD take mitigation statistics into account when deciding
whether to request the DOTS server cease mitigation.
OP-005 Mitigation Lifetime: A DOTS client SHOULD indicate the Due to the higher likelihood of packet loss during a DDoS attack,
desired lifetime of any mitigation requested from the DOTS server. DOTS servers SHOULD regularly send mitigation status to authorized
As DDoS attack duration is unpredictable, the DOTS client SHOULD DOTS clients which have requested and been granted mitigation,
be able to extend mitigation lifetime with periodic renewed regardless of client requests for mitigation status.
requests for help. When the mitigation lifetime comes to an end,
the DOTS server SHOULD delay session termination for a protocol-
defined grace period to allow for delivery of delayed mitigation
renewals over the signal channel. After the grace period elapses,
the DOTS server MAY terminate the session at any time.
If a DOTS client does not include a mitigation lifetime in When DOTS client-requested mitigation is active, DOTS server
requests for help sent to the DOTS server, the DOTS server will status messages SHOULD include the following mitigation metrics:
use a reasonable default as defined by the protocol. As above,
the DOTS client MAY extend a current mitigation request's lifetime
trivially with renewed requests for help.
A DOTS client MAY also request an indefinite mitigation lifetime, * Total number of packets blocked by the mitigation
* Current number of packets per second blocked
* Total number of bytes blocked
* Current number of bytes per second blocked
DOTS clients SHOULD take these metrics into account when
determining whether to ask the DOTS server to cease mitigation.
Once a DOTS client requests mitigation, the client MAY withdraw
that request at any time, regardless of whether mitigation is
currently active. The DOTS server MUST immediately acknowledge a
DOTS client's request to stop mitigation.
To protect against route or DNS flapping caused by a client
rapidly toggling mitigation, and to dampen the effect of
oscillating attacks, DOTS servers MAY continue mitigation for a
period of up to five minutes after acknowledging a DOTS client's
withdrawal of a mitigation request. During this period, DOTS
server status messages SHOULD indicate that mitigation is active
but terminating. After the five-minute period elapses, the DOTS
server MUST treat the mitigation as terminated, as the DOTS client
is no longer responsible for the mitigation. For example, if
there is a financial relationship between the DOTS client and
server domains, the DOTS client ceases incurring cost at this
point.
OP-005 Mitigation Lifetime: DOTS servers MUST support mitigation
lifetimes, 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 five-
minute termination period, as described above in OP-004.
DOTS clients SHOULD include a mitigation lifetime in all
mitigation requests. If a DOTS client does not include a
mitigation lifetime in requests for help sent to the DOTS server,
the DOTS server will use a reasonable default as defined by the
protocol.
DOTS servers SHOULD support indefinite mitigation lifetimes,
enabling architectures in which the mitigator is always in the enabling architectures in which the mitigator is always in the
traffic path to the resources for which the DOTS client is traffic path to the resources for which the DOTS client is
requesting protection. DOTS servers MAY refuse such requests for requesting protection. DOTS servers MAY refuse mitigations with
any reason. The reasons themselves are not in scope. indefinite lifetimes, for policy reasons. The reasons themselves
are out of scope for this document, but MUST be included in the
mitigation rejection message from the server, per OP-004.
OP-006 Mitigation Scope: DOTS clients MUST indicate the desired OP-006 Mitigation Scope: DOTS clients MUST indicate desired
scope of any mitigation, for example by using Classless Internet mitigation scope. The scope type will vary depending on the
Domain Routing (CIDR) [RFC1518],[RFC1519] prefixes, [RFC2373] for resources requiring mitigation. All DOTS agent implementations
IPv6 [RFC2460] prefixes, the length/prefix convention established MUST support the following required scope types:
in the Border Gateway Protocol (BGP) [RFC4271], SIP URIs
[RFC3261], E.164 numbers, DNS names, or by a resource group alias * IPv4 addresses in dotted quad format
agreed upon with the server through the data channel.
* IPv4 address prefixes in CIDR notation [RFC4632]
* IPv6 addresses [RFC2373]
* IPv6 address prefixes [RFC2373]
* Domain names [RFC1035]
The following mitigation scope types are OPTIONAL:
* Uniform Resource Identifiers [RFC3986]
DOTS agents MUST support mitigation scope aliases, allowing DOTS
client and server to refer to collections of protected resources
by an opaque identifier created through the data channel, direct
configuration, or other means.
If there is additional information available narrowing the scope If there is additional information available narrowing the scope
of any requested attack response, such as targeted port range, of any requested attack response, such as targeted port range,
protocol, or service, DOTS clients SHOULD include that information protocol, or service, DOTS clients SHOULD include that information
in client signals. DOTS clients MAY also include additional in client signals. DOTS clients MAY also include additional
attack details. Such supplemental information is OPTIONAL, and attack details. Such supplemental information is OPTIONAL, and
DOTS servers MAY ignore it when enabling countermeasures on the DOTS servers MAY ignore it when enabling countermeasures on the
mitigator. mitigator.
As an active attack evolves, clients MUST be able to adjust as As an active attack evolves, clients MUST be able to adjust as
skipping to change at page 13, line 44 skipping to change at page 15, line 8
3.1. Signal Channel 3.1. Signal Channel
As part of a protocol expected to operate over links affected by DDoS As part of a protocol expected to operate over links affected by DDoS
attack traffic, the DOTS signal channel MUST NOT contribute attack traffic, the DOTS signal channel MUST NOT contribute
significantly to link congestion. To meet the operational significantly to link congestion. To meet the operational
requirements above, DOTS signal channel implementations MUST support requirements above, DOTS signal channel implementations MUST support
UDP. However, UDP when deployed naively can be a source of network UDP. However, UDP when deployed naively can be a source of network
congestion, as discussed in [RFC5405]. Signal channel congestion, as discussed in [RFC5405]. Signal channel
implementations using UDP MUST therefore include a congestion control implementations using UDP MUST therefore include a congestion control
mechanism. The form of that congestion control is implementation- mechanism.
specific.
Signal channel implementations using TCP may rely on built-in TCP Signal channel implementations using TCP may rely on built-in TCP
congestion control support. congestion control support.
3.2. Data Channel 3.2. Data Channel
As specified in DATA-001, the data channel requires reliable, in- As specified in DATA-001, the data channel requires reliable, in-
order message delivery. Data channel implementations using TCP may order message delivery. Data channel implementations using TCP may
rely on the TCP implementation's built-in congestion control rely on the TCP implementation's built-in congestion control
mechanisms. mechanisms.
skipping to change at page 14, line 29 skipping to change at page 15, line 37
o Signaling blocking o Signaling blocking
The DOTS protocol MUST be designed for minimal data transfer to The DOTS protocol MUST be designed for minimal data transfer to
address the blocking risk. Impersonation and traffic injection address the blocking risk. Impersonation and traffic injection
mitigation can be managed through current secure communications best mitigation can be managed through current secure communications best
practices. See Section 2.4 above for a detailed discussion. practices. See Section 2.4 above for a detailed discussion.
5. Contributors 5. Contributors
Med Boucadair Mohamed Boucadair
Orange Orange
mohamed.boucadair@orange.com mohamed.boucadair@orange.com
Flemming Andreasen: Flemming Andreasen
Cisco Systems, Inc. Cisco Systems, Inc.
fandreas@cisco.com fandreas@cisco.com
Dave Dolson
Sandvine
ddolson@sandvine.com
6. Acknowledgments 6. Acknowledgments
Thanks to Roman Danyliw and Matt Richardson for careful reading and Thanks to Roman Danyliw and Matt Richardson for careful reading and
feedback. feedback.
7. Change Log 7. Change Log
7.1. 03 revision 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 2016-10-30
o Extended SEC-003 to require secure interfaces within DOTS o Extended SEC-003 to require secure interfaces within DOTS
gateways. gateways.
o Changed DATA-003 to Resource Configuration, delegating control of o Changed DATA-003 to Resource Configuration, delegating control of
acceptable signal loss, heartbeat intervals, and mitigation acceptable signal loss, heartbeat intervals, and mitigation
lifetime to DOTS client. lifetime to DOTS client.
o Added data model requirements reflecting client control over the o Added data model requirements reflecting client control over the
above. above.
7.2. 02 revision 7.3. 02 revision
7.3. 01 revision 7.4. 01 revision
2016-03-21 2016-03-21
o Reconciled terminology with -00 revision of o Reconciled terminology with -00 revision of
[I-D.ietf-dots-use-cases]. [I-D.ietf-dots-use-cases].
o Terminology clarification based on working group feedback. o Terminology clarification based on working group feedback.
o Moved security-related requirements to separate section. o Moved security-related requirements to separate section.
o Made resilience/robustness primary general requirement to align o Made resilience/robustness primary general requirement to align
with charter. with charter.
skipping to change at page 16, line 5 skipping to change at page 17, line 37
efficacy reporting from DOTS clients. efficacy reporting from DOTS clients.
o Added proposed operational requirement to cache lookups of all o Added proposed operational requirement to cache lookups of all
kinds. kinds.
o Added proposed operational requirement regarding NAT traversal. o Added proposed operational requirement regarding NAT traversal.
o Removed redundant mutual authentication requirement from data o Removed redundant mutual authentication requirement from data
channel requirements. channel requirements.
7.4. 00 revision 7.5. 00 revision
2015-10-15 2015-10-15
7.5. Initial revision 7.6. Initial revision
2015-09-24 Andrew Mortensen 2015-09-24 Andrew Mortensen
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>. <http://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>. <http://www.rfc-editor.org/info/rfc793>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<http://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998,
<http://www.rfc-editor.org/info/rfc2373>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <http://www.rfc-editor.org/info/rfc4632>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<http://www.rfc-editor.org/info/rfc4821>.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405, for Application Designers", RFC 5405,
DOI 10.17487/RFC5405, November 2008, DOI 10.17487/RFC5405, November 2008,
<http://www.rfc-editor.org/info/rfc5405>. <http://www.rfc-editor.org/info/rfc5405>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-dots-architecture] [I-D.ietf-dots-architecture]
Mortensen, A., Andreasen, F., Reddy, T., Mortensen, A., Andreasen, F., Reddy, T.,
christopher_gray3@cable.comcast.com, c., Compton, R., and christopher_gray3@cable.comcast.com, c., Compton, R., and
N. Teague, "Distributed-Denial-of-Service Open Threat N. Teague, "Distributed-Denial-of-Service Open Threat
Signaling (DOTS) Architecture", draft-ietf-dots- Signaling (DOTS) Architecture", draft-ietf-dots-
architecture-00 (work in progress), July 2016. architecture-01 (work in progress), October 2016.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Fouant, S., Migault, D., Moskowitz, R., Dobbins, R., Fouant, S., Migault, D., Moskowitz, R.,
Teague, N., and L. Xia, "Use cases for DDoS Open Threat Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
Signaling", draft-ietf-dots-use-cases-01 (work in Open Threat Signaling", draft-ietf-dots-use-cases-03 (work
progress), March 2016. in progress), November 2016.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address
Allocation with CIDR", RFC 1518, DOI 10.17487/RFC1518,
September 1993, <http://www.rfc-editor.org/info/rfc1518>.
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, DOI 10.17487/RFC1519,
September 1993, <http://www.rfc-editor.org/info/rfc1519>.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, DOI 10.17487/RFC2373, July 1998,
<http://www.rfc-editor.org/info/rfc2373>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
Denial-of-Service Considerations", RFC 4732, Denial-of-Service Considerations", RFC 4732,
DOI 10.17487/RFC4732, December 2006, DOI 10.17487/RFC4732, December 2006,
<http://www.rfc-editor.org/info/rfc4732>. <http://www.rfc-editor.org/info/rfc4732>.
Authors' Addresses Authors' Addresses
Andrew Mortensen Andrew Mortensen
Arbor Networks, Inc. Arbor Networks, Inc.
2727 S. State St 2727 S. State St
 End of changes. 37 change blocks. 
125 lines changed or deleted 215 lines changed or added

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