< draft-ietf-dots-requirements-16.txt   draft-ietf-dots-requirements-17.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: April 25, 2019 Huawei Expires: August 4, 2019 Huawei
T. Reddy T. Reddy
McAfee McAfee
October 22, 2018 January 31, 2019
Distributed Denial of Service (DDoS) Open Threat Signaling Requirements Distributed Denial of Service (DDoS) Open Threat Signaling Requirements
draft-ietf-dots-requirements-16 draft-ietf-dots-requirements-17
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 April 25, 2019. This Internet-Draft will expire on August 4, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
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 . . . . . . . . . . . . . . . . . . 6 2.1. General Requirements . . . . . . . . . . . . . . . . . . 6
2.2. Signal Channel Requirements . . . . . . . . . . . . . . . 7 2.2. Signal Channel Requirements . . . . . . . . . . . . . . . 8
2.3. Data Channel Requirements . . . . . . . . . . . . . . . . 12 2.3. Data Channel Requirements . . . . . . . . . . . . . . . . 13
2.4. Security Requirements . . . . . . . . . . . . . . . . . . 13 2.4. Security Requirements . . . . . . . . . . . . . . . . . . 14
2.5. Data Model Requirements . . . . . . . . . . . . . . . . . 15 2.5. Data Model Requirements . . . . . . . . . . . . . . . . . 15
3. Congestion Control Considerations . . . . . . . . . . . . . . 16 3. Congestion Control Considerations . . . . . . . . . . . . . . 16
3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 16 3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 16
3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 16 3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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 5, line 31 skipping to change at page 5, line 31
Accept-list: A list of filters indicating sources from which traffic Accept-list: A list of filters indicating sources from which traffic
should always be allowed, regardless of contradictory data gleaned should always be allowed, regardless of contradictory data gleaned
in a detected attack. in a detected attack.
Multi-homed DOTS client: A DOTS client exchanging messages with Multi-homed DOTS client: A DOTS client exchanging messages with
multiple DOTS servers, each in a separate administrative domain. multiple DOTS servers, each in a separate administrative domain.
2. Requirements 2. Requirements
This section describes the required features and characteristics of The goal of the DOTS requirements specification is to specify the
the DOTS protocols. requirements for DOTS signal channel and data channel protocols that
have different application and transport layer requirements. This
section describes the required features and characteristics of the
DOTS protocols.
The DOTS protocols enable and manage mitigation on behalf of a The DOTS protocols enable and manage mitigation on behalf of a
network domain or resource which is or may become the focus of a DDoS network domain or resource which is or may become the focus of a DDoS
attack. An active DDoS attack against the entity controlling the attack. An active DDoS attack against the entity controlling the
DOTS client need not be present before establishing a communication DOTS client need not be present before establishing a communication
channel between DOTS agents. Indeed, establishing a relationship channel between DOTS agents. Indeed, establishing a relationship
with peer DOTS agents during normal network conditions provides the with peer DOTS agents during normal network conditions provides the
foundation for more rapid attack response against future attacks, as foundation for more rapid attack response against future attacks, as
all interactions setting up DOTS, including any business or service all interactions setting up DOTS, including any business or service
level agreements, are already complete. Reachability information of level agreements, are already complete. Reachability information of
skipping to change at page 6, line 46 skipping to change at page 6, line 50
Finally, DOTS should be sufficiently extensible to meet future needs Finally, DOTS should be sufficiently extensible to meet future needs
in coordinated attack defense, although this consideration is in coordinated attack defense, although this consideration is
necessarily superseded by the other operational requirements. necessarily superseded by the other operational requirements.
2.1. General Requirements 2.1. General Requirements
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. Implementations of older protocol be backward compatible. Implementations of older protocol
versions SHOULD ignore information added to DOTS messages as part versions MUST ignore optional information added to DOTS messages
of newer protocol versions. as part of newer protocol versions. Implementations of older
protocol versions MUST reject mandatory information added to DOTS
messages as part of newer protocol versions.
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 attack the severely constrained network conditions caused by attack
traffic. The protocol MUST be resilient, that is, continue traffic. Additional means to enhance the resilience of DOTS
operating despite message loss and out-of-order or redundant protocols, including when multiple DOTS servers are provisioned to
message delivery. In support of signaling protocol robustness, the DOTS clients, SHOULD be considered. The protocol MUST be
DOTS signals SHOULD be conveyed over a transport not susceptible resilient, that is, continue operating despite message loss and
to Head of Line Blocking. out-of-order or redundant message delivery. In support of
signaling protocol robustness, DOTS signals SHOULD be conveyed
over transport and application protocols not susceptible to Head
of Line Blocking. These requirements are at SHOULD strength to
handle middle-boxes and firewall traversal.
GEN-003 Bulk Data Exchange: Infrequent bulk data exchange between GEN-003 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 drop- or coordination, permitting such tasks as population of drop- or
accept-listed source addresses; address or prefix group aliasing; accept-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
skipping to change at page 8, line 9 skipping to change at page 8, line 22
necessary due to network policy or middlebox capabilities or necessary due to network policy or middlebox capabilities or
configurations. configurations.
SIG-002 Sub-MTU Message Size: To avoid message fragmentation and the SIG-002 Sub-MTU Message Size: To avoid message fragmentation and the
consequently decreased probability of message delivery over a consequently decreased probability of message delivery over a
congested link, signaling protocol message size MUST be kept under congested link, signaling protocol message size MUST be kept under
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. transport- or message-level security.
DOTS agents SHOULD attempt to learn the PMTU through mechanisms DOTS agents can attempt to learn PMTU using the procedures
such as Path MTU Discovery [RFC1191] or Packetization Layer Path discussed in [I-D.ietf-intarea-frag-fragile]. If the PMTU cannot
MTU Discovery [RFC4821]. If the PMTU cannot be discovered, DOTS be discovered, DOTS agents MUST assume a PMTU of 1280 bytes for
agents SHOULD assume a PMTU of 1280 bytes. If IPv4 support on IPv6. If IPv4 support on legacy or otherwise unusual networks is
legacy or otherwise unusual networks is a consideration and the a consideration and the PMTU is unknown, DOTS implementations MAY
PMTU is unknown, DOTS implementations MAY rely on a PMTU of 576 rely on a PMTU of 576 bytes for IPv4 datagrams, as discussed in
bytes, as discussed in [RFC0791] and [RFC1122]. [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.
SIG-004 Channel Health Monitoring: DOTS agents MUST support exchange 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. The heartbeat interval during active mitigation could be
other while a mitigation request is active. The heartbeat negotiable, but MUST be frequent enough to maintain any on-path
interval during active mitigation could be negotiable, but SHOULD NAT or Firewall bindings during mitigation. When TCP is used as
be frequent enough to maintain any on-path NAT or Firewall transport, the DOTS signal channel heartbeat messages need to be
bindings during mitigation. frequent enough to maintain the TCP connection state.
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 server MUST
solicit heartbeat exchanges after successful mutual solicit heartbeat exchanges after successful mutual
authentication. When DOTS agents are exchanging heartbeats and no authentication. When DOTS agents are exchanging heartbeats and no
mitigation request is active, either agent MAY request changes to mitigation request is active, either agent MAY request changes to
the heartbeat rate. For example, a DOTS server might want to the heartbeat rate. For example, a DOTS server might want to
reduce heartbeat frequency or cease heartbeat exchanges when an reduce heartbeat frequency or cease heartbeat exchanges when an
active DOTS client has not requested mitigation, in order to active DOTS client has not requested mitigation, in order to
control load. control load.
Following mutual authentication, a signal channel MUST be Following mutual authentication, a signal channel MUST be
considered active until a DOTS agent explicitly ends the session, considered active until a DOTS agent explicitly ends the session.
or either DOTS agent fails to receive heartbeats from the other During peace time, signal channel MUST be considered active until
after a mutually agreed upon retransmission procedure has been either DOTS agent fails to receive heartbeats from the other after
exhausted. Because heartbeat loss is much more likely during a mutually agreed upon retransmission procedure has been
volumetric attack, DOTS agents SHOULD avoid signal channel exhausted. Peer DOTS agents MUST regularly send heartbeats to
termination when mitigation is active and heartbeats are not each other while a mitigation request is active. Because
received by either DOTS agent for an extended period. In such heartbeat loss is much more likely during volumetric attack, DOTS
circumstances, DOTS clients MAY attempt to reestablish the signal agents SHOULD avoid signal channel termination when mitigation is
channel, but SHOULD continue to send heartbeats so that the DOTS active and heartbeats are not received by either DOTS agent for an
server knows the session is still alive. DOTS servers are assumed extended period. The exception circumstances to terminate the
to have the ability to monitor the attack, using feedback from the signal channel session during active mitigation are discussed
mitigator and other available sources, and MAY use the absence of below:
attack traffic and lack of client heartbeats as an indication the
signal channel is defunct. * To handle possible DOTS server restart or crash, the DOTS
clients MAY attempt to establish a new signal channel session,
but MUST continue to send heartbeats on the current session so
that the DOTS server knows the session is still alive. If the
new session is successfully established, the DOTS client can
terminate the current session.
* DOTS servers are assumed to have the ability to monitor the
attack, using feedback from the mitigator and other available
sources, and MAY use the absence of attack traffic and lack of
client heartbeats as an indication the signal channel is
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 authentication domain of the redirection
skipping to change at page 9, line 37 skipping to change at page 10, line 15
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
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 MUST 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.
When DOTS client-requested mitigation is active, DOTS server When DOTS client-requested mitigation is active, DOTS server
status messages SHOULD include the following mitigation metrics: status messages MUST include the following mitigation metrics:
* Total number of packets blocked by the mitigation * Total number of packets blocked by the mitigation
* Current number of packets per second blocked * Current number of packets per second blocked
* Total number of bytes blocked * Total number of bytes blocked
* Current number of bytes per second blocked * Current number of bytes per second blocked
DOTS clients MAY take these metrics into account when determining DOTS clients MAY take these metrics into account when determining
whether to ask the DOTS server to cease mitigation. whether to ask the DOTS server to cease mitigation.
A DOTS client MAY withdraw a mitigation request at any time, A DOTS client MAY withdraw a mitigation request at any time,
regardless of whether mitigation is currently active. The DOTS regardless of whether mitigation is currently active. The DOTS
server MUST immediately acknowledge a DOTS client's request to server MUST immediately acknowledge a DOTS client's request to
stop mitigation. stop mitigation.
To protect against route or DNS flapping caused by a client To protect against route or DNS flapping caused by a client
rapidly toggling mitigation, and to dampen the effect of rapidly toggling mitigation, and to dampen the effect of
skipping to change at page 12, line 11 skipping to change at page 12, line 37
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-009 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 MUST 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-010 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 MUST 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-011 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]
skipping to change at page 13, line 16 skipping to change at page 13, line 43
DATA-001 Reliable transport: Messages sent over the data channel DATA-001 Reliable transport: Messages sent over the data channel
MUST be delivered reliably, in order sent. MUST be delivered reliably, in order sent.
DATA-002 Data privacy and integrity: Transmissions over the data DATA-002 Data privacy and integrity: Transmissions over the data
channel are likely to contain operationally or privacy-sensitive channel are likely to contain operationally or privacy-sensitive
information or instructions from the remote DOTS agent. Theft, information or instructions from the remote DOTS agent. Theft,
modification, or replay of data channel transmissions could lead modification, or replay of data channel transmissions could lead
to information leaks or malicious transactions on behalf of the to information leaks or malicious transactions on behalf of the
sending agent (see Section 4 below). Consequently data sent over sending agent (see Section 4 below). Consequently data sent over
the data channel MUST be encrypted and authenticated using current the data channel MUST be encrypted using a secure transport (like
IETF best practices. DOTS servers MUST enable means to prevent TLS). DOTS servers MUST enable means to prevent leaking
leaking operationally or privacy-sensitive data. Although operationally or privacy-sensitive data. Although administrative
administrative entities participating in DOTS may detail what data entities participating in DOTS may detail what data may be
may be revealed to third-party DOTS agents, such considerations revealed to third-party DOTS agents, such considerations are not
are not in scope for this document. in scope for this document.
DATA-003 Resource Configuration: To help meet the general and signal DATA-003 Resource Configuration: To help meet the general and signal
channel requirements in Section 2.1 and Section 2.2, DOTS server channel requirements in Section 2.1 and Section 2.2, DOTS server
implementations MUST provide an interface to configure resource implementations MUST provide an interface to configure resource
identifiers, as described in SIG-008. DOTS server implementations identifiers, as described in SIG-008. DOTS server implementations
MAY expose additional configurability. Additional configurability MAY expose additional configurability. Additional configurability
is implementation-specific. is implementation-specific.
DATA-004 Policy management: DOTS servers MUST provide methods for DATA-004 Policy management: DOTS servers MUST provide methods for
DOTS clients to manage drop- and accept-lists of traffic destined DOTS clients to manage drop- and accept-lists of traffic destined
skipping to change at page 16, line 25 skipping to change at page 17, line 5
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 signal channel significantly to link congestion. To meet the signal channel
requirements above, DOTS signal channel implementations SHOULD requirements above, DOTS signal channel implementations SHOULD
support connectionless transports. However, some connectionless support connectionless transports. However, some connectionless
transports when deployed naively can be a source of network transports when deployed naively can be a source of network
congestion, as discussed in [RFC8085]. Signal channel congestion, as discussed in [RFC8085]. Signal channel
implementations using such connectionless transports, such as UDP, implementations using such connectionless transports, such as UDP,
therefore MUST include a congestion control mechanism. therefore MUST include a congestion control mechanism.
Signal channel implementations using TCP may rely on built-in TCP Signal channel implementations using a IETF standard congestion-
congestion control support. controlled transport protocol (like TCP) may rely on built-in
transport 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 a IETF
rely on the TCP implementation's built-in congestion control standard congestion-controlled transport protocol may rely on the
mechanisms. transport implementation's built-in congestion control mechanisms.
4. Security Considerations 4. Security Considerations
This document informs future protocols under development, and so does This document informs future protocols under development, and so does
not have security considerations of its own. However, operators not have security considerations of its own. However, operators
should be aware of potential risks involved in deploying DOTS. DOTS should be aware of potential risks involved in deploying DOTS. DOTS
agent impersonation and signal blocking are discussed here. agent impersonation and signal blocking are discussed here.
Additional DOTS security considerations may be found in Additional DOTS security considerations may be found in
[I-D.ietf-dots-architecture] and DOTS protocol documents. [I-D.ietf-dots-architecture] and DOTS protocol documents.
skipping to change at page 18, line 7 skipping to change at page 18, line 30
fandreas@cisco.com fandreas@cisco.com
Dave Dolson Dave Dolson
Sandvine Sandvine
ddolson@sandvine.com ddolson@sandvine.com
7. Acknowledgments 7. Acknowledgments
Thanks to Roman Danyliw, Matt Richardson, and Jon Shallow for careful Thanks to Roman Danyliw, Matt Richardson, Joe Touch, Scott Bradner
reading and feedback. and Jon Shallow for careful reading and feedback.
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,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
skipping to change at page 18, line 35 skipping to change at page 19, line 10
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
skipping to change at page 19, line 15 skipping to change at page 19, line 34
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <https://www.rfc-editor.org/info/rfc4632>. 2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>. 2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010, DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>. <https://www.rfc-editor.org/info/rfc5952>.
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
A., and H. Ashida, "Common Requirements for Carrier-Grade A., and H. Ashida, "Common Requirements for Carrier-Grade
NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
April 2013, <https://www.rfc-editor.org/info/rfc6888>. April 2013, <https://www.rfc-editor.org/info/rfc6888>.
skipping to change at page 19, line 46 skipping to change at page 20, line 12
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-dots-architecture] [I-D.ietf-dots-architecture]
Mortensen, A., Andreasen, F., K, R., Mortensen, A., Andreasen, F., K, R., Teague, N., Compton,
christopher_gray3@cable.comcast.com, c., Compton, R., and R., and c. christopher_gray3@cable.comcast.com,
N. Teague, "Distributed-Denial-of-Service Open Threat "Distributed-Denial-of-Service Open Threat Signaling
Signaling (DOTS) Architecture", draft-ietf-dots- (DOTS) Architecture", draft-ietf-dots-architecture-10
architecture-07 (work in progress), September 2018. (work in progress), December 2018.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
Open Threat Signaling", draft-ietf-dots-use-cases-16 (work Open Threat Signaling", draft-ietf-dots-use-cases-17 (work
in progress), July 2018. in progress), January 2019.
[I-D.ietf-intarea-frag-fragile]
Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
and F. Gont, "IP Fragmentation Considered Fragile", draft-
ietf-intarea-frag-fragile-08 (work in progress), January
2019.
[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,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents", Initiation Protocol (SIP) Back-to-Back User Agents",
RFC 7092, DOI 10.17487/RFC7092, December 2013, RFC 7092, DOI 10.17487/RFC7092, December 2013,
 End of changes. 28 change blocks. 
82 lines changed or deleted 102 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/