draft-ietf-dots-requirements-20.txt   draft-ietf-dots-requirements-21.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: September 2, 2019 McAfee Expires: September 10, 2019 McAfee
R. Moskowitz R. Moskowitz
Huawei Huawei
March 1, 2019 March 9, 2019
Distributed Denial of Service (DDoS) Open Threat Signaling Requirements Distributed Denial of Service (DDoS) Open Threat Signaling Requirements
draft-ietf-dots-requirements-20 draft-ietf-dots-requirements-21
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 September 2, 2019. This Internet-Draft will expire on September 10, 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 10, line 34 skipping to change at page 10, line 34
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.
DOTS servers MUST regularly send mitigation status updates to DOTS servers MUST regularly send mitigation status updates to
authorized DOTS clients which have requested and been granted authorized DOTS clients which have requested and been granted
mitigation. If unreliable transport is used for the signal mitigation. If unreliable transport is used for the signal
channel protocol, due to the higher likelihood of packet loss channel protocol, due to the higher likelihood of packet loss
during a DDoS attack, DOTS servers MUST send mitigation status during a DDoS attack, DOTS servers needs to send mitigation status
multiple times at regular intervals following the the data multiple times at regular intervals following the the data
transmission guidelines discussed in Section 3.1.3 of [RFC8085]. 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
skipping to change at page 14, line 37 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 IETF best practices (like document, but should follow current IETF best practices [RFC7525]
[RFC7525]) with respect to any cryptographic mechanisms to with respect to any cryptographic mechanisms to authenticate the
authenticate the remote peer. 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 IETF options are not specified, the protocols MUST follow current IETF
best practices (like [RFC7525]) for encryption and message best practices [RFC7525] for encryption and message
authentication. Client-domain DOTS gateways are more trusted than authentication. Client-domain DOTS gateways are more trusted than
DOTS clients, while server-domain DOTS gateways and DOTS servers DOTS clients, while server-domain DOTS gateways and DOTS servers
share the same level of trust. A security mechanism at the share the same level of trust. A security mechanism at the
transport layer (e.g., TLS) is thus adequate to provide security transport layer (e.g., TLS) is thus adequate to provide security
between peer DOTS agents. 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
skipping to change at page 20, line 50 skipping to change at page 20, line 50
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <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-11 (DOTS) Architecture", draft-ietf-dots-architecture-12
(work in progress), February 2019. (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.,
 End of changes. 8 change blocks. 
10 lines changed or deleted 10 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/