draft-ietf-dots-architecture-05.txt   draft-ietf-dots-architecture-06.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: April 28, 2018 Cisco Expires: September 21, 2018 Cisco
T. Reddy T. Reddy
McAfee, Inc. McAfee, Inc.
C. Gray C. Gray
Comcast
R. Compton R. Compton
Charter Charter
N. Teague N. Teague
Verisign Verisign
October 25, 2017 March 20, 2018
Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture
draft-ietf-dots-architecture-05 draft-ietf-dots-architecture-06
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 April 28, 2018. This Internet-Draft will expire on September 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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
skipping to change at page 2, line 46 skipping to change at page 2, line 46
3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. DOTS Sessions . . . . . . . . . . . . . . . . . . . . . . 16 3.1. DOTS Sessions . . . . . . . . . . . . . . . . . . . . . . 16
3.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 16 3.1.1. Preconditions . . . . . . . . . . . . . . . . . . . . 16
3.1.2. Establishing the DOTS Session . . . . . . . . . . . . 16 3.1.2. Establishing the DOTS Session . . . . . . . . . . . . 16
3.1.3. Maintaining the DOTS Session . . . . . . . . . . . . 17 3.1.3. Maintaining the DOTS Session . . . . . . . . . . . . 17
3.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 18 3.2. Modes of Signaling . . . . . . . . . . . . . . . . . . . 18
3.2.1. Direct Signaling . . . . . . . . . . . . . . . . . . 18 3.2.1. Direct Signaling . . . . . . . . . . . . . . . . . . 18
3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 18 3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 18
3.2.3. Recursive Signaling . . . . . . . . . . . . . . . . . 19 3.2.3. Recursive Signaling . . . . . . . . . . . . . . . . . 19
3.2.4. Anycast Signaling . . . . . . . . . . . . . . . . . . 22 3.2.4. Anycast Signaling . . . . . . . . . . . . . . . . . . 22
3.3. Triggering Requests for Mitigation . . . . . . . . . . . 23 3.2.5. Signaling Considerations for Network Address
3.3.1. Manual Mitigation Request . . . . . . . . . . . . . . 24 Translation . . . . . . . . . . . . . . . . . . . . . 23
3.3.2. Automated Conditional Mitigation Request . . . . . . 25 3.3. Triggering Requests for Mitigation . . . . . . . . . . . 25
3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 26 3.3.1. Manual Mitigation Request . . . . . . . . . . . . . . 26
4. Security Considerations . . . . . . . . . . . . . . . . . . . 26 3.3.2. Automated Conditional Mitigation Request . . . . . . 27
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3.3. Automated Mitigation on Loss of Signal . . . . . . . 27
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 4. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Normative References . . . . . . . . . . . . . . . . . . 27 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
7.2. Informative References . . . . . . . . . . . . . . . . . 27 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 7.1. Normative References . . . . . . . . . . . . . . . . . . 29
7.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Context and Motivation 1. Context and Motivation
Signaling the need for help defending against an active distributed Signaling the need for help defending against an active distributed
denial of service (DDoS) attack requires a common understanding of denial of service (DDoS) attack requires a common understanding of
mechanisms and roles among the parties coordinating defensive mechanisms and roles among the parties coordinating defensive
response. The signaling layer and supplementary messaging is the response. The signaling layer and supplementary messaging is the
focus of DDoS Open Threat Signaling (DOTS). DOTS defines a method of focus of DDoS Open Threat Signaling (DOTS). DOTS defines a method of
coordinating defensive measures among willing peers to mitigate coordinating defensive measures among willing peers to mitigate
attacks quickly and efficiently, enabling hybrid attack responses attacks quickly and efficiently, enabling hybrid attack responses
skipping to change at page 21, line 16 skipping to change at page 21, line 16
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Gn . . Gn .
+----+ 1 . +----+ +-----------+ . +----+ 1 . +----+ +-----------+ .
| Cc |<--------->| Sn |~~~~~~~| Mitigator | . | Cc |<--------->| Sn |~~~~~~~| Mitigator | .
+----+ . +====+ | Mn | . +----+ . +====+ | Mn | .
. | Cn | +-----------+ . . | Cn | +-----------+ .
example.com . +----+ . example.com . +----+ .
client . ^ . client . ^ .
. . .|. . . . . . . . . . . . . . . . .|. . . . . . . . . . . . . .
| |
1 | 2 |
| |
. . .|. . . . . . . . . . . . . . . . .|. . . . . . . . . . . . . .
. v . . v .
. +----+ +-----------+ . . +----+ +-----------+ .
. | So |~~~~~~~| Mitigator | . . | So |~~~~~~~| Mitigator | .
. +----+ | Mo | . . +----+ | Mo | .
. +-----------+ . . +-----------+ .
. . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
example.org domain example.org domain
skipping to change at page 23, line 42 skipping to change at page 23, line 42
Anycast signaling deployments similarly must also take into account Anycast signaling deployments similarly must also take into account
active mitigations. Active mitigations initiated through a DOTS active mitigations. Active mitigations initiated through a DOTS
session may involve diverting traffic to a scrubbing center. If the session may involve diverting traffic to a scrubbing center. If the
DOTS session flaps due to anycast changes as described above, DOTS session flaps due to anycast changes as described above,
mitigation may also flap as the DOTS servers sharing the anycast DOTS mitigation may also flap as the DOTS servers sharing the anycast DOTS
service address toggles mitigation on detecting DOTS session loss, service address toggles mitigation on detecting DOTS session loss,
depending on whether the client has configured mitigation on loss of depending on whether the client has configured mitigation on loss of
signal. signal.
3.2.5. Signaling Considerations for Network Address Translation
Network address translators (NATs) are expected to be a common
feature of DOTS deployments. The Middlebox Traversal Guidelines in
[RFC8085] include general NAT considerations for DOTS deployements
when the signal channel is established over UDP.
Additional DOTS-specific considerations arise when NATs are part of
the DOTS architecture. For example, DDoS attack detection behind a
NAT will detect attacks against internal addresses. A DOTS client
subsequently asked to request mitigation for the attacked scope of
addresses cannot reasonably perform the task, due to the lack of
externally routable addresses in the mitigation scope.
The following considerations do not cover all possible scenarios, but
are meant rather to highlight anticipated common issues when
signaling through NATs.
3.2.5.1. Direct Provisioning of Internal-to-External Address Mappings
Operators may circumvent the problem of translating internal
addresses or prefixes to externally routable mitigation scopes by
directly provisioning the mappings of external addresses to internal
protected resources on the DOTS client. When the operator requests
mitigation scoped for internal addresses, directly or through
automated means, the DOTS client looks up the matching external
addresses or prefixes, and issues a mitigation request scoped to that
externally routable information.
When directly provisioning the address mappings, operators must
ensure the mappings remain up to date, or risk losing the ability to
request accurate mitigation scopes. This document does not prescribe
the method by which mappings are maintained once they are provisioned
on the DOTS client.
3.2.5.2. Resolving Public Mitigation Scope with Session Traversal
Utilities (STUN)
Internal resources may discover their external address through a STUN
Binding request/response transaction, as described in [RFC5389].
After learning its reflexive transport address from the STUN server,
the internal service can export its external/internal address pair to
the DOTS client, allowing the DOTS client to request mitigation with
the correct external scope, as depicted in Figure 14. The mechanism
for provisioning the DOTS client with the address pair is
unspecified.
Binding Binding
+--------+ request +---+ request +--------+
| STUN |<----------| N |<----------| STUN |
| server | | A | | client |
| |---------->| T |---------->| |
+--------+ Binding +---+ Binding +--------+
response response |
| external/internal
| address pair
v
+--------+
| DOTS |
| client |
+--------+
Figure 14: Resolving mitigation scope with STUN
3.2.5.3. Resolving Requested Mitigation Scope with DNS
DOTS supports mitigation scoped to DNS names. As discussed in
[RFC3235], using DNS names instead of IP addresses potentially avoids
the address translation problem, as long as the name is internally
and externally resolvable by the same name. For example, a detected
attack's internal target address can be mapped to a DNS name through
a reverse lookup. The DNS name returned by the reverse lookup can
then be provided to the DOTS client as the external scope for
mitigation.
3.3. Triggering Requests for Mitigation 3.3. Triggering Requests for Mitigation
[I-D.ietf-dots-requirements] places no limitation on the [I-D.ietf-dots-requirements] places no limitation on the
circumstances in which a DOTS client operator may request mitigation, circumstances in which a DOTS client operator may request mitigation,
nor does it demand justification for any mitigation request, thereby nor does it demand justification for any mitigation request, thereby
reserving operational control over DDoS defense for the domain reserving operational control over DDoS defense for the domain
requesting mitigation. This architecture likewise does not prescribe requesting mitigation. This architecture likewise does not prescribe
the network conditions and mechanisms triggering a mitigation request the network conditions and mechanisms triggering a mitigation request
from a DOTS client. from a DOTS client.
skipping to change at page 27, line 46 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-06 (work in Requirements", draft-ietf-dots-requirements-14 (work in
progress), July 2017. progress), February 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-07 (work Open Threat Signaling", draft-ietf-dots-use-cases-09 (work
in progress), July 2017. in progress), November 2017.
[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
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000, DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>. <https://www.rfc-editor.org/info/rfc2782>.
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235,
DOI 10.17487/RFC3235, January 2002,
<https://www.rfc-editor.org/info/rfc3235>.
[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>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
skipping to change at page 29, line 5 skipping to change at page 30, line 44
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <https://www.rfc-editor.org/info/rfc4786>. December 2006, <https://www.rfc-editor.org/info/rfc4786>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/info/rfc5389>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[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,
<https://www.rfc-editor.org/info/rfc7092>. <https://www.rfc-editor.org/info/rfc7092>.
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
"Architectural Considerations of IP Anycast", RFC 7094, "Architectural Considerations of IP Anycast", RFC 7094,
DOI 10.17487/RFC7094, January 2014, DOI 10.17487/RFC7094, January 2014,
<https://www.rfc-editor.org/info/rfc7094>. <https://www.rfc-editor.org/info/rfc7094>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
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: amortensen@arbor.net EMail: amortensen@arbor.net
skipping to change at page 30, line 5 skipping to change at page 32, line 5
EMail: fandreas@cisco.com EMail: fandreas@cisco.com
Tirumaleswar Reddy Tirumaleswar Reddy
McAfee, Inc. McAfee, Inc.
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore, Karnataka 560071 Bangalore, Karnataka 560071
India India
EMail: tireddy@cisco.com EMail: tireddy@cisco.com
Christopher Gray Christopher Gray
Comcast
United States United States
EMail: Christopher_Gray3@cable.comcast.com EMail: Christopher_Gray3@cable.comcast.com
Rich Compton Rich Compton
Charter Charter
EMail: Rich.Compton@charter.com EMail: Rich.Compton@charter.com
Nik Teague Nik Teague
 End of changes. 15 change blocks. 
23 lines changed or deleted 113 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/