draft-ietf-dots-architecture-06.txt   draft-ietf-dots-architecture-07.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: September 21, 2018 Cisco Expires: March 8, 2019 Cisco
T. Reddy T. Reddy
McAfee, Inc. McAfee, Inc.
C. Gray C. Gray
R. Compton R. Compton
Charter Charter
N. Teague N. Teague
Verisign Verisign
March 20, 2018 September 04, 2018
Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture
draft-ietf-dots-architecture-06 draft-ietf-dots-architecture-07
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 44 skipping to change at page 1, line 44
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 21, 2018. This Internet-Draft will expire on March 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 40 skipping to change at page 10, line 40
mitigation. The mechanism of enforcement is not in scope for this mitigation. The mechanism of enforcement is not in scope for this
document, but is expected to restrict requested mitigation scope to document, but is expected to restrict requested mitigation scope to
addresses, prefixes, and/or services owned by the DOTS client's addresses, prefixes, and/or services owned by the DOTS client's
administrative domain, such that a DOTS client from one domain is not administrative domain, such that a DOTS client from one domain is not
able to influence the network path to another domain. A DOTS server able to influence the network path to another domain. A DOTS server
MUST reject requests for mitigation of resources not owned by the MUST reject requests for mitigation of resources not owned by the
requesting DOTS client's administrative domain. A DOTS server MAY requesting DOTS client's administrative domain. A DOTS server MAY
also refuse a DOTS client's mitigation request for arbitrary reasons, also refuse a DOTS client's mitigation request for arbitrary reasons,
within any limits imposed by business or service level agreements within any limits imposed by business or service level agreements
between client and server domains. If a DOTS server refuses a DOTS between client and server domains. If a DOTS server refuses a DOTS
client's request for mitigation, the DOTS server SHOULD include the client's request for mitigation, the DOTS server MUST include the
refusal reason in the server signal sent to the client. 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
skipping to change at page 20, line 16 skipping to change at page 20, line 16
client-requested mitigation is being overwhelmed by the severity of client-requested mitigation is being overwhelmed by the severity of
the attack. Out-of-scope business or service level agreements may the attack. Out-of-scope business or service level agreements may
permit the mitigating domain to drop the mitigation and let attack permit the mitigating domain to drop the mitigation and let attack
traffic flow unchecked to the target, but this only encourages attack traffic flow unchecked to the target, but this only encourages attack
escalation. In the case where the mitigating domain is the upstream escalation. In the case where the mitigating domain is the upstream
service provider for the attack target, this may mean the mitigating service provider for the attack target, this may mean the mitigating
domain and its other services and users continue to suffer the domain and its other services and users continue to suffer the
incidental effects of the attack. incidental effects of the attack.
A recursive signaling model as shown in Figure 13 offers an A recursive signaling model as shown in Figure 13 offers an
alternative. In a variation of the use case "End-customer with a alternative. In a variation of the use case "Upstream DDoS
single upstream transit provider offering DDoS mitigation services" Mitigation by an Upstream Internet Transit Provider" described in
described in [I-D.ietf-dots-use-cases], a domain operating a DOTS [I-D.ietf-dots-use-cases], a domain operating a DOTS server and
server and mitigator also operates a DOTS client. This DOTS client mitigator also operates a DOTS client. This DOTS client has an
has an established DOTS session with a DOTS server belonging to a established DOTS session with a DOTS server belonging to a separate
separate administrative domain. administrative domain.
With these preconditions in place, the operator of the mitigator With these preconditions in place, the operator of the mitigator
being overwhelmed or otherwise performing inadequately may request being overwhelmed or otherwise performing inadequately may request
mitigation for the attack target from this separate DOTS-aware mitigation for the attack target from this separate DOTS-aware
domain. Such a request recurses the originating mitigation request domain. Such a request recurses the originating mitigation request
to the secondary DOTS server, in the hope of building a cumulative to the secondary DOTS server, in the hope of building a cumulative
mitigation against the attack. mitigation against the attack.
example.net domain example.net domain
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
skipping to change at page 28, line 10 skipping to change at page 28, line 10
To maintain a DOTS session, the DOTS client and the DOTS server To maintain a DOTS session, the DOTS client and the DOTS server
exchange regular but infrequent messages across the signal channel. exchange regular but infrequent messages across the signal channel.
In the absence of an attack, the probability of message loss in the In the absence of an attack, the probability of message loss in the
signaling channel should be extremely low. Under attack conditions, signaling channel should be extremely low. Under attack conditions,
however, some signal loss may be anticipated as attack traffic however, some signal loss may be anticipated as attack traffic
congests the link, depending on the attack type. congests the link, depending on the attack type.
While [I-D.ietf-dots-requirements] specifies the DOTS protocol be While [I-D.ietf-dots-requirements] specifies the DOTS protocol be
robust when signaling under attack conditions, there are nevertheless robust when signaling under attack conditions, there are nevertheless
scenarios in which the DOTS signal is lost in spite of protocol best scenarios in which the DOTS signal is lost in spite of protocol best
efforts. To handle such scenarios, a DOTS operator may configure the efforts. To handle such scenarios, a DOTS operator may request one
DOTS session to trigger mitigation when the DOTS server ceases or more mitigations which are triggered only when the DOTS server
receiving DOTS client signals (or vice versa) beyond the miss count ceases receiving DOTS client heartbeats beyond the miss count or
or period permitted by the protocol. interval permitted by the protocol.
The impact of mitigating due to loss of signal in either direction The impact of mitigating due to loss of signal in either direction
must be considered carefully before enabling it. Signal loss is not must be considered carefully before enabling it. Signal loss is not
caused by links congested with attack traffic alone, and as such caused by links congested with attack traffic alone, and as such
mitigation requests triggered by signal channel degradation in either mitigation requests triggered by signal channel degradation in either
direction may incur unnecessary costs, in network performance and direction may incur unnecessary costs, in network performance and
operational expense alike. operational expense alike.
4. Security Considerations 4. Security Considerations
skipping to change at page 29, line 37 skipping to change at page 29, line 37
[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>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-dots-requirements] [I-D.ietf-dots-requirements]
Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed
Denial of Service (DDoS) Open Threat Signaling Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-14 (work in Requirements", draft-ietf-dots-requirements-15 (work in
progress), February 2018. progress), August 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-09 (work Open Threat Signaling", draft-ietf-dots-use-cases-16 (work
in progress), November 2017. in progress), July 2018.
[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>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
 End of changes. 9 change blocks. 
19 lines changed or deleted 19 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/