draft-ietf-dots-requirements-12.txt   draft-ietf-dots-requirements-13.txt 
DOTS A. Mortensen DOTS A. Mortensen
Internet-Draft Arbor Networks Internet-Draft Arbor Networks
Intended status: Informational R. Moskowitz Intended status: Informational R. Moskowitz
Expires: July 29, 2018 Huawei Expires: August 11, 2018 Huawei
T. Reddy T. Reddy
McAfee, Inc. McAfee
January 25, 2018 February 07, 2018
Distributed Denial of Service (DDoS) Open Threat Signaling Requirements Distributed Denial of Service (DDoS) Open Threat Signaling Requirements
draft-ietf-dots-requirements-12 draft-ietf-dots-requirements-13
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 July 29, 2018. This Internet-Draft will expire on August 11, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 2, line 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . 6 2.1. General Requirements . . . . . . . . . . . . . . . . . . 6
2.2. Signal Channel Requirements . . . . . . . . . . . . . . . 7 2.2. Signal Channel Requirements . . . . . . . . . . . . . . . 7
2.3. Data Channel Requirements . . . . . . . . . . . . . . . . 12 2.3. Data Channel Requirements . . . . . . . . . . . . . . . . 12
2.4. Security Requirements . . . . . . . . . . . . . . . . . . 13 2.4. Security Requirements . . . . . . . . . . . . . . . . . . 13
2.5. Data Model Requirements . . . . . . . . . . . . . . . . . 14 2.5. Data Model Requirements . . . . . . . . . . . . . . . . . 14
3. Congestion Control Considerations . . . . . . . . . . . . . . 15 3. Congestion Control Considerations . . . . . . . . . . . . . . 16
3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 15 3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 16
3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
1.1. Context and Motivation 1.1. Context and Motivation
Distributed Denial of Service (DDoS) attacks afflict networks of all Distributed Denial of Service (DDoS) attacks afflict networks of all
kinds, plaguing network operators at service providers and kinds, plaguing network operators at service providers and
enterprises around the world. High-volume attacks saturating inbound enterprises around the world. High-volume attacks saturating inbound
links are now common, as attack scale and frequency continue to links are now common, as attack scale and frequency continue to
increase. increase.
skipping to change at page 7, line 7 skipping to change at page 7, line 7
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 caused by particular the severely constrained network conditions caused 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. In support of signaling protocol robustness, message delivery. In support of signaling protocol robustness,
DOTS signals SHOULD be conveyed over a transport not susceptible DOTS signals SHOULD be conveyed over a transport not susceptible
to Head of Line Blocking. to Head of Line Blocking.
GEN-003 Bidirectionality: To support peer health detection, to GEN-003 Bulk Data Exchange: Infrequent bulk data exchange between
maintain an active signal channel, and 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. Unidirectional messages MUST be supported within the
bidirectional signal channel to allow for unsolicited message
delivery, enabling asynchronous notifications between DOTS agents.
GEN-004 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
exchange. exchange.
GEN-004 Mitigation Hinting: DOTS clients may have access to attack
details which can be used to inform mitigation techniques.
Example attack details might include locally collected
fingerprints for an on-going attack, or anticipated or active
attack focal points based on other threat intelligence. DOTS
clients MAY send mitigation hints derived from attack details to
DOTS servers, in the full understanding that the DOTS server MAY
ignore mitigation hints. Mitigation hints MAY be transmitted
across either signal or data channel. DOTS server treatment of
mitigation hints, and how such hints shape mitigation, are
implementation-specific.
GEN-005 Loop Handling: In specific scenarios, it may be possible for
communication between DOTS agents to loop, for example as a result
of misconfiguration or aggressive caching. Signal and data
channel implementations should be prepared to detect and terminate
such loops to prevent service disruption.
2.2. Signal Channel Requirements 2.2. Signal Channel Requirements
SIG-001 Use of Common Transport Protocols: DOTS MUST operate over SIG-001 Use of Common Transport Protocols: DOTS MUST operate over
common widely deployed and standardized transport protocols. common widely deployed and standardized transport protocols.
While connectionless transport such as the User Datagram Protocol While connectionless transport such as the User Datagram Protocol
(UDP) [RFC0768] SHOULD be used for the signal channel, the (UDP) [RFC0768] SHOULD be used for the signal channel, the
Transmission Control Protocol (TCP) [RFC0793] MAY be used if Transmission Control Protocol (TCP) [RFC0793] MAY be used if
necessary due to network policy or middlebox capabilities or necessary due to network policy or middlebox capabilities or
configurations. configurations.
skipping to change at page 8, line 5 skipping to change at page 8, line 15
transport- or message-level security. transport- or message-level security.
DOTS agents SHOULD attempt to learn the PMTU through mechanisms DOTS agents SHOULD attempt to learn the PMTU through mechanisms
such as Path MTU Discovery [RFC1191] or Packetization Layer Path such as Path MTU Discovery [RFC1191] or Packetization Layer Path
MTU Discovery [RFC4821]. If the PMTU cannot be discovered, DOTS MTU Discovery [RFC4821]. If the PMTU cannot be discovered, DOTS
agents SHOULD assume a PMTU of 1280 bytes. If IPv4 support on agents SHOULD assume a PMTU of 1280 bytes. If IPv4 support on
legacy or otherwise unusual networks is a consideration and PMTU legacy or otherwise unusual networks is a consideration and PMTU
is unknown, DOTS implementations MAY rely on a PMTU of 576 bytes, is unknown, DOTS implementations MAY rely on a PMTU of 576 bytes,
as discussed in [RFC0791] and [RFC1122]. as discussed in [RFC0791] and [RFC1122].
SIG-003 Channel Health Monitoring: DOTS agents MUST support exchange SIG-003 Bidirectionality: To support peer health detection, to
maintain an active signal channel, and 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. Unidirectional messages MUST be supported within the
bidirectional signal channel to allow for unsolicited message
delivery, enabling asynchronous notifications between DOTS agents.
SIG-004 Channel Health Monitoring: DOTS agents MUST support exchange
of heartbeat messages over the signal channel to monitor channel of heartbeat messages over the signal channel to monitor channel
health. Peer DOTS agents SHOULD regularly send heartbeats to each health. Peer DOTS agents SHOULD regularly send heartbeats to each
other while a mitigation request is active. The heartbeat other while a mitigation request is active. The heartbeat
interval during active mitigation could be negotiable, but SHOULD interval during active mitigation could be negotiable, but SHOULD
be frequent enough to maintain any on-path NAT or Firewall be frequent enough to maintain any on-path NAT or Firewall
bindings during mitigation. bindings during mitigation.
To support scenarios in which loss of heartbeat is used to trigger To support scenarios in which loss of heartbeat is used to trigger
mitigation, and to keep the channel active, DOTS clients MAY mitigation, and to keep the channel active, DOTS clients MAY
solicit heartbeat exchanges after successful mutual solicit heartbeat exchanges after successful mutual
skipping to change at page 8, line 39 skipping to change at page 9, line 10
termination when mitigation is active and heartbeats are not termination when mitigation is active and heartbeats are not
received by either DOTS agent for an extended period. In such received by either DOTS agent for an extended period. In such
circumstances, DOTS clients MAY attempt to reestablish the signal circumstances, DOTS clients MAY attempt to reestablish the signal
channel, but SHOULD continue to send heartbeats so that the DOTS channel, but SHOULD continue to send heartbeats so that the DOTS
server knows the session is still alive. DOTS servers are assumed server knows the session is still alive. DOTS servers are assumed
to have the ability to monitor the attack, using feedback from the to have the ability to monitor the attack, using feedback from the
mitigator and other available sources, and MAY use the absence of mitigator and other available sources, and MAY use the absence of
attack traffic and lack of client heartbeats as an indication the attack traffic and lack of client heartbeats as an indication the
signal channel is defunct. signal channel is defunct.
SIG-004 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. target 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-005 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
mitigation, the DOTS server MUST include a reason for the mitigation, the DOTS server MUST include a reason for the
rejection in the status message sent to the client. rejection in the status message sent to the client.
Due to the higher likelihood of packet loss during a DDoS attack, Due to the higher likelihood of packet loss during a DDoS attack,
DOTS servers SHOULD regularly send mitigation status to authorized DOTS servers SHOULD regularly send mitigation status to authorized
DOTS clients which have requested and been granted mitigation, DOTS clients which have requested and been granted mitigation,
regardless of client requests for mitigation status. regardless of client requests for mitigation status.
skipping to change at page 10, line 5 skipping to change at page 10, line 28
The initial active-but-terminating period is implementation- and The initial active-but-terminating period is implementation- and
deployment- specific, but SHOULD be sufficiently long to absorb deployment- specific, but SHOULD be sufficiently long to absorb
latency incurred by route propagation. If the client requests latency incurred by route propagation. If the client requests
mitigation again before the initial active-but-terminating period mitigation again before the initial active-but-terminating period
elapses, the DOTS server MAY exponentially increase the active- elapses, the DOTS server MAY exponentially increase the active-
but-terminating period up to a maximum of 300 seconds (5 minutes). but-terminating period up to a maximum of 300 seconds (5 minutes).
After the active-but-terminating period elapses, the DOTS server After the active-but-terminating period elapses, the DOTS server
MUST treat the mitigation as terminated, as the DOTS client is no MUST treat the mitigation as terminated, as the DOTS client is no
longer responsible for the mitigation. longer responsible for the mitigation.
SIG-006 Mitigation Lifetime: DOTS servers MUST support mitigations SIG-007 Mitigation Lifetime: DOTS servers MUST support mitigations
for a negotiated time interval, and MUST terminate a mitigation for a negotiated time interval, and MUST terminate a mitigation
when the lifetime elapses. DOTS servers also MUST support renewal when the lifetime elapses. DOTS servers also MUST support renewal
of mitigation lifetimes in mitigation requests from DOTS clients, of mitigation lifetimes in mitigation requests from DOTS clients,
allowing clients to extend mitigation as necessary for the allowing clients to extend mitigation as necessary for the
duration of an attack. duration of an attack.
DOTS servers MUST treat a mitigation terminated due to lifetime DOTS servers MUST treat a mitigation terminated due to lifetime
expiration exactly as if the DOTS client originating the expiration exactly as if the DOTS client originating the
mitigation had asked to end the mitigation, including the active- mitigation had asked to end the mitigation, including the active-
but-terminating period, as described above in SIG-005. but-terminating period, as described above in SIG-005.
skipping to change at page 10, line 32 skipping to change at page 11, line 7
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 clients MUST be prepared to not be requesting protection. DOTS clients MUST be prepared to not be
granted mitigations with indefinite lifetimes. DOTS servers MAY granted mitigations with indefinite lifetimes. DOTS servers MAY
refuse mitigations with indefinite lifetimes, for policy reasons. refuse mitigations with indefinite lifetimes, for policy reasons.
The reasons themselves are out of scope. If the DOTS server does The reasons themselves are out of scope. If the DOTS server does
not grant a mitigation request with an indefinite mitigation not grant a mitigation request with an indefinite mitigation
lifetime, it MUST set the lifetime to a value that is configured lifetime, it MUST set the lifetime to a value that is configured
locally. That value MUST be returned in a reply to the requesting locally. That value MUST be returned in a reply to the requesting
DOTS client. DOTS client.
SIG-007 Mitigation Scope: DOTS clients MUST indicate desired SIG-008 Mitigation Scope: DOTS clients MUST indicate desired
mitigation scope. The scope type will vary depending on the mitigation scope. The scope type will vary depending on the
resources requiring mitigation. All DOTS agent implementations resources requiring mitigation. All DOTS agent implementations
MUST support the following required scope types: MUST support the following required scope types:
* IPv4 prefixes in CIDR notation [RFC4632] * IPv4 prefixes in CIDR notation [RFC4632]
* IPv6 prefixes [RFC4291][RFC5952] * IPv6 prefixes [RFC4291][RFC5952]
* Domain names [RFC1035] * Domain names [RFC1035]
skipping to change at page 11, line 27 skipping to change at page 12, line 5
As an active attack evolves, DOTS clients MUST be able to adjust As an active attack evolves, DOTS clients MUST be able to adjust
as necessary the scope of requested mitigation by refining the as necessary the scope of requested mitigation by refining the
scope of resources requiring mitigation. scope of resources requiring mitigation.
A DOTS client may obtain the mitigation scope through direct A DOTS client may obtain the mitigation scope through direct
provisioning or through implementation-specific methods of provisioning or through implementation-specific methods of
discovery. DOTS clients MUST support at least one mechanism to discovery. DOTS clients MUST support at least one mechanism to
obtain mitigation scope. obtain mitigation scope.
SIG-008 Mitigation Efficacy: When a mitigation request is active, SIG-009 Mitigation Efficacy: When a mitigation request is active,
DOTS clients SHOULD transmit a metric of perceived mitigation DOTS clients SHOULD transmit a metric of perceived mitigation
efficacy to the DOTS server. DOTS servers MAY use the efficacy efficacy to the DOTS server. DOTS servers MAY use the efficacy
metric to adjust countermeasures activated on a mitigator on metric to adjust countermeasures activated on a mitigator on
behalf of a DOTS client. behalf of a DOTS client.
SIG-009 Conflict Detection and Notification: Multiple DOTS clients SIG-010 Conflict Detection and Notification: Multiple DOTS clients
controlled by a single administrative entity may send conflicting controlled by a single administrative entity may send conflicting
mitigation requests as a result of misconfiguration, operator mitigation requests as a result of misconfiguration, operator
error, or compromised DOTS clients. DOTS servers in the same error, or compromised DOTS clients. DOTS servers in the same
administrative domain attempting to honor conflicting requests may administrative domain attempting to honor conflicting requests may
flap network route or DNS information, degrading the networks flap network route or DNS information, degrading the networks
attempting to participate in attack response with the DOTS attempting to participate in attack response with the DOTS
clients. DOTS servers in a single administrative domain SHALL clients. DOTS servers in a single administrative domain SHALL
detect such conflicting requests, and SHALL notify the DOTS detect such conflicting requests, and SHALL notify the DOTS
clients in conflict. The notification SHOULD indicate the nature clients in conflict. The notification SHOULD indicate the nature
and scope of the conflict, for example, the overlapping prefix and scope of the conflict, for example, the overlapping prefix
range in a conflicting mitigation request. range in a conflicting mitigation request.
SIG-010 Network Address Translator Traversal: DOTS clients may be SIG-011 Network Address Translator Traversal: DOTS clients may be
deployed behind a Network Address Translator (NAT), and need to deployed behind a Network Address Translator (NAT), and need to
communicate with DOTS servers through the NAT. DOTS protocols communicate with DOTS servers through the NAT. DOTS protocols
MUST therefore be capable of traversing NATs. MUST therefore be capable of traversing NATs.
If UDP is used as the transport for the DOTS signal channel, all If UDP is used as the transport for the DOTS signal channel, all
considerations in "Middlebox Traversal Guidelines" in [RFC8085] considerations in "Middlebox Traversal Guidelines" in [RFC8085]
apply to DOTS. Regardless of transport, DOTS protocols MUST apply to DOTS. Regardless of transport, DOTS protocols MUST
follow established best common practices established in BCP 127 follow established best common practices established in BCP 127
for NAT traversal [RFC4787][RFC6888][RFC7857]. for NAT traversal [RFC4787][RFC6888][RFC7857].
skipping to change at page 20, line 20 skipping to change at page 20, line 32
Email: amortensen@arbor.net Email: amortensen@arbor.net
Robert Moskowitz Robert Moskowitz
Huawei Huawei
Oak Park, MI 42837 Oak Park, MI 42837
United States United States
Email: rgm@htt-consult.com Email: rgm@htt-consult.com
Tirumaleswar Reddy Tirumaleswar Reddy
McAfee, Inc. McAfee
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore, Karnataka 560071 Bangalore, Karnataka 560071
India India
Email: TirumaleswarReddy_Konda@McAfee.com Email: TirumaleswarReddy_Konda@McAfee.com
 End of changes. 18 change blocks. 
29 lines changed or deleted 47 lines changed or added

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