< draft-ietf-dots-signal-call-home-12.txt   draft-ietf-dots-signal-call-home-13.txt >
DOTS T. Reddy DOTS T. Reddy
Internet-Draft McAfee Internet-Draft McAfee
Intended status: Standards Track M. Boucadair Intended status: Standards Track M. Boucadair
Expires: June 26, 2021 Orange Expires: July 15, 2021 Orange
J. Shallow J. Shallow
December 23, 2020 January 11, 2021
Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel Call Home Channel Call Home
draft-ietf-dots-signal-call-home-12 draft-ietf-dots-signal-call-home-13
Abstract Abstract
This document specifies the DOTS signal channel Call Home, which This document specifies the DOTS signal channel Call Home, which
enables a Call Home DOTS server to initiate a secure connection to a enables a Call Home DOTS server to initiate a secure connection to a
Call Home DOTS client, and to receive attack traffic information from Call Home DOTS client, and to receive attack traffic information from
the Call Home DOTS client. The Call Home DOTS server in turn uses the Call Home DOTS client. The Call Home DOTS server in turn uses
the attack traffic information to identify compromised devices the attack traffic information to identify compromised devices
launching outgoing DDoS attacks and take appropriate mitigation launching outgoing DDoS attacks and take appropriate mitigation
action(s). action(s).
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 June 26, 2021. This Internet-Draft will expire on July 15, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Applicability Scope . . . . . . . . . . . . . . . . . . . . . 7 3. Applicability Scope . . . . . . . . . . . . . . . . . . . . . 7
4. Co-existence of Base DOTS Signal Channel and DOTS Call Home . 8 4. Co-existence of Base DOTS Signal Channel and DOTS Call Home . 9
5. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 12 5. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 13
5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. DOTS Signal Channel Variations . . . . . . . . . . . . . 14 5.2. DOTS Signal Channel Variations . . . . . . . . . . . . . 15
5.2.1. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 14 5.2.1. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 15
5.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 15 5.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 16
5.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 16 5.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 17
5.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 16 5.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 17
5.3.2. Address Sharing Considerations . . . . . . . . . . . 20 5.3.2. Address Sharing Considerations . . . . . . . . . . . 21
6. DOTS Signal Call Home YANG Module . . . . . . . . . . . . . . 23 6. DOTS Signal Call Home YANG Module . . . . . . . . . . . . . . 24
6.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 23 6.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 24
6.2. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . 24 6.2. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . 25
6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25 6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
7.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 29 7.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 30
7.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 30 7.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 31
7.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 30 7.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 31
7.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 31 7.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.1. Normative References . . . . . . . . . . . . . . . . . . 35 12.1. Normative References . . . . . . . . . . . . . . . . . . 36
12.2. Informative References . . . . . . . . . . . . . . . . . 36 12.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Some Home Network Issues . . . . . . . . . . . . . . 39 Appendix A. Some Home Network Issues . . . . . . . . . . . . . . 40
Appendix B. Disambiguating Base DOTS Signal vs. DOTS Call Home . 41 Appendix B. Disambiguating Base DOTS Signal vs. DOTS Call Home . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
The Distributed Denial-of-Service Open Threat Signaling (DOTS) signal The Distributed Denial-of-Service Open Threat Signaling (DOTS) signal
channel protocol [I-D.ietf-dots-rfc8782-bis] is used to carry channel protocol [I-D.ietf-dots-rfc8782-bis] is used to carry
information about a network resource or a network (or a part thereof) information about a network resource or a network (or a part thereof)
that is under a Distributed Denial of Service (DDoS) attack that is under a Distributed Denial of Service (DDoS) attack
[RFC4732]. Such information is sent by a DOTS client to one or [RFC4732]. Such information is sent by a DOTS client to one or
multiple DOTS servers so that appropriate mitigation actions are multiple DOTS servers so that appropriate mitigation actions are
undertaken on traffic deemed suspicious. Various use cases are undertaken on traffic deemed suspicious. Various use cases are
skipping to change at page 4, line 32 skipping to change at page 4, line 32
subscribers or the ISP may receive filtering rules (e.g., using BGP subscribers or the ISP may receive filtering rules (e.g., using BGP
Flowspec [RFC5575][I-D.ietf-idr-flow-spec-v6]) from a transit Flowspec [RFC5575][I-D.ietf-idr-flow-spec-v6]) from a transit
provider to filter, block, or rate-limit DDoS attack traffic provider to filter, block, or rate-limit DDoS attack traffic
originating from the ISP's subscribers to a downstream target. originating from the ISP's subscribers to a downstream target.
Nevertheless, the DOTS signal channel does not provide means for the Nevertheless, the DOTS signal channel does not provide means for the
ISP to request blocking such attacks close to the sources without ISP to request blocking such attacks close to the sources without
altering legitimate traffic. This document fills that void by altering legitimate traffic. This document fills that void by
specifying an extension to the DOTS signal channel: DOTS signal specifying an extension to the DOTS signal channel: DOTS signal
channel Call Home. channel Call Home.
Note: Another design approach would be to extend the DOTS signal
channel with a new attribute to explicitly indicate whether a
mitigation request is about an outbound DDoS attack. In such an
approach, it is assumed that a DOTS server is deployed within the
domain that is hosting the attack source(s), while a DOTS client
is enabled within an upstream network (e.g., access network).
However, initiating a DOTS signal channel from an upstream network
to a source network is complicated because of the presence of
translators and firewalls. Moreover, the use of the same signal
channel to handle both inbound and outbound attacks complicates
both the heartbeat and redirection mechanisms that are executed as
a function of the attack direction (see Sections 5.2.1 and 5.2.2).
Also, the DOTS server will be subject to fingerprinting (e.g.,
using scanning tools) and DoS attacks (e.g., by having the DOTS
server to perform computationally expensive operations). Various
management and deployment considerations that motivate the Call
Home functionality are listed in Section 1.1 of [RFC8071].
'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers 'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers
to a DOTS signal channel established at the initiative of a DOTS to a DOTS signal channel established at the initiative of a DOTS
server thanks to a role reversal at the (D)TLS layer (Section 5.1). server thanks to a role reversal at the (D)TLS layer (Section 5.1).
That is, the DOTS server initiates a secure connection to a DOTS That is, the DOTS server initiates a secure connection to a DOTS
client, and uses that connection to receive the attack traffic client, and uses that connection to receive the attack traffic
information (e.g., attack sources) from the DOTS client. information (e.g., attack sources) from the DOTS client.
A high-level DOTS Call Home functional architecture is shown in A high-level DOTS Call Home functional architecture is shown in
Figure 2. Attack source(s) are within the DOTS server domain. Figure 2. Attack source(s) are within the DOTS server domain.
Scope Scope
+.-.-.-.-.-.-.-.-.-.-.-.+ +.-.-.-.-.-.-.-.-.-.-.-.+
+---------------+ : +-------------+ : +---------------+ : +-------------+ :
skipping to change at page 6, line 15 skipping to change at page 6, line 22
home network). home network).
The Call Home DOTS server uses the DDoS attack traffic information to The Call Home DOTS server uses the DDoS attack traffic information to
identify the compromised device in its domain that is responsible for identify the compromised device in its domain that is responsible for
launching the DDoS attack, optionally notifies a network launching the DDoS attack, optionally notifies a network
administrator, and takes appropriate mitigation action(s). For administrator, and takes appropriate mitigation action(s). For
example, a mitigation action can be to quarantine the compromised example, a mitigation action can be to quarantine the compromised
device or block its traffic to the attack target(s) until the device or block its traffic to the attack target(s) until the
mitigation request is withdrawn. mitigation request is withdrawn.
Other motivations for introducing the Call Home function are
discussed in Section 1.1 of [RFC8071].
This document assumes that Call Home DOTS servers are provisioned This document assumes that Call Home DOTS servers are provisioned
with a way to know how to reach the upstream Call Home DOTS with a way to know how to reach the upstream Call Home DOTS
client(s), which could occur by a variety of means (e.g., client(s), which could occur by a variety of means (e.g.,
[I-D.ietf-dots-server-discovery]). The specification of such means [I-D.ietf-dots-server-discovery]). The specification of such means
are out of scope of this document. are out of scope of this document.
More information about the applicability scope of the DOTS signal More information about the applicability scope of the DOTS signal
channel Call Home is provided in Section 3. channel Call Home is provided in Section 3.
2. Terminology 2. Terminology
 End of changes. 10 change blocks. 
36 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/