draft-ietf-dots-requirements-07.txt   draft-ietf-dots-requirements-08.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: May 3, 2018 Huawei Expires: June 8, 2018 Huawei
T. Reddy T. Reddy
McAfee, Inc. McAfee, Inc.
October 30, 2017 December 05, 2017
Distributed Denial of Service (DDoS) Open Threat Signaling Requirements Distributed Denial of Service (DDoS) Open Threat Signaling Requirements
draft-ietf-dots-requirements-07 draft-ietf-dots-requirements-08
Abstract Abstract
This document defines the requirements for the Distributed Denial of This document defines the requirements for the Distributed Denial of
Service (DDoS) Open Threat Signaling (DOTS) protocols coordinating Service (DDoS) Open Threat Signaling (DOTS) protocols coordinating
attack response against DDoS attacks. attack response against DDoS attacks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 May 3, 2018. This Internet-Draft will expire on June 8, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(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 14 skipping to change at page 2, line 14
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Context and Motivation . . . . . . . . . . . . . . . . . 2 1.1. Context and Motivation . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. General Requirements . . . . . . . . . . . . . . . . . . 7 2.1. General Requirements . . . . . . . . . . . . . . . . . . 7
2.2. Signal Channel Requirements . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. 04 revision . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . 17
7.2. 03 revision . . . . . . . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . 18
7.3. 02 revision . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
7.4. 01 revision . . . . . . . . . . . . . . . . . . . . . . . 18
7.5. 00 revision . . . . . . . . . . . . . . . . . . . . . . . 19
7.6. Initial revision . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
1.1. Context and Motivation 1.1. Context and Motivation
Distributed Denial of Service (DDoS) attacks continue to plague Distributed Denial of Service (DDoS) attacks continue to plague
network operators around the globe, from Tier-1 service providers on network operators around the globe, from Tier-1 service providers on
down to enterprises and small businesses. Attack scale and frequency down to enterprises and small businesses. Attack scale and frequency
similarly have continued to increase, in part as a result of software similarly have continued to increase, in part as a result of software
vulnerabilities leading to reflection and amplification attacks. vulnerabilities leading to reflection and amplification attacks.
skipping to change at page 8, line 44 skipping to change at page 8, line 36
interval during active mitigation is not specified, but SHOULD be interval during active mitigation is not specified, but SHOULD be
frequent enough to maintain any on-path NAT bindings during frequent enough to maintain any on-path NAT bindings during
mitigation. 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
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
delay or cease heartbeat exchanges when an active DOTS client has reduce heartbeat frequency or cease heartbeat exchanges when an
not requested mitigation, in order to control load. active DOTS client has not requested mitigation, in order to
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 or either DOTS agent fails to receive heartbeats from the other
after a mutually agreed upon timeout period has elapsed. Because after a mutually agreed upon timeout period has elapsed. Because
heartbeat loss is much more likely during volumetric attack, DOTS heartbeat loss is much more likely during volumetric attack, DOTS
agents SHOULD avoid signal channel termination when mitigation is agents SHOULD avoid signal channel termination when mitigation is
active and heartbeats are not received by either DOTS agent for an active and heartbeats are not received by either DOTS agent for an
extended period. In such circumstances, DOTS clients MAY attempt extended period. In such circumstances, DOTS clients MAY attempt
to reestablish the signal channel. DOTS servers SHOULD monitor to reestablish the signal channel. DOTS servers SHOULD monitor
skipping to change at page 17, line 29 skipping to change at page 17, line 27
Dave Dolson Dave Dolson
Sandvine Sandvine
ddolson@sandvine.com ddolson@sandvine.com
6. Acknowledgments 6. Acknowledgments
Thanks to Roman Danyliw and Matt Richardson for careful reading and Thanks to Roman Danyliw and Matt Richardson for careful reading and
feedback. feedback.
7. Change Log 7. References
7.1. 04 revision
2017-03-13
o Establish required and optional mitigation scope types
o Specify message size for DOTS signal channel
o Recast mitigation lifetime as a DOTS server requirement
o Clarify DOTS server's responsibilities after client request to end
mitigation
o Specify security state handling on redirection
o Signal channel should use transport not susceptible to HOL
blocking
o Expanded list of DDoS types to include network links
7.2. 03 revision
2016-10-30
o Extended SEC-003 to require secure interfaces within DOTS
gateways.
o Changed DATA-003 to Resource Configuration, delegating control of
acceptable signal loss, heartbeat intervals, and mitigation
lifetime to DOTS client.
o Added data model requirements reflecting client control over the
above.
7.3. 02 revision
7.4. 01 revision
2016-03-21
o Reconciled terminology with -00 revision of
[I-D.ietf-dots-use-cases].
o Terminology clarification based on working group feedback.
o Moved security-related requirements to separate section.
o Made resilience/robustness primary general requirement to align
with charter.
o Clarified support for unidirectional communication within the
bidirectional signal channel.
o Added proposed operational requirement to support session
redirection.
o Added proposed operational requirement to support conflict
notification.
o Added proposed operational requirement to support mitigation
lifetime in mitigation requests.
o Added proposed operational requirement to support mitigation
efficacy reporting from DOTS clients.
o Added proposed operational requirement to cache lookups of all
kinds.
o Added proposed operational requirement regarding NAT traversal.
o Removed redundant mutual authentication requirement from data
channel requirements.
7.5. 00 revision
2015-10-15
7.6. Initial revision
2015-09-24 Andrew Mortensen
8. References
8.1. Normative References 7.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,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
skipping to change at page 20, line 37 skipping to change at page 18, line 46
[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>.
[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>.
8.2. Informative References 7.2. Informative References
[I-D.ietf-dots-architecture] [I-D.ietf-dots-architecture]
Mortensen, A., Andreasen, F., Reddy, T., Mortensen, A., Andreasen, F., Reddy, T.,
christopher_gray3@cable.comcast.com, c., Compton, R., and christopher_gray3@cable.comcast.com, c., Compton, R., and
N. Teague, "Distributed-Denial-of-Service Open Threat N. Teague, "Distributed-Denial-of-Service Open Threat
Signaling (DOTS) Architecture", draft-ietf-dots- Signaling (DOTS) Architecture", draft-ietf-dots-
architecture-04 (work in progress), July 2017. architecture-05 (work in progress), October 2017.
[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-07 (work Open Threat Signaling", draft-ietf-dots-use-cases-09 (work
in progress), July 2017. in progress), November 2017.
[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. 12 change blocks. 
107 lines changed or deleted 18 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/