draft-ietf-dots-requirements-18.txt   draft-ietf-dots-requirements-19.txt 
DOTS A. Mortensen DOTS A. Mortensen
Internet-Draft Arbor Networks Internet-Draft Arbor Networks
Intended status: Informational T. Reddy Intended status: Informational T. Reddy
Expires: August 6, 2019 McAfee Expires: August 29, 2019 McAfee
R. Moskowitz R. Moskowitz
Huawei Huawei
February 2, 2019 February 25, 2019
Distributed Denial of Service (DDoS) Open Threat Signaling Requirements Distributed Denial of Service (DDoS) Open Threat Signaling Requirements
draft-ietf-dots-requirements-18 draft-ietf-dots-requirements-19
Abstract Abstract
This document defines the requirements for the Distributed Denial of This document defines the requirements for the Distributed Denial of
Service (DDoS) Open Threat Signaling (DOTS) protocols enabling Service (DDoS) Open Threat Signaling (DOTS) protocols enabling
coordinated response to DDoS attacks. coordinated response to DDoS attacks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 6, 2019. This Internet-Draft will expire on August 29, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
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 . . . . . . . . . . . . . . . . . . 7
2.2. Signal Channel Requirements . . . . . . . . . . . . . . . 8 2.2. Signal Channel Requirements . . . . . . . . . . . . . . . 8
2.3. Data Channel Requirements . . . . . . . . . . . . . . . . 13 2.3. Data Channel Requirements . . . . . . . . . . . . . . . . 13
2.4. Security Requirements . . . . . . . . . . . . . . . . . . 14 2.4. Security Requirements . . . . . . . . . . . . . . . . . . 14
2.5. Data Model Requirements . . . . . . . . . . . . . . . . . 15 2.5. Data Model Requirements . . . . . . . . . . . . . . . . . 16
3. Congestion Control Considerations . . . . . . . . . . . . . . 16 3. Congestion Control Considerations . . . . . . . . . . . . . . 17
3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 16 3.1. Signal Channel . . . . . . . . . . . . . . . . . . . . . 17
3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Data Channel . . . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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 Distributed Denial of Service (DDoS) attacks afflict networks
connected to the Internet, plaguing network operators at service connected to the Internet, plaguing network operators at service
providers and enterprises around the world. High-volume attacks providers and enterprises around the world. High-volume attacks
skipping to change at page 3, line 17 skipping to change at page 3, line 17
operators in the attack path unable to assist in the defense. operators in the attack path unable to assist in the defense.
A standardized method to coordinate a real-time response among A standardized method to coordinate a real-time response among
involved operators will increase the speed and effectiveness of DDoS involved operators will increase the speed and effectiveness of DDoS
attack mitigation, and reduce the impact of these attacks. This attack mitigation, and reduce the impact of these attacks. This
document describes the required characteristics of protocols that document describes the required characteristics of protocols that
enable attack response coordination and mitigation of DDoS attacks. enable attack response coordination and mitigation of DDoS attacks.
DDoS Open Threat Signaling (DOTS) communicates the need for defensive DDoS Open Threat Signaling (DOTS) communicates the need for defensive
action in anticipation of or in response to an attack, but does not action in anticipation of or in response to an attack, but does not
dictate the implementation of these actions. The requirements in dictate the implementation of these actions. The DOTS use cases are
this document are derived from [I-D.ietf-dots-use-cases] and discussed in [I-D.ietf-dots-use-cases] and the DOTS architecture is
[I-D.ietf-dots-architecture]. discussed in [I-D.ietf-dots-architecture].
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP14 [RFC2119] document are to be interpreted as described in BCP14 [RFC2119]
[RFC8174], when, and only when, they appear in all capitals. [RFC8174], when, and only when, they appear in all capitals. These
capitalized words are used to signify the requirements for DOTS
protocols design.
This document adopts the following terms: This document adopts the following terms:
DDoS: A distributed denial-of-service attack, in which traffic DDoS: A distributed denial-of-service attack, in which traffic
originating from multiple sources is directed at a target on a originating from multiple sources is 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 and/or other functionality of an attack target. the availability and/or other functionality of an attack target.
Denial-of-service considerations are discussed in detail in Denial-of-service considerations are discussed in detail in
[RFC4732]. [RFC4732].
skipping to change at page 7, line 6 skipping to change at page 7, line 13
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
proprietary DDoS defenses. Future extensions MUST be backward proprietary DDoS defenses. Future extensions MUST be backward
compatible. Implementations of older protocol versions MUST compatible. Implementations of older protocol versions MUST
ignore optional information added to DOTS messages as part of ignore optional information added to DOTS messages as part of
newer protocol versions. Implementations of older protocol newer protocol versions. Implementations of older protocol
versions MUST reject mandatory information added to DOTS messages versions MUST reject DOTS messages carrying mandatory information
as part of newer protocol versions. 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. Additional means to enhance the resilience of DOTS traffic. Additional means to enhance the resilience of DOTS
protocols, including when multiple DOTS servers are provisioned to protocols, including when multiple DOTS servers are provisioned to
the DOTS clients, SHOULD be considered. The protocol MUST be the DOTS clients, SHOULD be considered. The protocol MUST be
resilient, that is, continue operating despite message loss and resilient, that is, continue operating despite message loss and
out-of-order or redundant message delivery. In support of out-of-order or redundant message delivery. In support of
skipping to change at page 8, line 20 skipping to change at page 8, line 26
(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.
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. If the total message size
exceeds the path MTU, the DOTS agent MUST split the message into
separate messages; for example, the list of mitigation scope types
could be split into multiple lists and each list conveyed in a new
message.
DOTS agents can attempt to learn PMTU using the procedures DOTS agents can attempt to learn PMTU using the procedures
discussed in [I-D.ietf-intarea-frag-fragile]. If the PMTU cannot discussed in [I-D.ietf-intarea-frag-fragile]. If the PMTU cannot
be discovered, DOTS agents MUST assume a PMTU of 1280 bytes for be discovered, DOTS agents MUST assume a PMTU of 1280 bytes for
IPv6. If IPv4 support on legacy or otherwise unusual networks is IPv6. If the PMTU cannot be discovered, DOTS agents MUST assume a
a consideration and the PMTU is unknown, DOTS implementations MAY PMTU of 1280 bytes, as IPv6 requires that every link in the
rely on a PMTU of 576 bytes for IPv4 datagrams, as discussed in Internet have an MTU of 1280 octets or greater as specified in
[RFC8200]. If IPv4 support on legacy or otherwise unusual
networks is a consideration and the PMTU is unknown, DOTS
implementations MAY assume on a PMTU of 576 bytes for IPv4
datagrams, as every IPv4 host must be capable of receiving a
packet whose length is equal to 576 bytes as discussed in
[RFC0791] and [RFC1122]. [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. The heartbeat interval during active mitigation could be health. These keepalives serve the purpose to maintain any on-
negotiable, but MUST be frequent enough to maintain any on-path path NAT or Firewall bindings to avoid cryptographic handshake for
NAT or Firewall bindings during mitigation. When TCP is used as new mitigation requests. The heartbeat interval during active
transport, the DOTS signal channel heartbeat messages need to be mitigation could be negotiable based on NAT/Firewall
frequent enough to maintain the TCP connection state. characteristics. Absent information about the NAT/Firewall
characteristics, DOTS agent needs to ensure its on-path NAT or
Firewall bindings do not expire, by using the keep-alive frequency
discussed in Section 3.5 of [RFC8085].
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 server MUST mitigation, and to keep the channel active, DOTS servers 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.
During peace time, signal channel MUST be considered active until When no attack traffic is present, the signal channel MUST be
either DOTS agent fails to receive heartbeats from the other after considered active until either DOTS agent fails to receive
a mutually agreed upon retransmission procedure has been heartbeats from the other peer after a mutually agreed upon
exhausted. Peer DOTS agents MUST regularly send heartbeats to retransmission procedure has been exhausted. Peer DOTS agents
each other while a mitigation request is active. Because MUST regularly send heartbeats to each other while a mitigation
heartbeat loss is much more likely during volumetric attack, DOTS request is active. Because heartbeat loss is much more likely
agents SHOULD avoid signal channel termination when mitigation is during volumetric attack, DOTS agents SHOULD avoid signal channel
active and heartbeats are not received by either DOTS agent for an termination when mitigation is active and heartbeats are not
extended period. The exception circumstances to terminate the received by either DOTS agent for an extended period. The
signal channel session during active mitigation are discussed exception circumstances to terminate the signal channel session
below: during active mitigation are discussed below:
* To handle possible DOTS server restart or crash, the DOTS * To handle possible DOTS server restart or crash, the DOTS
clients MAY attempt to establish a new signal channel session, clients MAY attempt to establish a new signal channel session,
but MUST continue to send heartbeats on the current session so but MUST continue to send heartbeats on the current session so
that the DOTS server knows the session is still alive. If the that the DOTS server knows the session is still alive. If the
new session is successfully established, the DOTS client can new session is successfully established, the DOTS client can
terminate the current session. terminate the current session.
* DOTS servers are assumed to have the ability to monitor the * DOTS servers are assumed to have the ability to monitor the
attack, using feedback from the mitigator and other available attack, using feedback from the mitigator and other available
skipping to change at page 10, line 14 skipping to change at page 10, line 31
while mitigation is enabled during an active attack against a while mitigation is enabled during an active attack against a
target in the DOTS client's domain. target in the DOTS client's domain.
SIG-006 Mitigation Requests and Status: Authorized DOTS clients MUST SIG-006 Mitigation Requests and Status: Authorized DOTS clients MUST
be able to request scoped mitigation from DOTS servers. DOTS be able to request scoped mitigation from DOTS servers. DOTS
servers MUST send status to the DOTS clients about mitigation servers MUST send status to the DOTS clients about mitigation
requests. If a DOTS server rejects an authorized request for requests. If a DOTS server rejects an authorized request for
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, DOTS servers MUST regularly send mitigation status updates to
DOTS servers MUST regularly send mitigation status to authorized authorized DOTS clients which have requested and been granted
DOTS clients which have requested and been granted mitigation, mitigation. If unreliable transport is used for the signal
regardless of client requests for mitigation status. channel protocol, due to the higher likelihood of packet loss
during a DDoS attack, DOTS servers MUST send mitigation status
multiple times at regular intervals following the the data
transmission guidelines discussed in Section 3.1.3 of [RFC8085].
When DOTS client-requested mitigation is active, DOTS server When DOTS client-requested mitigation is active, DOTS server
status messages MUST 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
skipping to change at page 12, line 37 skipping to change at page 13, line 8
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 MUST transmit a metric of perceived mitigation DOTS clients MUST be able to transmit a metric of perceived
efficacy to the DOTS server. DOTS servers MAY use the efficacy mitigation efficacy to the DOTS server. DOTS servers MAY use the
metric to adjust countermeasures activated on a mitigator on efficacy metric to adjust countermeasures activated on a mitigator
behalf of a DOTS client. on 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
skipping to change at page 13, line 37 skipping to change at page 14, line 8
The data channel provides a protocol for DOTS configuration, The data channel provides a protocol for DOTS configuration,
management. For example, a DOTS client may submit to a DOTS server a management. For example, a DOTS client may submit to a DOTS server a
collection of prefixes it wants to refer to by alias when requesting collection of prefixes it wants to refer to by alias when requesting
mitigation, to which the server would respond with a success status mitigation, to which the server would respond with a success status
and the new prefix group alias, or an error status and message in the and the new prefix group alias, or an error status and message in the
event the DOTS client's data channel request failed. event the DOTS client's data channel request failed.
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
channel are likely to contain operationally or privacy-sensitive
information or instructions from the remote DOTS agent. Theft,
modification, or replay of data channel transmissions could lead
to information leaks or malicious transactions on behalf of the
sending agent (see Section 4 below). Consequently data sent over
the data channel MUST be encrypted using a secure transport (like
TLS). DOTS servers MUST enable means to prevent leaking
operationally or privacy-sensitive data. Although administrative
entities participating in DOTS may detail what data may be
revealed to third-party DOTS agents, such considerations are not
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
for resources belonging to a client. for resources belonging to a client.
skipping to change at page 14, line 31 skipping to change at page 14, line 37
2.4. Security Requirements 2.4. Security Requirements
DOTS must operate within a particularly strict security context, as DOTS must operate within a particularly strict security context, as
an insufficiently protected signal or data channel may be subject to an insufficiently protected signal or data channel may be subject to
abuse, enabling or supplementing the very attacks DOTS purports to abuse, enabling or supplementing the very attacks DOTS purports to
mitigate. mitigate.
SEC-001 Peer Mutual Authentication: DOTS agents MUST authenticate SEC-001 Peer Mutual Authentication: DOTS agents MUST authenticate
each other before a DOTS signal or data channel is considered each other before a DOTS signal or data channel is considered
valid. The method of authentication is not specified in this valid. The method of authentication is not specified in this
document, but should follow current industry best practices with document, but should follow current IETF best practices (like
respect to any cryptographic mechanisms to authenticate the remote [RFC7525]) with respect to any cryptographic mechanisms to
peer. authenticate the remote peer.
SEC-002 Message Confidentiality, Integrity and Authenticity: DOTS SEC-002 Message Confidentiality, Integrity and Authenticity: DOTS
protocols MUST take steps to protect the confidentiality, protocols MUST take steps to protect the confidentiality,
integrity and authenticity of messages sent between client and integrity and authenticity of messages sent between client and
server. While specific transport- and message-level security server. While specific transport- and message-level security
options are not specified, the protocols MUST follow current options are not specified, the protocols MUST follow current IETF
industry best practices for encryption and message authentication. best practices (like [RFC7525]) for encryption and message
Client-domain DOTS gateways are more trusted than DOTS clients, authentication. Client-domain DOTS gateways are more trusted than
while server-domain DOTS gateways and DOTS servers share the same DOTS clients, while server-domain DOTS gateways and DOTS servers
level of trust. A security mechanism at the network layer (e.g., share the same level of trust. A security mechanism at the
TLS) is thus adequate to provide hop-by-hop security. In other transport layer (e.g., TLS) is thus adequate to provide security
words, end-to-end security is not required for DOTS protocols. between peer DOTS agents.
In order for DOTS protocols to remain secure despite advancements In order for DOTS protocols to remain secure despite advancements
in cryptanalysis and traffic analysis, DOTS agents MUST support in cryptanalysis and traffic analysis, DOTS agents MUST support
secure negotiation of the terms and mechanisms of protocol secure negotiation of the terms and mechanisms of protocol
security, subject to the interoperability and signal message size security, subject to the interoperability and signal message size
requirements in Section 2.2. requirements in Section 2.2.
While the interfaces between downstream DOTS server and upstream While the interfaces between downstream DOTS server and upstream
DOTS client within a DOTS gateway are implementation-specific, DOTS client within a DOTS gateway are implementation-specific,
those interfaces nevertheless MUST provide security equivalent to those interfaces nevertheless MUST provide security equivalent to
that of the signal channels bridged by gateways in the signaling that of the signal channels bridged by gateways in the signaling
path. For example, when a DOTS gateway consisting of a DOTS path. For example, when a DOTS gateway consisting of a DOTS
server and DOTS client is running on the same logical device, the server and DOTS client is running on the same logical device, the
two DOTS agents could be implemented within the same process two DOTS agents could be implemented within the same process
security boundary. security boundary.
SEC-003 Message Replay Protection: To prevent a passive attacker SEC-003 Data privacy and integrity: Transmissions over the DOTS
protocols are likely to contain operationally or privacy-sensitive
information or instructions from the remote DOTS agent. Theft,
modification, or replay of message transmissions could lead to
information leaks or malicious transactions on behalf of the
sending agent (see Section 4 below). Consequently data sent over
the DOTS protocols MUST be encrypted using secure transports (like
TLS and DTLS). DOTS servers MUST enable means to prevent leaking
operationally or privacy-sensitive data. Although administrative
entities participating in DOTS may detail what data may be
revealed to third-party DOTS agents, such considerations are not
in scope for this document.
SEC-004 Message Replay Protection: To prevent a passive attacker
from capturing and replaying old messages, and thereby potentially from capturing and replaying old messages, and thereby potentially
disrupting or influencing the network policy of the receiving DOTS disrupting or influencing the network policy of the receiving DOTS
agent's domain, DOTS protocols MUST provide a method for replay agent's domain, DOTS protocols MUST provide a method for replay
detection and prevention. detection and prevention.
Within the signal channel, messages MUST be uniquely identified Within the signal channel, messages MUST be uniquely identified
such that replayed or duplicated messages can be detected and such that replayed or duplicated messages can be detected and
discarded. Unique mitigation requests MUST be processed at most discarded. Unique mitigation requests MUST be processed at most
once. once.
SEC-004 Authorization: DOTS servers MUST authorize all messages from SEC-005 Authorization: DOTS servers MUST authorize all messages from
DOTS clients which pertain to mitigation, configuration, DOTS clients which pertain to mitigation, configuration,
filtering, or status. filtering, or status.
DOTS servers MUST reject mitigation requests with scopes which the DOTS servers MUST reject mitigation requests with scopes which the
DOTS client is not authorized to manage. DOTS client is not authorized to manage.
Likewise, DOTS servers MUST refuse to allow creation, modification Likewise, DOTS servers MUST refuse to allow creation, modification
or deletion of scope aliases and drop-/accept-lists when the DOTS or deletion of scope aliases and drop-/accept-lists when the DOTS
client is unauthorized. client is unauthorized.
skipping to change at page 18, line 32 skipping to change at page 19, line 4
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 Dave Dolson
Sandvine Sandvine
ddolson@sandvine.com ddolson@sandvine.com
7. Acknowledgments 7. Acknowledgments
Thanks to Roman Danyliw, Matt Richardson, Joe Touch, Scott Bradner, Thanks to Roman Danyliw, Matt Richardson, Joe Touch, Scott Bradner,
Robert Sparks, Brian Weis, Benjamin Kaduk and Jon Shallow for careful Robert Sparks, Brian Weis, Benjamin Kaduk, Eric Rescorla, Alvaro
reading and feedback. Retana, Suresh Krishnan, Ben Campbell, Mirja Kuehlewind 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 20, line 19 skipping to change at page 20, line 39
<https://www.rfc-editor.org/info/rfc7857>. <https://www.rfc-editor.org/info/rfc7857>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-dots-architecture] [I-D.ietf-dots-architecture]
Mortensen, A., Andreasen, F., K, R., Teague, N., Compton, Mortensen, A., Andreasen, F., K, R., Teague, N., Compton,
R., and c. christopher_gray3@cable.comcast.com, R., and c. christopher_gray3@cable.comcast.com,
"Distributed-Denial-of-Service Open Threat Signaling "Distributed-Denial-of-Service Open Threat Signaling
(DOTS) Architecture", draft-ietf-dots-architecture-10 (DOTS) Architecture", draft-ietf-dots-architecture-11
(work in progress), December 2018. (work in progress), February 2019.
[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-17 (work Open Threat Signaling", draft-ietf-dots-use-cases-17 (work
in progress), January 2019. in progress), January 2019.
[I-D.ietf-intarea-frag-fragile] [I-D.ietf-intarea-frag-fragile]
Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
and F. Gont, "IP Fragmentation Considered Fragile", draft- and F. Gont, "IP Fragmentation Considered Fragile", draft-
ietf-intarea-frag-fragile-08 (work in progress), January ietf-intarea-frag-fragile-09 (work in progress), February
2019. 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",
skipping to change at page 21, line 14 skipping to change at page 21, line 37
[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,
<https://www.rfc-editor.org/info/rfc4732>. <https://www.rfc-editor.org/info/rfc4732>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
Authors' Addresses Authors' Addresses
Andrew Mortensen Andrew Mortensen
Arbor Networks Arbor Networks
2727 S. State St 2727 S. State St
Ann Arbor, MI 48104 Ann Arbor, MI 48104
United States United States
Email: andrewmortensen@gmail.com Email: andrewmortensen@gmail.com
Tirumaleswar Reddy Tirumaleswar Reddy
McAfee 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
Robert Moskowitz Robert Moskowitz
Huawei Huawei
 End of changes. 29 change blocks. 
77 lines changed or deleted 104 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/