draft-ietf-dots-signal-call-home-01.txt   draft-ietf-dots-signal-call-home-02.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: October 28, 2019 Orange Expires: December 2, 2019 Orange
J. Shallow J. Shallow
April 26, 2019 May 31, 2019
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-01 draft-ietf-dots-signal-call-home-02
Abstract Abstract
This document specifies the DOTS signal channel Call Home service, This document specifies the DOTS signal channel Call Home service,
which enables a DOTS server to initiate a secure connection to a DOTS which enables a DOTS server to initiate a secure connection to a DOTS
client, and to receive the attack traffic information from the DOTS client, and to receive the attack traffic information from the DOTS
client. The DOTS server in turn uses the attack traffic information client. The DOTS server in turn uses the attack traffic information
to identify the compromised devices launching the outgoing DDoS to identify the compromised devices launching the outgoing DDoS
attack and takes appropriate mitigation action(s). attack and takes appropriate mitigation action(s).
The Call Home service is not specific to the home networks; the The DOTS Call Home service is not specific to the home networks; the
solution targets any deployment which requires to block DDoS attack solution targets any deployment which requires to block DDoS attack
traffic closer to the source(s) of a DDoS attack. traffic closer to the source(s) of a DDoS attack.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 28, 2019. This Internet-Draft will expire on December 2, 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 2, line 21 skipping to change at page 2, line 21
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 4 1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5 1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5
2. Notational Conventions and Terminology . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 7 3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 7
3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. DOTS Signal Channel Extension . . . . . . . . . . . . . . 8 3.2. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 8
3.2.1. Mitigation Request . . . . . . . . . . . . . . . . . 8 3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 9
3.2.2. DOTS Signal Call Home YANG Module . . . . . . . . . . 12 3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 3.3.2. DOTS Signal Call Home YANG Module . . . . . . . . . . 14
4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 16 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 16 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 17
4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 16 4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 17
4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 17 4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 18
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
1.1. The Problem 1.1. The Problem
The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is
used to carry information about a network resource or a network (or a used to carry information about a network resource or a network (or a
part thereof) that is under a Distributed Denial of Service (DDoS) part thereof) that is under a Distributed Denial of Service (DDoS)
attack. Such information is sent by a DOTS client to one or multiple attack. Such information is sent by a DOTS client to one or multiple
DOTS servers so that appropriate mitigation actions are undertaken on DOTS servers so that appropriate mitigation actions are undertaken on
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Internet of Things (IoT) devices are becoming more and more prevalent Internet of Things (IoT) devices are becoming more and more prevalent
in home networks, and with compute and memory becoming cheaper and in home networks, and with compute and memory becoming cheaper and
cheaper, various types of IoT devices become available in the cheaper, various types of IoT devices become available in the
consumer market at affordable price. But on the downside, the main consumer market at affordable price. But on the downside, the main
threat being most of these IoT devices are bought off-the-shelf and threat being most of these IoT devices are bought off-the-shelf and
most manufacturers haven't considered security in the product design. most manufacturers haven't considered security in the product design.
IoT devices deployed in home networks can be easily compromised, they IoT devices deployed in home networks can be easily compromised, they
do not have an easy mechanism to upgrade, and IoT manufactures may do not have an easy mechanism to upgrade, and IoT manufactures may
cease manufacture and/or discontinue patching vulnerabilities on IoT cease manufacture and/or discontinue patching vulnerabilities on IoT
devices (Sections 5.4 and 5.5 of [I-D.irtf-t2trg-iot-seccons]). devices (Sections 5.4 and 5.5 of [RFC8576]). However, these
However, these vulnerable and compromised devices will continue to be vulnerable and compromised devices will continue to be used for a
used for a long period of time in the home, and the end-user does not long period of time in the home, and the end-user does not know that
know that IoT devices in his/her home are compromised. The IoT devices in his/her home are compromised. The compromised IoT
compromised IoT devices are typically used for launching DDoS attacks devices are typically used for launching DDoS attacks (Section 3 of
(Section 3 of [I-D.irtf-t2trg-iot-seccons]) on victims while the [RFC8576]) on victims while the owner/administrator of the home
owner/administrator of the home network is not aware about such network is not aware about such misbehaviors. Similar to other DDoS
misbehaviors. Similar to other DDoS attacks, the victim in this attacks, the victim in this attack can be an application server, a
attack can be an application server, a host, a router, a firewall, or host, a router, a firewall, or an entire network.
an entire network.
Nowadays, network devices in a home network offer network security Nowadays, network devices in a home network offer network security
(e.g., firewall or Intrusion Protection System (IPS) service on a (e.g., firewall or Intrusion Protection System (IPS) service on a
home router) to protect the devices connected to the home network home router) to protect the devices connected to the home network
from both external and internal attacks. Over the years several from both external and internal attacks. Over the years several
techniques have been identified to detect DDoS attacks, some of these techniques have been identified to detect DDoS attacks, some of these
techniques can be enabled on home network devices but most of them techniques can be enabled on home network devices but most of them
are used in the Internet Service Provider (ISP)'s network. The ISP are used in the Internet Service Provider (ISP)'s network. The ISP
offering DDoS mitigation service can detect outgoing DDoS attack offering DDoS mitigation service can detect outgoing DDoS attack
traffic originating from its subscribers or the ISP may receive traffic originating from its subscribers or the ISP may receive
skipping to change at page 7, line 5 skipping to change at page 7, line 5
| || | ||
+-----+-++----+ +-----+-++----+
|Attack Source| |Attack Source|
+-------------+ +-------------+
Figure 1: Call Home Reference Architecture Figure 1: Call Home Reference Architecture
It is out of the scope of this document to identify an exhaustive It is out of the scope of this document to identify an exhaustive
list of such deployments. list of such deployments.
2. Notational Conventions and Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The reader should be familiar with the terms defined in The reader should be familiar with the terms defined in
[I-D.ietf-dots-requirements]. [I-D.ietf-dots-requirements].
skipping to change at page 8, line 40 skipping to change at page 8, line 40
different port number. Using this TCP connection, the DOTS different port number. Using this TCP connection, the DOTS
server initiates a TLS connection to the DOTS client. server initiates a TLS connection to the DOTS client.
The Happy Eyeballs mechanism explained in Section 4.3 of The Happy Eyeballs mechanism explained in Section 4.3 of
[I-D.ietf-dots-signal-channel] can be used for initiating (D)TLS [I-D.ietf-dots-signal-channel] can be used for initiating (D)TLS
connections. connections.
2. Using this (D)TLS connection, the DOTS client may request, 2. Using this (D)TLS connection, the DOTS client may request,
withdraw, or retrieve the status of mitigation requests. withdraw, or retrieve the status of mitigation requests.
3.2. DOTS Signal Channel Extension 3.2. Heartbeat Mechanism
3.2.1. Mitigation Request The Heartbeat mechanism used for the Call Home deviates from the one
defined in Section 4.7 of [I-D.ietf-dots-signal-channel]. This
section specifies the behavior to be followed by DOTS agents for the
Call Home.
Once the (D)TLS section is established between the DOTS agents, the
DOTS client contacts the DOTS server to retrieve the session
configuration parameters (Section 4.5 of
[I-D.ietf-dots-signal-channel]). The DOTS server adjusts the
'heartbeat-interval' to accommodate binding timers used by on-path
NATs and firewalls. Heartbeats will be then exchanged by the DOTS
agents following the instructions retrieved using the signal channel
session configuration exchange.
It is the responsibility of DOTS servers to ensure that on-path
translators/firewalls are maintaining a binding so that the same
external IP address and/or port number is retained for the DOTS
signal channel session. A DOTS client MAY trigger their heartbeat
requests immediately after receiving heartbeat probes from its peer
DOTS server.
When an outgoing attack that saturates the outgoing link from the
DOTS server is detected and reported by a DOTS client, the latter
MUST continue to use the signal channel even if no traffic is
received from the DOTS server. It is most likely that the outgoing
traffic is exceeding the DOTS server domain capacity. As a reminder,
the DOTS client cannot initiate a (D)TLS connection.
If the DOTS server receives traffic from the DOTS client, the DOTS
server MUST continue to use the signal channel even if the missing
heartbeat allowed threshold is reached.
If the DOTS server does not receive any traffic from the peer DOTS
client, the DOTS server sends heartbeat requests to the DOTS client
and after maximum 'missing-hb-allowed' threshold is reached, the DOTS
server concludes the session is disconnected. Then, the DOTS server
MUST try to resume the (D)TLS session.
3.3. DOTS Signal Channel Extension
3.3.1. Mitigation Request
This specification extends the mitigation request defined in This specification extends the mitigation request defined in
Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the
attacker source prefixes and source port numbers. The DOTS client attacker source prefixes and source port numbers. The DOTS client
conveys the following new parameters in the CBOR body of the conveys the following new parameters in the CBOR body of the
mitigation request: mitigation request:
source-prefix: A list of attacker prefixes used to attack the source-prefix: A list of attacker prefixes used to attack the
target. Prefixes are represented using Classless Inter-Domain target. Prefixes are represented using Classless Inter-Domain
Routing (CIDR) notation [RFC4632]. Routing (CIDR) notation [RFC4632].
skipping to change at page 10, line 5 skipping to change at page 10, line 45
information because 'target-uri' and 'target-fqdn' are optional information because 'target-uri' and 'target-fqdn' are optional
attributes and 'alias-name' will not be conveyed in a mitigation attributes and 'alias-name' will not be conveyed in a mitigation
request. request.
In order to help attack source identification by a DOTS server, the In order to help attack source identification by a DOTS server, the
DOTS client SHOULD include in its mitigation request additional DOTS client SHOULD include in its mitigation request additional
information such as 'source-port-range' or 'source-icmp-type-range'. information such as 'source-port-range' or 'source-icmp-type-range'.
The DOTS client may not include such information if 'source-prefix' The DOTS client may not include such information if 'source-prefix'
conveys an IPv6 address/prefix. conveys an IPv6 address/prefix.
Only immediate mitigation requests (i.e., 'trigger-mitigation' set to
'true') are allowed; DOTS clients MUST NOT send requests with
'trigger-mitigation' set to 'false'. Such requests MUST be discarded
by the DOTS server with a 4.00 (Bad Request).
If a Carrier Grade NAT (CGN, including NAT64) is located between the If a Carrier Grade NAT (CGN, including NAT64) is located between the
DOTS client domain and DOTS server domain, communicating an external DOTS client domain and DOTS server domain, communicating an external
IP address in a mitigation request is likely to be discarded by the IP address in a mitigation request is likely to be discarded by the
DOTS server because the external IP address is not visible locally to DOTS server because the external IP address is not visible locally to
the DOTS server (see Figure 3). The DOTS server is only aware of the the DOTS server (see Figure 3). The DOTS server is only aware of the
internal IP addresses/prefixes bound to its domain. Thus, the DOTS internal IP addresses/prefixes bound to its domain. Thus, the DOTS
client MUST NOT include the external IP address and/or port number client MUST NOT include the external IP address and/or port number
identifying the suspect attack source, but MUST include the internal identifying the suspect attack source, but MUST include the internal
IP address and/or port number. To that aim, the DOTS client SHOULD IP address and/or port number. To that aim, the DOTS client SHOULD
rely on mechanisms, such as [RFC8512] or [RFC8513], to retrieve the rely on mechanisms, such as [RFC8512] or [RFC8513], to retrieve the
internal IP address and port number which are mapped to an external internal IP address and port number which are mapped to an external
IP address and port number. IP address and port number.
N | .-------------------. N | .-------------------.
E | ( )-. E | ( )-.
T | .' ' T | .' '
W | ( ) W | ( )
O | ( DOTS server -' O | ( DOTS client -'
R | '-( ) R | '-( )
K | '-------+-----------' K | '-------+-----------'
| | | |
P | | P | |
R | +---+---+ R | +---+---+
O | | CGN | External Realm O | | CGN | External Realm
V |..............|.......|...................... V |..............| |......................
I | | | Internel Realm I | | | Internal Realm
D | +---+---+ D | +---+---+
E | | E | |
R | | R | |
--- | --- |
.---------+---------. .---------+---------.
( )-. ( )-.
.' Source Network ' .' Source Network '
( ) ( )
( DOTS client -' ( DOTS server -'
'-( ) '-( )
'------+------------' '------+------------'
| |
+-----+-------+ +-----+-------+
|Attack Source| |Attack Source|
+-------------+ +-------------+
Figure 3: Example of a CGN Between DOTS Domains Figure 3: Example of a CGN between DOTS Domains
If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the
provider's domain to service its customers, the identification of an provider's domain to service its customers, the identification of an
attack source bound to an IPv4 address/prefix MUST also rely on attack source bound to an IPv4 address/prefix MUST also rely on
source port numbers because the same IPv4 address is assigned to source port numbers because the same IPv4 address is assigned to
multiple customers. The port information is required to multiple customers. The port information is required to
unambiguously identify the source of an attack. unambiguously identify the source of an attack.
The DOTS server MUST check that the 'source-prefix' is within the The DOTS server MUST check that the 'source-prefix' is within the
scope of the DOTS server domain in the Call Home scenario. Note that scope of the DOTS server domain in the Call Home scenario. Note that
in such scenario, the DOTS server considers, by default, that any in such scenario, the DOTS server considers, by default, that any
routeable IP prefix enclosed in 'target-prefix' is within the scope routeable IP prefix enclosed in 'target-prefix' is within the scope
of the DOTS client. Invalid mitigation requests are handled as per of the DOTS client. Invalid mitigation requests are handled as per
Section 4.4.1 of [I-D.ietf-dots-signal-channel]. Section 4.4.1 of [I-D.ietf-dots-signal-channel].
If a translator is enabled on the boundaries of the domain hosting If a translator is enabled on the boundaries of the domain hosting
the DOTS server (a CPE with NAT enabled as shown in Figure 4, the DOTS server (e.g., a CPE with NAT enabled as shown in Figures 4
typically), the DOTS server uses the attack traffic information and 5), the DOTS server uses the attack traffic information conveyed
conveyed in a mitigation request to find the internal source IP in a mitigation request to find the internal source IP address of the
address of the compromised device and blocks the traffic from the compromised device and blocks the traffic from the compromised device
compromised device traffic to the attack target until the mitigation traffic to the attack target until the mitigation request is
request is withdrawn. Doing so allows to isolate the suspicious withdrawn. Doing so allows to isolate the suspicious device while
device while avoiding to disturb other services. avoiding to disturb other services.
.-------------------. .-------------------.
( )-. ( )-.
.' Network Provider ' .' Network Provider '
( (DMS) ) ( (DMS) )
( DOTS server -' ( DOTS client -'
'-( ) '-( )
'------+------------' '------+------------'
| |
| |
--- +--+----+ --- +--+----+
S | | CPE | External Realm S | | CPE | External Realm
O |..............|.......|................ O |..............| |................
U | | NAT | Internel Realm U | | NAT | Internal Realm
R | +-------+ R | +-------+
C | | C | |
E | .--------+----------. E | .--------+----------.
| ( )-. | ( )-.
N | .' ' N | .' '
E | ( ) E | ( )
T | ( DOTS client -' T | ( DOTS server -'
W | '-( ) W | '-( )
O | '------+------------' O | '------+------------'
R | | R | |
K | +-----+-------+ K | +-----+-------+
| |Attack Source| | |Attack Source|
+-------------+ +-------------+
Figure 4: Example of a DOTS Client Domain with a NAT Embeded in a CPE Figure 4: Example of a DOTS Server Domain with a NAT Embeded in a CPE
.-------------------.
( )-.
.' Network Provider '
( (DMS) )
( DOTS client -'
'-( )
'---------+---------'
|
|
--- +-----+-----+
S | | CPE/NAT | External Realm
O |..............| |................
U | |DOTS server| Internal Realm
R | +-----------+
C | |
E | .--------+----------.
| ( )-.
N | .' '
E | ( Local Area Network )
T | ( -'
W | '-( )
O | '------+------------'
R | |
K | +-----+-------+
| |Attack Source|
+-------------+
Figure 5: Example of a DOTS Server and a NAT Embeded in a CPE
The DOTS server domain administrator consent MAY be required to block The DOTS server domain administrator consent MAY be required to block
the traffic from the compromised device to the attack target. An the traffic from the compromised device to the attack target. An
implementation MAY have a configuration knob to block the traffic implementation MAY have a configuration knob to block the traffic
from the compromised device to the attack target with or without DOTS from the compromised device to the attack target with or without DOTS
server domain administrator consent. If the attack traffic is server domain administrator consent. If the attack traffic is
blocked, the DOTS server informs the DOTS client that the attack is blocked, the DOTS server informs the DOTS client that the attack is
being mitigated. being mitigated.
If the attack traffic information is identified by the DOTS server or If the attack traffic information is identified by the DOTS server or
the DOTS server domain administrator as legitimate traffic, the the DOTS server domain administrator as legitimate traffic, the
skipping to change at page 12, line 35 skipping to change at page 14, line 17
The DOTS client is informed about the progress of the attack The DOTS client is informed about the progress of the attack
mitigation following the rules in [I-D.ietf-dots-signal-channel]. mitigation following the rules in [I-D.ietf-dots-signal-channel].
For example, if the DOTS server is embedded in a CPE, it can program For example, if the DOTS server is embedded in a CPE, it can program
the packet processor to punt all the traffic from the compromised the packet processor to punt all the traffic from the compromised
device to the target to slow path. The CPE inspects the punted slow device to the target to slow path. The CPE inspects the punted slow
path traffic to detect and block the outgoing DDoS attack traffic or path traffic to detect and block the outgoing DDoS attack traffic or
quarantine the device (e.g., using MAC level filtering) until it is quarantine the device (e.g., using MAC level filtering) until it is
remediated, and notifies the CPE administrator about the compromised remediated, and notifies the CPE administrator about the compromised
device. device.
3.2.2. DOTS Signal Call Home YANG Module 3.3.2. DOTS Signal Call Home YANG Module
3.2.2.1. Tree Structure 3.3.2.1. Tree Structure
This document augments the "dots-signal-channel" DOTS signal YANG This document augments the "dots-signal-channel" DOTS signal YANG
module defined in [I-D.ietf-dots-signal-channel] for signaling the module defined in [I-D.ietf-dots-signal-channel] for signaling the
attack traffic information. This document defines the YANG module attack traffic information. This document defines the YANG module
"ietf-dots-call-home", which has the following tree structure: "ietf-dots-call-home", which has the following tree structure:
module: ietf-dots-call-home module: ietf-dots-call-home
augment /ietf-signal:dots-signal/ietf-signal:message-type augment /ietf-signal:dots-signal/ietf-signal:message-type
/ietf-signal:mitigation-scope/ietf-signal:scope: /ietf-signal:mitigation-scope/ietf-signal:scope:
+--rw source-prefix* inet:ip-prefix {source-signaling}? +--rw source-prefix* inet:ip-prefix {source-signaling}?
+--rw source-port-range* [lower-port] {source-signaling}? +--rw source-port-range* [lower-port] {source-signaling}?
| +--rw lower-port inet:port-number | +--rw lower-port inet:port-number
| +--rw upper-port? inet:port-number | +--rw upper-port? inet:port-number
+--rw source-icmp-type-range* +--rw source-icmp-type-range*
| [lower-type] {source-signaling}? | [lower-type] {source-signaling}?
+--rw lower-type uint8 +--rw lower-type uint8
+--rw upper-type? uint8 +--rw upper-type? uint8
3.2.2.2. YANG Module 3.3.2.2. YANG Module
This module uses the common YANG types defined in [RFC6991]. This module uses the common YANG types defined in [RFC6991].
<CODE BEGINS> file "ietf-dots-call-home@2019-04-25.yang" <CODE BEGINS> file "ietf-dots-call-home@2019-04-25.yang"
module ietf-dots-call-home { module ietf-dots-call-home {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home"; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home";
prefix call-home; prefix call-home;
skipping to change at page 13, line 46 skipping to change at page 15, line 19
"RFC YYYY: Distributed Denial-of-Service Open Threat "RFC YYYY: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
} }
organization organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group"; "IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/dots/> "WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org> WG List: <mailto:dots@ietf.org>
Editor: Konda, Tirumaleswar Reddy Author: Konda, Tirumaleswar Reddy
<mailto:TirumaleswarReddy_Konda@McAfee.com>; <mailto:TirumaleswarReddy_Konda@McAfee.com>;
Editor: Mohamed Boucadair Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>; <mailto:mohamed.boucadair@orange.com>;
Editor: Jon Shallow Author: Jon Shallow
<mailto:ietf-supjps@jpshallow.com>"; <mailto:ietf-supjps@jpshallow.com>";
description description
"This module contains YANG definitions for the signaling "This module contains YANG definitions for the signaling
messages exchanged between a DOTS client and a DOTS server messages exchanged between a DOTS client and a DOTS server
for the Call Home deployment scenario. for the Call Home deployment scenario.
Copyright (c) 2019 IETF Trust and the persons identified as Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
skipping to change at page 17, line 37 skipping to change at page 19, line 14
Name: ietf-call-home Name: ietf-call-home
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home
Maintained by IANA: N Maintained by IANA: N
Prefix: call-home Prefix: call-home
Reference: RFC XXXX Reference: RFC XXXX
5. Security Considerations 5. Security Considerations
This document deviates from classic DOTS signal channel usage by This document deviates from classic DOTS signal channel usage by
having the DOTS server initiate the TLS or DTLS connection. DOTS having the DOTS server initiate the (D)TLS connection. DOTS signal
signal channel related security considerations discussed in channel related security considerations discussed in Section 10 of
Section 10 of [I-D.ietf-dots-signal-channel] MUST be considered. [I-D.ietf-dots-signal-channel] MUST be considered. DOTS agents MUST
DOTS agents MUST authenticate each other using (D)TLS before a DOTS authenticate each other using (D)TLS before a DOTS signal channel
signal channel session is considered valid. session is considered valid.
An attacker may launch a DoS attack on the DOTS client by having it An attacker may launch a DoS attack on the DOTS client by having it
perform computationally expensive operations, before deducing that perform computationally expensive operations, before deducing that
the attacker doesn't possess a valid key. For instance, in TLS 1.3 the attacker doesn't possess a valid key. For instance, in TLS 1.3
[RFC8446], the ServerHello message contains a Key Share value based [RFC8446], the ServerHello message contains a Key Share value based
on an expensive asymmetric key operation for key establishment. on an expensive asymmetric key operation for key establishment.
Common precautions mitigating DoS attacks are recommended, such as Common precautions mitigating DoS attacks are recommended, such as
temporarily blacklisting the source address after a set number of temporarily blacklisting the source address after a set number of
unsuccessful authentication attempts. unsuccessful authentication attempts.
DOTS servers may not blindly trust mitigation requests from DOTS DOTS servers may not blindly trust mitigation requests from DOTS
clients. For example, DOTS servers can use the attack flow clients. For example, DOTS servers can use the attack flow
information in a mitigation request to enable full-fledged packet information in a mitigation request to enable full-fledged packet
inspection function to inspect all the traffic from the compromised inspection function to inspect all the traffic from the compromised
to the target or to re-direct the traffic from the compromised device to the target or to re-direct the traffic from the compromised device
to the target to a DDoS mitigation system to scrub the suspicious to the target to a DDoS mitigation system to scrub the suspicious
traffic. DOTS servers can also seek the consent of DOTS server traffic. DOTS servers can also seek the consent of DOTS server
domain administrator to block the traffic from the compromised device domain administrator to block the traffic from the compromised device
to the target (see Section 3.2.1). to the target (see Section 3.3.1).
6. Privacy Considerations 6. Privacy Considerations
The considerations discussed in [RFC6973] were taken into account to The considerations discussed in [RFC6973] were taken into account to
assess whether the DOTS Call Home extension introduces privacy assess whether the DOTS Call Home extension introduces privacy
threats. threats.
Concretely, the protocol does not leak any new information that can Concretely, the protocol does not leak any new information that can
be used to ease surveillance. In particular, the DOTS server is not be used to ease surveillance. In particular, the DOTS server is not
required to share information that is local to its network (e.g., required to share information that is local to its network (e.g.,
skipping to change at page 18, line 45 skipping to change at page 20, line 20
The DOTS Call Home extension is only advisory in nature. Concretely, The DOTS Call Home extension is only advisory in nature. Concretely,
the DOTS Call Home extension does not impose any action to be the DOTS Call Home extension does not impose any action to be
enforced within the home network; it is up to the DOTS server (and/or enforced within the home network; it is up to the DOTS server (and/or
network administrator) to decide whether and which actions are network administrator) to decide whether and which actions are
required. required.
Moreover, the DOTS Call Home extension avoids misattribution by Moreover, the DOTS Call Home extension avoids misattribution by
appropriately identifying the network to which a suspect attack appropriately identifying the network to which a suspect attack
source belongs to (e.g., address sharing issues discussed in source belongs to (e.g., address sharing issues discussed in
Section 3.2.1). Section 3.3.1).
Triggers to send a DOTS mitigation request to a DOTS server are Triggers to send a DOTS mitigation request to a DOTS server are
deployment-specific. For example, a DOTS client may rely on the deployment-specific. For example, a DOTS client may rely on the
output of some DDoS detection systems deployed within the DOTS client output of some DDoS detection systems deployed within the DOTS client
domain to detect potential outbound DDoS attacks or on abuse claims domain to detect potential outbound DDoS attacks or on abuse claims
received from remote victim networks. Such DDoS detection and received from remote victim networks. Such DDoS detection and
mitigation techniques are not meant to track the activity of users, mitigation techniques are not meant to track the activity of users,
but to protect the Internet and avoid altering the IP reputation of but to protect the Internet and avoid altering the IP reputation of
the DOTS client domain. the DOTS client domain.
skipping to change at page 19, line 32 skipping to change at page 21, line 13
Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments. Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-dots-signal-channel] [I-D.ietf-dots-signal-channel]
K, R., Boucadair, M., Patil, P., Mortensen, A., and N. K, R., Boucadair, M., Patil, P., Mortensen, A., and N.
Teague, "Distributed Denial-of-Service Open Threat Teague, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification", draft- Signaling (DOTS) Signal Channel Specification", draft-
ietf-dots-signal-channel-31 (work in progress), March ietf-dots-signal-channel-34 (work in progress), May 2019.
2019.
[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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 20, line 32 skipping to change at page 22, line 12
Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01 Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01
(work in progress), January 2019. (work in progress), January 2019.
[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-22 (work in Requirements", draft-ietf-dots-requirements-22 (work in
progress), March 2019. progress), March 2019.
[I-D.ietf-dots-server-discovery] [I-D.ietf-dots-server-discovery]
Boucadair, M., K, R., and P. Patil, "Distributed-Denial- Boucadair, M. and R. K, "Distributed-Denial-of-Service
of-Service Open Threat Signaling (DOTS) Server Discovery", Open Threat Signaling (DOTS) Server Discovery", draft-
draft-ietf-dots-server-discovery-01 (work in progress), ietf-dots-server-discovery-03 (work in progress), May
April 2019. 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.irtf-t2trg-iot-seccons]
Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of-
the-Art and Challenges for the Internet of Things
Security", draft-irtf-t2trg-iot-seccons-16 (work in
progress), December 2018.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006, DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>. <https://www.rfc-editor.org/info/rfc4340>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <https://www.rfc-editor.org/info/rfc4632>. 2006, <https://www.rfc-editor.org/info/rfc4632>.
skipping to change at page 22, line 22 skipping to change at page 23, line 41
Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513,
DOI 10.17487/RFC8513, January 2019, DOI 10.17487/RFC8513, January 2019,
<https://www.rfc-editor.org/info/rfc8513>. <https://www.rfc-editor.org/info/rfc8513>.
[RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C.
Jacquenet, "An Inventory of Transport-Centric Functions Jacquenet, "An Inventory of Transport-Centric Functions
Provided by Middleboxes: An Operator Perspective", Provided by Middleboxes: An Operator Perspective",
RFC 8517, DOI 10.17487/RFC8517, February 2019, RFC 8517, DOI 10.17487/RFC8517, February 2019,
<https://www.rfc-editor.org/info/rfc8517>. <https://www.rfc-editor.org/info/rfc8517>.
Authors' Addresses [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of
Things (IoT) Security: State of the Art and Challenges",
RFC 8576, DOI 10.17487/RFC8576, April 2019,
<https://www.rfc-editor.org/info/rfc8576>.
Authors' Addresses
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: kondtir@gmail.com Email: kondtir@gmail.com
Mohamed Boucadair Mohamed Boucadair
Orange Orange
 End of changes. 35 change blocks. 
78 lines changed or deleted 149 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/