draft-ietf-dots-architecture-11.txt   draft-ietf-dots-architecture-12.txt 
DOTS A. Mortensen DOTS A. Mortensen
Internet-Draft Arbor Networks Internet-Draft Arbor Networks
Intended status: Informational F. Andreasen Intended status: Informational F. Andreasen
Expires: August 11, 2019 Cisco Expires: September 1, 2019 Cisco
T. Reddy T. Reddy
McAfee, Inc. McAfee, Inc.
N. Teague N. Teague
Verisign Verisign
R. Compton R. Compton
Charter Charter
C. Gray C. Gray
February 7, 2019 February 28, 2019
Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture
draft-ietf-dots-architecture-11 draft-ietf-dots-architecture-12
Abstract Abstract
This document describes an architecture for establishing and This document describes an architecture for establishing and
maintaining Distributed Denial of Service (DDoS) Open Threat maintaining Distributed Denial of Service (DDoS) Open Threat
Signaling (DOTS) within and between domains. The document does not Signaling (DOTS) within and between domains. The document does not
specify protocols or protocol extensions, instead focusing on specify protocols or protocol extensions, instead focusing on
defining architectural relationships, components and concepts used in defining architectural relationships, components and concepts used in
a DOTS deployment. a DOTS deployment.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 11, 2019. This Internet-Draft will expire on September 1, 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 27 skipping to change at page 10, line 27
clients as described in Section 3.1, and maintains session state, clients as described in Section 3.1, and maintains session state,
tracking requests for mitigation, reporting on the status of active tracking requests for mitigation, reporting on the status of active
mitigations, and terminating sessions in the extended absence of a mitigations, and terminating sessions in the extended absence of a
client heartbeat or when a session times out. client heartbeat or when a session times out.
Assuming the preconditions discussed below exist, a DOTS client Assuming the preconditions discussed below exist, a DOTS client
maintaining an active session with a DOTS server may reasonably maintaining an active session with a DOTS server may reasonably
expect some level of mitigation in response to a request for expect some level of mitigation in response to a request for
coordinated attack response. coordinated attack response.
The DOTS server enforces authorization of DOTS clients' signals for For a given DOTS client (administrative) domain, the DOTS server
mitigation. The mechanism of enforcement is not in scope for this needs to be able to determine whether a given target resource is in
document, but is expected to restrict requested mitigation scope to that domain. For example, this could take the form of associating a
addresses, prefixes, and/or services owned by the DOTS client's set of IP addresses and/or prefixes per domain. The DOTS server
administrative domain, such that a DOTS client from one domain is not enforces authorization of DOTS clients' signals for mitigation. The
able to influence the network path to another domain. A DOTS server mechanism of enforcement is not in scope for this document, but is
MUST reject requests for mitigation of resources not owned by the expected to restrict requested mitigation scope to addresses,
requesting DOTS client's administrative domain. A DOTS server MAY prefixes, and/or services owned by the DOTS client domain, such that
also refuse a DOTS client's mitigation request for arbitrary reasons, a DOTS client from one domain is not able to influence the network
within any limits imposed by business or service level agreements path to another domain. A DOTS server MUST reject requests for
between client and server domains. If a DOTS server refuses a DOTS mitigation of resources not owned by the requesting DOTS client's
client's request for mitigation, the DOTS server MUST include the administrative domain. A DOTS server MAY also refuse a DOTS client's
refusal reason in the server signal sent to the client. mitigation request for arbitrary reasons, within any limits imposed
by business or service level agreements between client and server
domains. If a DOTS server refuses a DOTS client's request for
mitigation, the DOTS server MUST include the refusal reason in the
server signal sent to the client.
A DOTS server is in regular contact with one or more mitigators. If A DOTS server is in regular contact with one or more mitigators. If
a DOTS server accepts a DOTS client's request for help, the DOTS a DOTS server accepts a DOTS client's request for help, the DOTS
server forwards a translated form of that request to the mitigator(s) server forwards a translated form of that request to the mitigator(s)
responsible for scrubbing attack traffic. Note that the form of the responsible for scrubbing attack traffic. Note that the form of the
translated request passed from the DOTS server to the mitigator is translated request passed from the DOTS server to the mitigator is
not in scope: it may be as simple as an alert to mitigator operators, not in scope: it may be as simple as an alert to mitigator operators,
or highly automated using vendor or open application programming or highly automated using vendor or open application programming
interfaces supported by the mitigator. The DOTS server MUST report interfaces supported by the mitigator. The DOTS server MUST report
the actual scope of any mitigation enabled on behalf of a client. the actual scope of any mitigation enabled on behalf of a client.
skipping to change at page 30, line 36 skipping to change at page 30, line 36
[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-requirements] [I-D.ietf-dots-requirements]
Mortensen, A., K, R., and R. Moskowitz, "Distributed Mortensen, A., K, R., and R. Moskowitz, "Distributed
Denial of Service (DDoS) Open Threat Signaling Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-18 (work in Requirements", draft-ietf-dots-requirements-19 (work in
progress), February 2019. 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-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
 End of changes. 6 change blocks. 
18 lines changed or deleted 22 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/