draft-ietf-dots-signal-call-home-05.txt   draft-ietf-dots-signal-call-home-06.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: January 31, 2020 Orange Expires: March 13, 2020 Orange
J. Shallow J. Shallow
July 30, 2019 September 10, 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-05 draft-ietf-dots-signal-call-home-06
Abstract Abstract
This document specifies the DOTS signal channel Call Home, which This document specifies the DOTS signal channel Call Home, which
enables a DOTS server to initiate a secure connection to a DOTS 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).
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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 January 31, 2020. This Internet-Draft will expire on March 13, 2020.
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 45 skipping to change at page 2, line 45
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
1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 5 1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 6 1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 6
1.4. Co-existence of Base DOTS Signal Channel & DOTS Call Home 7 1.4. Co-existence of Base DOTS Signal Channel & DOTS Call Home 8
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 12 3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 12
3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 13 3.2. DOTS Signal Channel Variations . . . . . . . . . . . . . 13
3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 14 3.2.1. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 13
3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 14 3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 14
3.3.2. Address Sharing Considerations . . . . . . . . . . . 17 3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 15
3.3.3. DOTS Signal Call Home YANG Module . . . . . . . . . . 20 3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 15
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 3.3.2. Address Sharing Considerations . . . . . . . . . . . 18
4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 24 3.3.3. DOTS Signal Call Home YANG Module . . . . . . . . . . 21
4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 24 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 25 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 25
4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 26 4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 26
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 27
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 28
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . 29 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home . . 31 9.1. Normative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 9.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
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 [RFC4732]. Such information is sent by a DOTS client to one attack [RFC4732]. Such information is sent by a DOTS client to one
or multiple DOTS servers so that appropriate mitigation actions are or multiple DOTS servers so that appropriate mitigation actions are
skipping to change at page 5, line 39 skipping to change at page 5, line 41
A high-level DOTS Call Home functional architecture is shown in A high-level DOTS Call Home functional architecture is shown in
Figure 1. Attack source(s) are within the DOTS server domain. Figure 1. Attack source(s) are within the DOTS server domain.
Scope Scope
+.-.-.-.-.-.-.-.-.-.-.-.+ +.-.-.-.-.-.-.-.-.-.-.-.+
+---------------+ : +-------------+ : +---------------+ : +-------------+ :
| Alert/DMS/ | ~~~:~~~ | Call Home | : | Alert/DMS/ | ~~~:~~~ | Call Home | :
| Peer DMS/... | : | DOTS client | : | Peer DMS/... | : | DOTS client | :
+---------------+ : +------+------+ : +---------------+ : +------+------+ :
: | : : | :
: | : : | :
: | : : | :
+---------------+ : +------+------+ : +---------------+ : +------+------+ :
| Attack | ~~~:~~~ | Call Home | : | Attack | ~~~:~~~ | Call Home | :
| Source(s) | : | DOTS server | : | Source(s) | : | DOTS server | :
+---------------+ : +-------------+ : +---------------+ : +-------------+ :
+.-.-.-.-.-.-.-.-.-.-.-.+ +.-.-.-.-.-.-.-.-.-.-.-.+
Figure 1: Basic DOTS Signal Channel Call Home Functional Architecture Figure 1: Basic DOTS Signal Channel Call Home Functional Architecture
A DOTS client relies upon a variety of triggers to make use of the A DOTS client relies upon a variety of triggers to make use of the
Call Home function (e.g., scrubbing the traffic from the attack Call Home function (e.g., scrubbing the traffic from the attack
source, receiving an alert from an attack target, a peer DDoS source, receiving an alert from an attack target, a peer DDoS
Mitigation System (DMS), or a transit provider). The definition of Mitigation System (DMS), or a transit provider). The definition of
these triggers is deployment-specific. It is therefore out of the these triggers is deployment-specific. It is therefore out of the
scope of this document to elaborate on how these triggers are made scope of this document to elaborate on how these triggers are made
available to a Call Home DOTS client. available to a Call Home DOTS client.
In a typical deployment scenario, the Call Home DOTS server is In a typical deployment scenario, the Call Home DOTS server is
enabled on a Customer Premises Equipment (CPE), which is aligned with enabled on a Customer Premises Equipment (CPE), which is aligned with
skipping to change at page 13, line 36 skipping to change at page 13, line 36
[I-D.ietf-dots-signal-channel] is used for initiating (D)TLS [I-D.ietf-dots-signal-channel] is used for initiating (D)TLS
connections. connections.
2. Using this (D)TLS connection, the Call Home DOTS client may 2. Using this (D)TLS connection, the Call Home DOTS client may
request, withdraw, or retrieve the status of mitigation requests. request, withdraw, or retrieve the status of mitigation requests.
The Call Home DOTS client supplies the source information by The Call Home DOTS client supplies the source information by
means of new attributes defined in Section 3.3.1. means of new attributes defined in Section 3.3.1.
The Heartbeat mechanism used for the DOTS Call Home deviates from The Heartbeat mechanism used for the DOTS Call Home deviates from
the one defined in Section 4.7 of [I-D.ietf-dots-signal-channel]. the one defined in Section 4.7 of [I-D.ietf-dots-signal-channel].
Section 3.2 specifies the behavior to be followed by Call Home Section 3.2.1 specifies the behavior to be followed by Call Home
DOTS agents. DOTS agents.
3.2. Heartbeat Mechanism 3.2. DOTS Signal Channel Variations
3.2.1. Heartbeat Mechanism
Once the (D)TLS section is established between the DOTS agents, the Once the (D)TLS section is established between the DOTS agents, the
Call Home DOTS client contacts the Call Home DOTS server to retrieve Call Home DOTS client contacts the Call Home DOTS server to retrieve
the session configuration parameters (Section 4.5 of the session configuration parameters (Section 4.5 of
[I-D.ietf-dots-signal-channel]). The Call Home DOTS server adjusts [I-D.ietf-dots-signal-channel]). The Call Home DOTS server adjusts
the 'heartbeat-interval' to accommodate binding timers used by on- the 'heartbeat-interval' to accommodate binding timers used by on-
path NATs and firewalls. Heartbeats will be then exchanged by the path NATs and firewalls. Heartbeats will be then exchanged by the
DOTS agents following the instructions retrieved using the signal DOTS agents following the instructions retrieved using the signal
channel session configuration exchange. channel session configuration exchange.
skipping to change at page 14, line 24 skipping to change at page 14, line 28
client, the Call Home DOTS server MUST continue to use the DOTS client, the Call Home DOTS server MUST continue to use the DOTS
signal channel even if the missing heartbeats allowed threshold signal channel even if the missing heartbeats allowed threshold
('missing-hb-allowed') is reached. ('missing-hb-allowed') is reached.
If the Call Home DOTS server does not receive any traffic from the If the Call Home DOTS server does not receive any traffic from the
peer Call Home DOTS client during the time span required to exhaust peer Call Home DOTS client during the time span required to exhaust
the maximum 'missing-hb-allowed' threshold, the Call Home DOTS server the maximum 'missing-hb-allowed' threshold, the Call Home DOTS server
concludes the session is disconnected. Then, the Call Home DOTS concludes the session is disconnected. Then, the Call Home DOTS
server MUST try to resume the (D)TLS session. server MUST try to resume the (D)TLS session.
3.2.2. Redirected Signaling
A Call Home DOTS server MUST NOT support the Redirected Signaling
mechanism as specified in Section 4.6 of
[I-D.ietf-dots-signal-channel] (i.e., a 5.03 response that conveys an
alternate DOTS server's FQDN or alternate DOTS server's IP
address(es)). A Call Home DOTS client MUST silently discard such
message as only a Call Home DOTS server can initiate a new (D)TLS
connection.
If a Call Home DOTS client wants to redirect a Call Home DOTS server
to another Call Home DOTS client, it MUST send a Non-confirmable PUT
request to the predefined resource ".well-known/dots/redirect" with
the new Call Home DOTS client FQDN or IP address in the body of the
PUT similar to what is described in Section 4.6 of
[I-D.ietf-dots-signal-channel]. Furthermore, a new clause called
'ttl" is defined to return the Time to live (TTL) of the alternate
Call Home DOTS client.
On receipt of this PUT request, the Call Home DOTS server responds
with a 2.01 (Created), closes this connection and establishes a
connection with the new Call Home DOTS client. The processing of the
TTL is defined in Section 4.6 of [I-D.ietf-dots-signal-channel]. If
the Call Home DOTS server cannot service the PUT request, the
response is rejected with a 4.00 (bad Request).
Figure 8 shows a PUT request example to convey the alternate Call
Home DOTS client 'alt-call-home-client.example' together with its IP
addresses 2001:db8:6401::1 and 2001:db8:6401::2. The validity of
this alternate Call Home DOTS client is 10 minutes.
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "redirect"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:redirected-signal": {
"ietf-dots-call-home:alt-ch-client":
"alt-call-home-client.example",
"ietf-dots-call-home:alt-ch-client-record": [
"2001:db8:6401::1",
"2001:db8:6401::2"
],
"ietf-dots-call-home:ttl": 600
}
Figure 8: Example of a PUT Request for Redirected Signaling
3.3. DOTS Signal Channel Extension 3.3. DOTS Signal Channel Extension
3.3.1. Mitigation Request 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 attack Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the attack
source information (e.g., source prefixes, source port numbers). The source information (e.g., source prefixes, source port numbers). The
DOTS client conveys the following new parameters in the CBOR body of DOTS client conveys the following new parameters in the CBOR body of
the mitigation request: the mitigation request:
skipping to change at page 15, line 52 skipping to change at page 17, line 11
Address sharing implications on the setting of source information Address sharing implications on the setting of source information
('source-prefix', 'source-port-range') are discussed in ('source-prefix', 'source-port-range') are discussed in
Section 3.3.2. Section 3.3.2.
Only immediate mitigation requests (i.e., 'trigger-mitigation' set to Only immediate mitigation requests (i.e., 'trigger-mitigation' set to
'true') are allowed; Call Home DOTS clients MUST NOT send requests 'true') are allowed; Call Home DOTS clients MUST NOT send requests
with 'trigger-mitigation' set to 'false'. Such requests MUST be with 'trigger-mitigation' set to 'false'. Such requests MUST be
discarded by the Call Home DOTS server with a 4.00 (Bad Request). discarded by the Call Home DOTS server with a 4.00 (Bad Request).
An example of a mitigation request sent by a Call Home DOTS client is An example of a mitigation request sent by a Call Home DOTS client is
shown in Figure 8. shown in Figure 9.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=56" Uri-Path: "mid=56"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
skipping to change at page 16, line 29 skipping to change at page 17, line 37
], ],
"ietf-dots-call-home:source-prefix": [ "ietf-dots-call-home:source-prefix": [
"2001:db8:123::/128" "2001:db8:123::/128"
], ],
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
Figure 8: An Example of Mitigation Request Issued by a Call Home DOTS Figure 9: An Example of Mitigation Request Issued by a Call Home DOTS
Client Client
The Call Home DOTS server MUST check that the 'source-prefix' is The Call Home DOTS server MUST check that the 'source-prefix' is
within the scope of the Call Home DOTS server domain. Note that in a within the scope of the Call Home DOTS server domain. Note that in a
DOTS Call Home scenario, the Call Home DOTS server considers, by DOTS Call Home scenario, the Call Home DOTS server considers, by
default, that any routeable IP prefix enclosed in 'target-prefix' is default, that any routeable IP prefix enclosed in 'target-prefix' is
within the scope of the Call Home DOTS client. Invalid mitigation within the scope of the Call Home DOTS client. Invalid mitigation
requests are handled as per Section 4.4.1 of requests are handled as per Section 4.4.1 of
[I-D.ietf-dots-signal-channel]. [I-D.ietf-dots-signal-channel].
skipping to change at page 17, line 38 skipping to change at page 18, line 46
The DOTS agents follow the same procedures specified in The DOTS agents follow the same procedures specified in
[I-D.ietf-dots-signal-channel] for managing a mitigation request. [I-D.ietf-dots-signal-channel] for managing a mitigation request.
3.3.2. Address Sharing Considerations 3.3.2. Address Sharing Considerations
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
Call Home DOTS server because the external IP address is not visible Call Home DOTS server because the external IP address is not visible
locally to the Call Home DOTS server (see Figure 9). The Call Home locally to the Call Home DOTS server (see Figure 10). The Call Home
DOTS server is only aware of the internal IP addresses/prefixes bound DOTS server is only aware of the internal IP addresses/prefixes bound
to its domain. Thus, the Call Home DOTS client MUST NOT include the to its domain. Thus, the Call Home DOTS client MUST NOT include the
external IP address and/or port number identifying the suspect attack external IP address and/or port number identifying the suspect attack
source, but MUST include the internal IP address and/or port number. source, but MUST include the internal IP address and/or port number.
To that aim, the Call Home DOTS client SHOULD rely on mechanisms, To that aim, the Call Home DOTS client SHOULD rely on mechanisms,
such as [RFC8512] or [RFC8513], to retrieve the internal IP address such as [RFC8512] or [RFC8513], to retrieve the internal IP address
and port number which are mapped to an external IP address and port and port number which are mapped to an external IP address and port
number. number.
N | .-------------------. N | .-------------------.
skipping to change at page 18, line 34 skipping to change at page 19, line 36
.' Source Network ' .' Source Network '
( ) ( )
( Call Home -' ( Call Home -'
'-( DOTS server ) '-( DOTS server )
'------+------------' '------+------------'
| |
+-----+-------+ +-----+-------+
|Attack Source| |Attack Source|
+-------------+ +-------------+
Figure 9: Example of a CGN between DOTS Domains Figure 10: 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.
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 Call Home DOTS server (e.g., a CPE with NAT enabled as shown in the Call Home DOTS server (e.g., a CPE with NAT enabled as shown in
Figures 10 and 11), the Call Home DOTS server uses the attack traffic Figures 11 and 12), the Call Home DOTS server uses the attack traffic
information conveyed in a mitigation request to find the internal information conveyed in a mitigation request to find the internal
source IP address of the compromised device and blocks the traffic source IP address of the compromised device and blocks the traffic
from the compromised device traffic to the attack target until the from the compromised device traffic to the attack target until the
mitigation request is withdrawn. Doing so allows to isolate the mitigation request is withdrawn. Doing so allows to isolate the
suspicious device while avoiding to disturb other services. suspicious device while avoiding to disturb other services.
.-------------------. .-------------------.
( )-. ( )-.
.' Network Provider (DMS)' .' Network Provider (DMS)'
( ) ( )
skipping to change at page 19, line 31 skipping to change at page 20, line 33
N | .' ' N | .' '
E | ( Call Home ) E | ( Call Home )
T | ( DOTS server -' T | ( DOTS server -'
W | '-( ) W | '-( )
O | '-------+-----------' O | '-------+-----------'
R | | R | |
K | +------+------+ K | +------+------+
| |Attack Source| | |Attack Source|
+-------------+ +-------------+
Figure 10: Example of a DOTS Server Domain with a NAT Embedded in a Figure 11: Example of a DOTS Server Domain with a NAT Embedded in a
CPE CPE
.-------------------. .-------------------.
( )-. ( )-.
.' Network Provider (DMS) ' .' Network Provider (DMS) '
( ) ( )
( Call Home -' ( Call Home -'
'-( DOTS client ) '-( DOTS client )
'---------+---------' '---------+---------'
| |
skipping to change at page 20, line 32 skipping to change at page 21, line 32
N | .' ' N | .' '
E | ( Local Area Network ) E | ( Local Area Network )
T | ( -' T | ( -'
W | '-( ) W | '-( )
O | '--------+----------' O | '--------+----------'
R | | R | |
K | +------+------+ K | +------+------+
| |Attack Source| | |Attack Source|
+-------------+ +-------------+
Figure 11: Example of a Call Home DOTS Server and a NAT Embedded in a Figure 12: Example of a Call Home DOTS Server and a NAT Embedded in a
CPE CPE
3.3.3. DOTS Signal Call Home YANG Module 3.3.3. DOTS Signal Call Home YANG Module
3.3.3.1. Tree Structure 3.3.3.1. Tree Structure
This document augments the "ietf-dots-signal-channel" DOTS signal This document augments the "ietf-dots-signal-channel" DOTS signal
YANG module defined in [I-D.ietf-dots-signal-channel] for signaling YANG module defined in [I-D.ietf-dots-signal-channel] for signaling
the attack traffic information. This document defines the YANG the attack traffic information. This document defines the YANG
module "ietf-dots-call-home", which has the following tree structure: module "ietf-dots-call-home", which has the following tree structure:
skipping to change at page 21, line 16 skipping to change at page 22, line 16
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
augment /ietf-signal:dots-signal/ietf-signal:message-type
/ietf-signal:redirected-signal:
+--rw alt-ch-client string {call-home}?
+--rw alt-ch-client-record* inet:ip-address {call-home}?
+--rw ttl uint32 {call-home}?
3.3.3.2. YANG Module 3.3.3.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-09-06.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;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"Section 4 of RFC 6991"; "Section 4 of RFC 6991";
skipping to change at page 22, line 26 skipping to change at page 23, line 30
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2019-04-25 { revision 2019-09-06 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Distributed Denial-of-Service Open Threat "RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Call Home"; Signaling (DOTS) Signal Channel Call Home";
} }
feature source-signaling { feature source-signaling {
description description
"This feature means that source-related information "This feature means that source-related information
can be supplied in mitigation requests."; can be supplied in mitigation requests. This is
typically applicable for DOTS Call Home.";
}
feature call-home {
description
"This feature means that Call Home functionality
is supported.";
} }
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" {
if-feature source-signaling; if-feature source-signaling;
description "Attacker source details."; description "Attacker source details.";
leaf-list source-prefix { leaf-list source-prefix {
type inet:ip-prefix; type inet:ip-prefix;
description description
"IPv4 or IPv6 prefix identifying the attacker(s)."; "IPv4 or IPv6 prefix identifying the attacker(s).";
} }
list source-port-range { list source-port-range {
key "lower-port"; key "lower-port";
skipping to change at page 23, line 46 skipping to change at page 25, line 9
must ". >= ../lower-type" { must ". >= ../lower-type" {
error-message error-message
"The upper ICMP type must be greater than "The upper ICMP type must be greater than
or equal to lower ICMP type."; or equal to lower ICMP type.";
} }
description description
"Upper type of the ICMP type range."; "Upper type of the ICMP type range.";
} }
} }
} }
augment "/ietf-signal:dots-signal/ietf-signal:message-type/"
+ "ietf-signal:redirected-signal" {
if-feature call-home;
description
"The alternate Call Home DOTS client.";
leaf alt-ch-client {
type string;
description
"FQDN of an alternate Call Home DOTS client.";
}
leaf-list alt-ch-client-record {
type inet:ip-address;
description
"List of records for the alternate Call Home
DOTS client.";
}
leaf ttl {
type uint32;
units "seconds";
description
"The Time to live (TTL) of the alternate Call Home
DOTS client.";
}
}
} }
<CODE ENDS> <CODE ENDS>
4. IANA Considerations 4. IANA Considerations
4.1. DOTS Signal Channel Call Home UDP and TCP Port Number 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number
IANA is requested to assign the port number TBD to the DOTS signal IANA is requested to assign the port number TBD to the DOTS signal
channel Call Home protocol for both UDP and TCP from the "Service channel Call Home protocol for both UDP and TCP from the "Service
Name and Transport Protocol Port Number Registry" available at: Name and Transport Protocol Port Number Registry" available at:
skipping to change at page 24, line 31 skipping to change at page 26, line 21
Reference: RFC XXXX Reference: RFC XXXX
The assignment of port number 4647 is strongly suggested (DOTS signal The assignment of port number 4647 is strongly suggested (DOTS signal
channel uses port number 4646). channel uses port number 4646).
4.2. DOTS Signal Channel CBOR Mappings Registry 4.2. DOTS Signal Channel CBOR Mappings Registry
This specification registers the 'source-prefix', 'source-port- This specification registers the 'source-prefix', 'source-port-
range', and 'source-icmp-type-range' parameters in the IANA "DOTS range', and 'source-icmp-type-range' parameters in the IANA "DOTS
Signal Channel CBOR Key Values" registry established by Signal Channel CBOR Key Values" registry established by
[I-D.ietf-dots-signal-channel] (Figure 12). [I-D.ietf-dots-signal-channel] (Figure 13).
The 'source-prefix', 'source-port-range', and 'source-icmp-type- The 'source-prefix', 'source-port-range', and 'source-icmp-type-
range' are comprehension-optional parameters. range' are comprehension-optional parameters.
o Note to the RFC Editor: Please delete (TBD1)-(TBD5) once CBOR keys o Note to the RFC Editor: Please delete (TBD1)-(TBD8) once CBOR keys
are assigned from the 0x8000 - 0xBFFF range. are assigned from the 0x8000 - 0xBFFF range.
+-------------------+------------+--------+---------------+--------+ +-------------------+------------+--------+---------------+--------+
| Parameter Name | YANG | CBOR | CBOR Major | JSON | | Parameter Name | YANG | CBOR | CBOR Major | JSON |
| | Type | Key | Type & | Type | | | Type | Key | Type & | Type |
| | | | Information | | | | | | Information | |
+-------------------+------------+--------+---------------+--------+ +-------------------+------------+--------+---------------+--------+
| source-prefix | leaf-list | 0x8000 | 4 array | Array | | source-prefix | leaf-list | 0x8000 | 4 array | Array |
| | inet: | (TBD1) | | | | | inet: | (TBD1) | | |
| | ip-prefix | | 3 text string | String | | | ip-prefix | | 3 text string | String |
| source-port-range | list | 0x8001 | 4 array | Array | | source-port-range | list | 0x8001 | 4 array | Array |
| | | (TBD2) | | | | | | (TBD2) | | |
| source-icmp-type- | list | 0x8002 | 4 array | Array | | source-icmp-type- | list | 0x8002 | 4 array | Array |
| range | | (TBD3) | | | | range | | (TBD3) | | |
| lower-type | uint8 | 0x8003 | 0 unsigned | Number | | lower-type | uint8 | 0x8003 | 0 unsigned | Number |
| | | (TBD4) | | | | | | (TBD4) | | |
| upper-type | uint8 | 0x8004 | 0 unsigned | Number | | upper-type | uint8 | 0x8004 | 0 unsigned | Number |
| | | (TBD5) | | | | | | (TBD5) | | |
| alt-ch-client | string | 0x8005 | 3 text string | String |
| | | (TBD6) | | |
| alt-ch-client- | leaf-list | 0x8006 | 4 array | Array |
| record | inet: | (TBD7) | | |
| | ip-address| | 3 text string | String |
| ttl | uint32 | 0x8007 | 0 unsigned | Number |
| | | (TBD8) | | |
+-------------------+------------+--------+---------------+--------+ +-------------------+------------+--------+---------------+--------+
Figure 12: Assigned DOTS Signal Channel CBOR Key Values Figure 13: Assigned DOTS Signal Channel CBOR Key Values
4.3. New DOTS Conflict Cause 4.3. New DOTS Conflict Cause
This document requests IANA to assign a new code from the "DOTS This document requests IANA to assign a new code from the "DOTS
Signal Channel Conflict Cause Codes" registry: Signal Channel Conflict Cause Codes" registry:
+-----+-----------------------------------+-------------+-----------+ +-----+-----------------------------------+-------------+-----------+
| Cod | Label | Description | Reference | | Cod | Label | Description | Reference |
| e | | | | | e | | | |
+-----+-----------------------------------+-------------+-----------+ +-----+-----------------------------------+-------------+-----------+
skipping to change at page 28, line 32 skipping to change at page 30, line 49
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-35 (work in progress), July 2019. ietf-dots-signal-channel-37 (work in progress), July 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 29, line 27 skipping to change at page 31, line 44
9.2. Informative References 9.2. Informative References
[I-D.ietf-dots-multihoming] [I-D.ietf-dots-multihoming]
Boucadair, M., K, R., and W. Pan, "Multi-homing Deployment Boucadair, M., K, R., and W. Pan, "Multi-homing Deployment
Considerations for Distributed-Denial-of-Service Open Considerations for Distributed-Denial-of-Service Open
Threat Signaling (DOTS)", draft-ietf-dots-multihoming-02 Threat Signaling (DOTS)", draft-ietf-dots-multihoming-02
(work in progress), July 2019. (work in progress), July 2019.
[I-D.ietf-dots-server-discovery] [I-D.ietf-dots-server-discovery]
Boucadair, M. and R. K, "Distributed-Denial-of-Service Boucadair, M. and R. K, "Distributed-Denial-of-Service
Open Threat Signaling (DOTS) Server Discovery", draft- Open Threat Signaling (DOTS) Agent Discovery", draft-ietf-
ietf-dots-server-discovery-04 (work in progress), June dots-server-discovery-05 (work in progress), August 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., Moskowitz, R., Teague, N., Xia,
Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS L., and K. Nishizuka, "Use cases for DDoS Open Threat
Open Threat Signaling", draft-ietf-dots-use-cases-18 (work Signaling", draft-ietf-dots-use-cases-20 (work in
in progress), July 2019. progress), September 2019.
[I-D.ietf-i2nsf-terminology] [I-D.ietf-i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
Birkholz, "Interface to Network Security Functions (I2NSF) Birkholz, "Interface to Network Security Functions (I2NSF)
Terminology", draft-ietf-i2nsf-terminology-08 (work in Terminology", draft-ietf-i2nsf-terminology-08 (work in
progress), July 2019. progress), July 2019.
[I-D.ietf-idr-flow-spec-v6] [I-D.ietf-idr-flow-spec-v6]
McPherson, D., Raszuk, R., Pithawala, B., McPherson, D., Raszuk, R., Pithawala, B.,
akarch@cisco.com, a., and S. Hares, "Dissemination of Flow akarch@cisco.com, a., and S. Hares, "Dissemination of Flow
 End of changes. 31 change blocks. 
51 lines changed or deleted 150 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/