rfc9066.original | rfc9066.txt | |||
---|---|---|---|---|
DOTS T. Reddy | Internet Engineering Task Force (IETF) T. Reddy.K | |||
Internet-Draft McAfee | Request for Comments: 9066 Akamai | |||
Intended status: Standards Track M. Boucadair, Ed. | Category: Standards Track M. Boucadair, Ed. | |||
Expires: November 27, 2021 Orange | ISSN: 2070-1721 Orange | |||
J. Shallow | J. Shallow | |||
May 26, 2021 | November 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-14 | ||||
Abstract | Abstract | |||
This document specifies the DOTS signal channel Call Home, which | This document specifies the Denial-of-Service Open Threat Signaling | |||
enables a Call Home DOTS server to initiate a secure connection to a | (DOTS) signal channel Call Home, which enables a Call Home DOTS | |||
Call Home DOTS client, and to receive attack traffic information from | server to initiate a secure connection to a Call Home DOTS client and | |||
the Call Home DOTS client. The Call Home DOTS server in turn uses | to receive attack traffic information from the Call Home DOTS client. | |||
the attack traffic information to identify compromised devices | The Call Home DOTS server in turn uses the attack traffic information | |||
launching outgoing DDoS attacks and take appropriate mitigation | to identify compromised devices launching outgoing DDoS attacks and | |||
action(s). | take appropriate mitigation action(s). | |||
The DOTS signal channel Call Home is not specific to home networks; | The DOTS signal channel Call Home is not specific to home networks; | |||
the solution targets any deployment in which it is required to block | the solution targets any deployment in which it is required to block | |||
DDoS attack traffic closer to the source(s) of a DDoS attack. | DDoS attack traffic closer to the source(s) of a DDoS attack. | |||
Editorial Note (To be removed by RFC Editor) | ||||
Please update these statements within the document with the RFC | ||||
number to be assigned to this document: | ||||
o "This version of this YANG module is part of RFC XXXX;" | ||||
o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling | ||||
(DOTS) Signal Channel Call Home"; | ||||
o "| [RFCXXXX] |" | ||||
o reference: RFC XXXX | ||||
Please update this statement with the RFC number to be assigned to | ||||
the following documents: | ||||
o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling | ||||
(DOTS) Signal Channel Specification" (used to be I-D.ietf-dots- | ||||
rfc8782-bis) | ||||
Please update TBD/TBA statements with the assignments made by IANA to | ||||
DOTS Signal Channel Call Home. | ||||
Also, please update the "revision" date of the YANG module. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at https://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on November 27, 2021. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
https://www.rfc-editor.org/info/rfc9066. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2021 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 Revised BSD License text as described in Section 4.e of the | |||
the Trust Legal Provisions and are provided without warranty as | Trust Legal Provisions and are provided without warranty as described | |||
described in the Simplified BSD License. | in the Revised BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2. Terminology | |||
3. Applicability Scope . . . . . . . . . . . . . . . . . . . . . 7 | 3. Applicability Scope | |||
4. Co-existence of Base DOTS Signal Channel and DOTS Call Home . 8 | 4. Coexistence of a Base DOTS Signal Channel and DOTS Call Home | |||
5. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 12 | 5. DOTS Signal Channel Call Home | |||
5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 12 | 5.1. Procedure | |||
5.2. DOTS Signal Channel Variations . . . . . . . . . . . . . 14 | 5.2. DOTS Signal Channel Variations | |||
5.2.1. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 14 | 5.2.1. Heartbeat Mechanism | |||
5.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 15 | 5.2.2. Redirected Signaling | |||
5.3. DOTS Signal Channel Extension | ||||
5.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 16 | 5.3.1. Mitigation Request | |||
5.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 16 | 5.3.2. Address Sharing Considerations | |||
5.3.2. Address Sharing Considerations . . . . . . . . . . . 20 | 6. DOTS Signal Call Home YANG Module | |||
6. DOTS Signal Call Home YANG Module . . . . . . . . . . . . . . 23 | 6.1. Tree Structure | |||
6.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 23 | 6.2. YANG/JSON Mapping Parameters to CBOR | |||
6.2. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . 24 | 6.3. YANG Module | |||
6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25 | 7. IANA Considerations | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 | 7.1. DOTS Signal Channel CBOR Mappings Registry | |||
7.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 29 | 7.2. New DOTS Conflict Cause | |||
7.2. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 30 | 7.3. DOTS Signal Call Home YANG Module | |||
7.3. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 31 | 8. Security Considerations | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 | 9. Privacy Considerations | |||
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33 | 10. References | |||
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 | 10.1. Normative References | |||
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 | 10.2. Informative References | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 | Appendix A. Some Home Network Issues | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 35 | Appendix B. Disambiguating Base DOTS Signal vs. DOTS Call Home | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 36 | Acknowledgements | |||
Appendix A. Some Home Network Issues . . . . . . . . . . . . . . 39 | Contributors | |||
Appendix B. Disambiguating Base DOTS Signal vs. DOTS Call Home . 41 | Authors' Addresses | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 | ||||
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 [RFC9132] is used to carry information about a | |||
information about a network resource or a network (or a part thereof) | network resource or a network (or a part thereof) that is under a | |||
that is under a Distributed Denial of Service (DDoS) attack | Distributed Denial-of-Service (DDoS) attack [RFC4732]. Such | |||
[RFC4732]. Such information is sent by a DOTS client to one or | information is sent by a DOTS client to one or multiple DOTS servers | |||
multiple DOTS servers so that appropriate mitigation actions are | so that appropriate mitigation actions are undertaken on traffic | |||
undertaken on traffic deemed suspicious. Various use cases are | deemed suspicious. Various use cases are discussed in [RFC8903]. | |||
discussed in [I-D.ietf-dots-use-cases]. | ||||
However, [I-D.ietf-dots-rfc8782-bis] only covers how to mitigate when | However, [RFC9132] only covers how to mitigate when being attacked | |||
being attacked (i.e., protect a network from inbound DDoS attacks). | (i.e., protecting a network from inbound DDoS attacks). It does not | |||
It does not cover how to control the attacks close to their source(s) | cover how to control the attacks close to their source(s) that are | |||
that are misusing network resources (i.e., outbound DDoS attacks). | misusing network resources (i.e., outbound DDoS attacks). In | |||
In particular, the DOTS signal protocol does not discuss cooperative | particular, the DOTS signal protocol does not discuss cooperative | |||
DDoS mitigation between the network hosting an attack source and the | DDoS mitigation between the network hosting an attack source and the | |||
Internet Service Provider (ISP) to suppress the outbound DDoS attack | Internet Service Provider (ISP) to suppress the outbound DDoS attack | |||
traffic originating from that network. As a reminder, the base basic | traffic originating from that network. As a reminder, the base basic | |||
DOTS architecture is depicted in Figure 1 (Section 2 of [RFC8811]). | DOTS architecture is depicted in Figure 1 (Section 2 of [RFC8811]). | |||
+-----------+ +-------------+ | +-----------+ +-------------+ | |||
| Mitigator | ~~~~~~~~~~ | DOTS Server | | | Mitigator | ~~~~~~~~~~ | DOTS Server | | |||
+-----------+ +-------------+ | +-----------+ +-------------+ | |||
| | | | |||
| | | | |||
| | | | |||
+---------------+ +-------------+ | +---------------+ +-------------+ | |||
| Attack Target | ~~~~~~ | DOTS Client | | | Attack Target | ~~~~~~ | DOTS Client | | |||
+---------------+ +-------------+ | +---------------+ +-------------+ | |||
Figure 1: Basic DOTS Architecture | Figure 1: Basic DOTS Architecture | |||
Appendix A details why the rise of Internet of Things (IoT) compounds | Appendix A details why the rise of Internet of Things (IoT) compounds | |||
the possibility of these being used as malicious actors which need to | the possibility of these being used as malicious actors that need to | |||
be controlled. Similar issues can be encountered in enterprise | be controlled. Similar issues can be encountered in enterprise | |||
networks, data centers, etc. The ISP offering a DDoS mitigation | networks, data centers, etc. The ISP offering a DDoS mitigation | |||
service can detect outgoing DDoS attack traffic originating from its | service can detect outgoing DDoS attack traffic originating from its | |||
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 [RFC8955][RFC8956]) from a transit provider to filter, | Flowspec [RFC8955] [RFC8956]) from a transit provider to filter, | |||
block, or rate-limit DDoS attack traffic originating from the ISP's | block, or rate-limit DDoS attack traffic originating from the ISP's | |||
subscribers to a downstream target. Nevertheless, the DOTS signal | subscribers to a downstream target. Nevertheless, the DOTS signal | |||
channel does not provide means for the ISP to request blocking such | channel does not provide means for the ISP to request blocking such | |||
attacks close to the sources without altering legitimate traffic. | attacks close to the sources without altering legitimate traffic. | |||
This document fills that void by specifying an extension to the DOTS | This document fills that void by specifying an extension to the DOTS | |||
signal channel: DOTS signal channel Call Home. | signal channel: DOTS signal channel Call Home. | |||
Note: Another design approach would be to extend the DOTS signal | Note: Another design approach would be to extend the DOTS signal | |||
channel with a new attribute to explicitly indicate whether a | channel with a new attribute to explicitly indicate whether a | |||
mitigation request is about an outbound DDoS attack. In such an | mitigation request concerns an outbound DDoS attack. In such an | |||
approach, it is assumed that a DOTS server is deployed within the | approach, it is assumed that a DOTS server is deployed within the | |||
domain that is hosting the attack source(s), while a DOTS client | domain that is hosting the attack source(s), while a DOTS client | |||
is enabled within an upstream network (e.g., access network). | is enabled within an upstream network (e.g., access network). | |||
However, initiating a DOTS signal channel from an upstream network | However, initiating a DOTS signal channel from an upstream network | |||
to a source network is complicated because of the presence of | to a source network is complicated because of the presence of | |||
translators and firewalls. Moreover, the use of the same signal | translators and firewalls. Moreover, the use of the same signal | |||
channel to handle both inbound and outbound attacks complicates | channel to handle both inbound and outbound attacks complicates | |||
both the heartbeat and redirection mechanisms that are executed as | 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). | 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., | Also, the DOTS server will be subject to fingerprinting (e.g., | |||
using scanning tools) and DoS attacks (e.g., by having the DOTS | using scanning tools) and DoS attacks (e.g., by having the DOTS | |||
server to perform computationally expensive operations). Various | server perform computationally expensive operations). Various | |||
management and deployment considerations that motivate the Call | management and deployment considerations that motivate the Call | |||
Home functionality are listed in Section 1.1 of [RFC8071]. | 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) | |||
to a DOTS signal channel established at the initiative of a DOTS | refers to a DOTS signal channel established at the initiative of a | |||
server thanks to a role reversal at the (D)TLS layer (Section 5.1). | DOTS server thanks to a role reversal at the (D)TLS layer | |||
That is, the DOTS server initiates a secure connection to a DOTS | (Section 5.1). That is, the DOTS server initiates a secure | |||
client, and uses that connection to receive the attack traffic | connection to a DOTS client and uses that connection to receive the | |||
information (e.g., attack sources) from the DOTS client. | attack traffic 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 | |||
+.-.-.-.-.-.-.-.-.-.-.-.+ | +.-.-.-.-.-.-.-.-.-.-.-.+ | |||
+---------------+ : +-------------+ : | +---------------+ : +-------------+ : | |||
| Alert | ~~~:~~~ | Call Home | : | | Alert | ~~~:~~~ | Call Home | : | |||
| | : | DOTS client | : | | | : | DOTS client | : | |||
+---------------+ : +------+------+ : | +---------------+ : +------+------+ : | |||
skipping to change at page 5, line 31 ¶ | skipping to change at line 184 ¶ | |||
| Source(s) | : | DOTS server | : | | Source(s) | : | DOTS server | : | |||
+---------------+ : +-------------+ : | +---------------+ : +-------------+ : | |||
+.-.-.-.-.-.-.-.-.-.-.-.+ | +.-.-.-.-.-.-.-.-.-.-.-.+ | |||
Figure 2: Basic DOTS Signal Channel Call Home Functional Architecture | Figure 2: Basic DOTS Signal Channel Call Home Functional Architecture | |||
DOTS agents involved in the DOTS Call Home otherwise adhere to the | DOTS agents involved in the DOTS Call Home otherwise adhere to the | |||
DOTS roles as defined in [RFC8612]. For clarity, this document uses | DOTS roles as defined in [RFC8612]. For clarity, this document uses | |||
"Call Home DOTS client" (or "Call Home DOTS server") to refer to a | "Call Home DOTS client" (or "Call Home DOTS server") to refer to a | |||
DOTS client (or DOTS server) deployed in a Call Home scenario | DOTS client (or DOTS server) deployed in a Call Home scenario | |||
(Figure 2). DOTS Call Home agents may (or not) be co-located with | (Figure 2). Call Home DOTS agents may (or may not) be co-located | |||
DOTS agents that are compliant with [I-D.ietf-dots-rfc8782-bis] (see | with DOTS agents that are compliant with [RFC9132] (see Section 4 for | |||
Section 4 for more details). | more details). | |||
A Call Home DOTS client relies upon a variety of triggers to make use | A Call Home DOTS client relies upon a variety of triggers to make use | |||
of the Call Home function (e.g., scrubbing the traffic from the | of the Call Home function (e.g., scrubbing the traffic from the | |||
attack source, receiving an alert from an attack target, a peer DDoS | attack source or receiving an alert from an attack target, a peer | |||
Mitigation System (DMS), or a transit provider). The definition of | DDoS Mitigation System (DMS), or a transit provider). The definition | |||
these triggers is deployment-specific. It is therefore out of the | of 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 | |||
recent trends to enrich the CPE with advanced security features. For | recent trends to enrich the CPE with advanced security features. For | |||
example, the DOTS Call Home service can be part of services supported | example, the DOTS Call Home service can be part of services supported | |||
by an ISP-managed CPE or a managed security service subscribed by the | by an ISP-managed CPE or a managed security service subscribed to by | |||
user. Unlike classic DOTS deployments [I-D.ietf-dots-use-cases], a | the user. Unlike classic DOTS deployments [RFC8903], a Call Home | |||
Call Home DOTS server maintains a single DOTS signal channel session | DOTS server maintains a single DOTS signal channel session for each | |||
for each DOTS-capable upstream provisioning domain | DOTS-capable upstream provisioning domain [DOTS-MULTIHOMING]. | |||
[I-D.ietf-dots-multihoming]. | ||||
For instance, the Call Home DOTS server in the home network initiates | For instance, the Call Home DOTS server in the home network initiates | |||
the signal channel Call Home in 'idle' time and then subsequently the | the signal channel Call Home in "idle" time; subsequently, the Call | |||
Call Home DOTS client in the ISP environment can initiate a | Home DOTS client in the ISP environment can initiate a mitigation | |||
mitigation request whenever the ISP detects there is an attack from a | request whenever the ISP detects there is an attack from a | |||
compromised device in the DOTS server domain (i.e., from within the | compromised device in the DOTS server domain (i.e., from within the | |||
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. | |||
skipping to change at page 6, line 32 ¶ | skipping to change at line 232 ¶ | |||
client(s), which could occur by a variety of means (e.g., [RFC8973]). | client(s), which could occur by a variety of means (e.g., [RFC8973]). | |||
The specification of such means are out of scope of this document. | The specification of such means 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 | |||
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 | |||
14 [RFC2119][RFC8174] when, and only when, they appear in all | BCP 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 Section 1.2 | The reader should be familiar with the terms defined in Section 1.2 | |||
of [RFC8612]. | of [RFC8612]. | |||
DDoS Mitigation System (DMS) refers to a system that performs DDoS | "DDoS Mitigation System (DMS)" refers to a system that performs DDoS | |||
mitigation. | mitigation. | |||
'Base DOTS signal channel' refers to [I-D.ietf-dots-rfc8782-bis]. | "Base DOTS signal channel" refers to [RFC9132]. | |||
The meaning of the symbols in YANG tree diagrams are defined in | The meaning of the symbols in YANG tree diagrams are defined in | |||
[RFC8340] and [RFC8791]. | [RFC8340] and [RFC8791]. | |||
(D)TLS is used for statements that apply to both Transport Layer | (D)TLS is used for statements that apply to both Transport Layer | |||
Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS) | Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS) | |||
[RFC6347]. Specific terms are used for any statement that applies to | [RFC6347] [DTLS13]. Specific terms are used for any statement that | |||
either protocol alone. | applies to either protocol alone. | |||
3. Applicability Scope | 3. Applicability Scope | |||
The problems discussed in Section 1 may be encountered in many | The problems discussed in Section 1 may be encountered in many | |||
deployments (e.g., home networks, enterprise networks, transit | deployments (e.g., home networks, enterprise networks, transit | |||
networks, data centers). The solution specified in this document can | networks, data centers). The solution specified in this document can | |||
be used for those deployments to block DDoS attack traffic closer to | be used for those deployments to block DDoS attack traffic closer to | |||
the source(s) of the attack. That is, attacks that are issued, e.g., | the source(s) of the attack. That is, attacks that are issued, e.g., | |||
from within an enterprise network or a data center, will thus be | from within an enterprise network or a data center will thus be | |||
blocked before exiting these networks. | blocked before exiting these networks. | |||
An instantiation of the Call Home functional architecture is depicted | An instantiation of the Call Home functional architecture is depicted | |||
in Figure 3. | in Figure 3. | |||
+-------------+ | +-------------+ | |||
|Attack Target| | |Attack Target| | |||
+-----+-------+ | +-----+-------+ | |||
| /\ Target Network | | /\ Target Network | |||
......................|.||.................... | ......................|.||.................... | |||
skipping to change at page 7, line 51 ¶ | skipping to change at line 298 ¶ | |||
.' Call Home || ' | .' Call Home || ' | |||
( DOTS server || Outbound ) | ( DOTS server || Outbound ) | |||
( || DDoS -' | ( || DDoS -' | |||
'-( || Attack ) | '-( || Attack ) | |||
'------+-||---------' | '------+-||---------' | |||
| || | | || | |||
+-----+-++----+ | +-----+-++----+ | |||
|Attack Source| | |Attack Source| | |||
+-------------+ | +-------------+ | |||
Figure 3: DOTS Signal Channel Call Home Reference Architecture | Figure 3: DOTS Signal Channel 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. | |||
Call Home DOTS agent relationships are similar to those discussed in | Call Home DOTS agent relationships are similar to those discussed in | |||
Section 2.3 of [RFC8811]. For example, multiple Call Home DOTS | Section 2.3 of [RFC8811]. For example, multiple Call Home DOTS | |||
servers of the same domain can be associated with the same Call Home | servers of the same domain can be associated with the same Call Home | |||
DOTS client. A Call Home DOTS client may decide to contact these | DOTS client. A Call Home DOTS client may decide to contact these | |||
Call Home DOTS servers sequentially, fork a mitigation request to all | Call Home DOTS servers sequentially, fork a mitigation request to all | |||
of them, or select one Call Home DOTS server to place a mitigation | of them, or select one Call Home DOTS server to place a mitigation | |||
request. Such decision is implementation-specific. | request. Such a decision is implementation specific. | |||
For some mitigations, a feedback may be required from an | For some mitigations, feedback may be required from an administrator | |||
administrator to confirm a filtering action. Means to seek for an | to confirm a filtering action. The means to seek an administrator's | |||
administrator's consent are deployment-specific. Indeed, a variety | consent are deployment specific. Indeed, a variety of implementation | |||
of implementation options can be considered as a function of the Call | options can be considered for any given Call Home DOTS deployment, | |||
Home DOTS deployment: push notifications using a dedicated | such as push notifications using a dedicated application, Syslog, | |||
application, Syslog, etc. It is out of the scope of this document to | etc. It is out of the scope of this document to make recommendations | |||
make recommendations about how such interactions are implemented (see | about how such interactions are implemented (see Figure 2). | |||
Figure 2). | ||||
The Call Home DOTS server can be enabled on a border router or a | The Call Home DOTS server can be enabled on a border router or a | |||
dedicated appliance. For the particular case of home networks, the | dedicated appliance. For the particular case of home networks, the | |||
Call Home DOTS server functionality can be enabled on a managed CPE | Call Home DOTS server functionality can be enabled on a managed CPE | |||
or be bundled with a CPE management application that is provided by | or bundled with a CPE management application that is provided by an | |||
an ISP to its subscribers. These managed services are likely to be | ISP to its subscribers. These managed services are likely to be | |||
designed to hide the complexity of managing (including configuring) | designed to hide the complexity of managing (including configuring) | |||
the CPE. For example, managed CPEs support means to notify the user | the CPE. For example, managed CPEs support the means to notify the | |||
when a new device is detected in order to seek a confirmation whether | user when a new device is detected in order to seek confirmation as | |||
access should be granted or not to the device. These means can be | to whether or not access should be granted to the device. These | |||
upgraded to interface with the Call Home DOTS server. Customized | means can be upgraded to interface with the Call Home DOTS server. | |||
settings can be configured by users to control the notifications | Customized settings can be configured by users to control the | |||
(e.g., triggers, type) and default actions. | notifications (e.g., triggers, type) and default actions. | |||
4. Co-existence of Base DOTS Signal Channel and DOTS Call Home | 4. Coexistence of a Base DOTS Signal Channel and DOTS Call Home | |||
The DOTS signal channel Call Home does not require nor preclude the | The DOTS signal channel Call Home does not require or preclude the | |||
activation of the base DOTS signal channel | activation of the base DOTS signal channel [RFC9132]. Some sample | |||
[I-D.ietf-dots-rfc8782-bis]. Some sample deployment schemes are | deployment schemes are discussed in this section for illustration | |||
discussed in this section for illustration purposes. | purposes. | |||
The network that hosts an attack source may also be subject to | The network that hosts an attack source may also be subject to | |||
inbound DDoS attacks. In that case, both the base DOTS signal | inbound DDoS attacks. In that case, both the base DOTS signal | |||
channel and DOTS signal channel Call Home may be enabled as shown in | channel and DOTS signal channel Call Home may be enabled as shown in | |||
Figure 4 (Same DMS provider) or Figure 5 (Distinct DMS providers). | Figure 4 (same DMS provider) or Figure 5 (distinct DMS providers). | |||
DOTS Signal Channel Base DOTS | DOTS Signal Channel Base DOTS | |||
Call Home Signal Channel | Call Home Signal Channel | |||
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ | +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ | |||
: +------+ :: +------+ : | : +------+ :: +------+ : | |||
: | DOTS | :: | DOTS | : | : | DOTS | :: | DOTS | : | |||
: |client| :: |server| : | : |client| :: |server| : | |||
: +--+---+ :: +---+--+ : | : +--+---+ :: +---+--+ : | |||
: /\ | :: | : Network | : /\ | :: | : Network | |||
: || | :: | :Provider | : || | :: | :Provider | |||
skipping to change at page 9, line 26 ¶ | skipping to change at line 365 ¶ | |||
Outbound || | :: | || Inbound | Outbound || | :: | || Inbound | |||
DDoS || | :: | || DDoS | DDoS || | :: | || DDoS | |||
Attack || | :: | \/ Attack | Attack || | :: | \/ Attack | |||
: +--+---+ :: +---+--+ : | : +--+---+ :: +---+--+ : | |||
: | DOTS | :: | DOTS | : | : | DOTS | :: | DOTS | : | |||
: |server| :: |client| : | : |server| :: |client| : | |||
: +------+ :: +------+ : | : +------+ :: +------+ : | |||
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ | +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ | |||
Network #A | Network #A | |||
Figure 4: Activation of Base DOTS Signal Channel and Call Home (Same | Figure 4: Activation of a Base DOTS Signal Channel and Call Home | |||
DMS Provider) | (Same DMS Provider) | |||
Note that a DMS provider may not be on the default forwarding path of | Note that a DMS provider may not be on the default forwarding path of | |||
an inbound DDoS attack traffic targeting a network (e.g., Network #B | inbound DDoS attack traffic targeting a network (e.g., Network #B in | |||
in Figure 5). Nevertheless, the DOTS signal channel Call Home | Figure 5). Nevertheless, the DOTS signal channel Call Home requires | |||
requires the DMS provider to be on the default forwarding path of the | the DMS provider to be on the default forwarding path of the outbound | |||
outbound traffic from a given network. | traffic from a given network. | |||
DOTS Signal Channel Base DOTS | DOTS Signal Channel Base DOTS | |||
Call Home Signal Channel | Call Home Signal Channel | |||
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ | +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ | |||
: Network +------+ :: +------+ Third : | : Network +------+ :: +------+ Third : | |||
: Provider | DOTS | :: | DOTS | Party : | : Provider | DOTS | :: | DOTS | Party : | |||
: (DMS) |client| :: |server| DMS : | : (DMS) |client| :: |server| DMS : | |||
: +--+---+ :: +---+--+ Provider : | : +--+---+ :: +---+--+ Provider : | |||
: /\ | :: | : | : /\ | :: | : | |||
: || | :: | : | : || | :: | : | |||
skipping to change at page 10, line 26 ¶ | skipping to change at line 395 ¶ | |||
Outbound || | :: | || Inbound | Outbound || | :: | || Inbound | |||
DDoS || | :: | || DDoS | DDoS || | :: | || DDoS | |||
Attack || | :: | \/ Attack | Attack || | :: | \/ Attack | |||
: +--+---+ :: +---+--+ : | : +--+---+ :: +---+--+ : | |||
: | DOTS | :: | DOTS | : | : | DOTS | :: | DOTS | : | |||
: |server| :: |client| : | : |server| :: |client| : | |||
: +------+ :: +------+ : | : +------+ :: +------+ : | |||
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ | +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ | |||
Network #B | Network #B | |||
Figure 5: Activation of Base DOTS Signal Channel and Call Home | Figure 5: Activation of a Base DOTS Signal Channel and Call Home | |||
(Distinct DMS Providers) | (Distinct DMS Providers) | |||
Figures 6 and 7 depict examples where the same node embeds both base | Figures 6 and 7 depict examples where the same node embeds both base | |||
DOTS and DOTS Call Home agents. For example, a DOTS server and a | DOTS and Call Home DOTS agents. For example, a DOTS server and a | |||
Call Home DOTS client may be enabled on the same device within the | Call Home DOTS client may be enabled on the same device within the | |||
infrastructure of a DMS provider (e.g., Node #i in Figure 6) or a | infrastructure of a DMS provider (e.g., Node #i in Figure 6), or a | |||
DOTS client and a Call Home DOTS server may be enabled on the same | DOTS client and a Call Home DOTS server may be enabled on the same | |||
device within a source network (e.g., Node #j with Network #D shown | device within a source network (e.g., Node #j with Network #D shown | |||
in Figure 7) . | in Figure 7). | |||
Whether the same or distinct nodes are used to host base DOTS and | Whether the same or distinct nodes are used to host base DOTS and | |||
DOTS Call Home agents is specific to each domain. | Call Home DOTS agents is specific to each domain. | |||
DOTS Signal Channel Base DOTS | DOTS Signal Channel Base DOTS | |||
Call Home Signal Channel | Call Home Signal Channel | |||
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ | +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ | |||
: +----------------------+ : | : +----------------------+ : | |||
: | Node #i | : | : | Node #i | : | |||
: | +------+ +------+ | : | : | +------+ +------+ | : | |||
: | | DOTS | | DOTS | | : | : | | DOTS | | DOTS | | : | |||
: | |client| |server| | : | : | |client| |server| | : | |||
: | +--+---+ +---+--+ | : | : | +--+---+ +---+--+ | : | |||
skipping to change at page 11, line 28 ¶ | skipping to change at line 432 ¶ | |||
Outbound || | :: | || Inbound | Outbound || | :: | || Inbound | |||
DDoS || | :: | || DDoS | DDoS || | :: | || DDoS | |||
Attack || | :: | \/ Attack | Attack || | :: | \/ Attack | |||
: +--+---+ :: +---+--+ : | : +--+---+ :: +---+--+ : | |||
: | DOTS | :: | DOTS | : | : | DOTS | :: | DOTS | : | |||
: |server| :: |client| : | : |server| :: |client| : | |||
: +------+ :: +------+ : | : +------+ :: +------+ : | |||
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ | +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ | |||
Network #C | Network #C | |||
Figure 6: An Example of the Same Node Embedding both a Call Home DOTS | Figure 6: The Same Node Embedding a Call Home DOTS Client and a | |||
Client and a DOTS Server at the Network Provider's Side | DOTS Server at the Network Provider's Side | |||
DOTS Signal Channel Base DOTS | DOTS Signal Channel Base DOTS | |||
Call Home Signal Channel | Call Home Signal Channel | |||
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ | +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ | |||
: +----------------------+ : | : +----------------------+ : | |||
: | Node #k | : | : | Node #k | : | |||
: | +------+ +------+ | : | : | +------+ +------+ | : | |||
: | | DOTS | | DOTS | | : | : | | DOTS | | DOTS | | : | |||
: | |client| |server| | : | : | |client| |server| | : | |||
: | +--+---+ +---+--+ | : | : | +--+---+ +---+--+ | : | |||
: +----|-----::-----|----+ : Network | : +----|-----::-----|----+ : Network | |||
skipping to change at page 12, line 30 ¶ | skipping to change at line 461 ¶ | |||
: +----|-----::-----|----+ : | : +----|-----::-----|----+ : | |||
: | +--+---+ +---+--+ | : | : | +--+---+ +---+--+ | : | |||
: | | DOTS | | DOTS | | : | : | | DOTS | | DOTS | | : | |||
: | |server| |client| | : | : | |server| |client| | : | |||
: | +------+ +------+ | : | : | +------+ +------+ | : | |||
: | Node #j | : | : | Node #j | : | |||
: +----------------------+ : | : +----------------------+ : | |||
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ | +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ | |||
Network #D | Network #D | |||
Figure 7: Another Example where the Same Node Embeds both a DOTS | Figure 7: The Same Node Embedding both a DOTS Client and a Call | |||
Client and a Call Home DOTS Server | Home DOTS Server | |||
Appendix B elaborates on the considerations to unambiguously | Appendix B elaborates on the considerations to unambiguously | |||
distinguish DOTS messages which belong to each of these channels. | distinguish DOTS messages that belong to each of these channels. | |||
5. DOTS Signal Channel Call Home | 5. DOTS Signal Channel Call Home | |||
5.1. Procedure | 5.1. Procedure | |||
The DOTS signal channel Call Home preserves all but one of the DOTS | The DOTS signal channel Call Home preserves all but one of the DOTS | |||
client/server roles in the DOTS protocol stack, as compared to DOTS | client/server roles in the DOTS protocol stack, as compared to the | |||
client-initiated DOTS signal channel protocol | client-initiated DOTS signal channel protocol [RFC9132]. The role | |||
[I-D.ietf-dots-rfc8782-bis]. The role reversal that occurs is at the | reversal that occurs is at the (D)TLS layer; that is, (1) the Call | |||
(D)TLS layer; that is, (1) the Call Home DOTS server acts as a DTLS | Home DOTS server acts as a DTLS client, and the Call Home DOTS client | |||
client and the Call Home DOTS client acts as a DTLS server or (2) the | acts as a DTLS server; or (2) the Call Home DOTS server acts as a TLS | |||
Call Home DOTS server acts as a TLS client initiating the underlying | client initiating the underlying TCP connection, and the Call Home | |||
TCP connection and the Call Home DOTS client acts as a TLS server. | DOTS client acts as a TLS server. The Call Home DOTS server | |||
The Call Home DOTS server initiates (D)TLS handshake to the Call Home | initiates a (D)TLS handshake to the Call Home DOTS client. | |||
DOTS client. | ||||
For example, a home network element (e.g., home router) co-located | For example, a home network element (e.g., home router) co-located | |||
with a Call Home DOTS server is the (D)TLS client. That is, the Call | with a Call Home DOTS server is the (D)TLS client. That is, the Call | |||
Home DOTS server assumes the role of the (D)TLS client, but the | Home DOTS server assumes the role of the (D)TLS client, but the | |||
network element's role as a DOTS server remains the same. | network element's role as a DOTS server remains the same. | |||
Existing certificate chains and mutual authentication mechanisms | Existing certificate chains and mutual authentication mechanisms | |||
between the DOTS agents are unaffected by the Call Home function. | between the DOTS agents are unaffected by the Call Home function. | |||
From a deployment standpoint, and given the scale of Call Home DOTS | From a deployment standpoint, and given the scale of Call Home DOTS | |||
servers that may be involved, enabling means for automating the | servers that may be involved, enabling means for automating the | |||
skipping to change at page 13, line 33 ¶ | skipping to change at line 509 ¶ | |||
| server | | client | | | server | | client | | |||
+-----+-----+ +-----+-----+ | +-----+-----+ +-----+-----+ | |||
(D)TLS client (D)TLS server | (D)TLS client (D)TLS server | |||
| | | | | | |||
| 1. (D)TLS connection | | | 1. (D)TLS connection | | |||
|----------------------------------->| | |----------------------------------->| | |||
| 2. Mitigation request | | | 2. Mitigation request | | |||
|<-----------------------------------| | |<-----------------------------------| | |||
| ... | | | ... | | |||
Figure 8: DOTS Signal Channel Call Home Sequence Diagram | Figure 8: DOTS Signal Channel Call Home Sequence Diagram | |||
The DOTS signal channel Call Home procedure is as follows: | The DOTS signal channel Call Home procedure is as follows: | |||
1. If UDP transport is used, the Call Home DOTS server begins by | 1. If UDP transport is used, the Call Home DOTS server begins by | |||
initiating a DTLS connection to the Call Home DOTS client. | initiating a DTLS connection to the Call Home DOTS client. | |||
If TCP is used, the Call Home DOTS server begins by initiating a | If TCP is used, the Call Home DOTS server begins by initiating a | |||
TCP connection to the Call Home DOTS client. Once connected, the | TCP connection to the Call Home DOTS client. Once connected, the | |||
Call Home DOTS server continues to initiate a TLS connection to | Call Home DOTS server continues to initiate a TLS connection to | |||
the Call Home DOTS client. | the Call Home DOTS client. | |||
Peer DOTS agents may have mutual agreement to use a specific port | Peer DOTS agents may have mutual agreement to use a specific port | |||
number, such as by explicit configuration or dynamic discovery | number, such as by explicit configuration or dynamic discovery | |||
[RFC8973]. The interaction between the base DOTS signal channel | [RFC8973]. The interaction between the base DOTS signal channel | |||
and the Call Home is discussed in Appendix B. | and the Call Home is discussed in Appendix B. | |||
The Happy Eyeballs mechanism explained in Section 4.3 of | The Happy Eyeballs mechanism explained in Section 4.3 of | |||
[I-D.ietf-dots-rfc8782-bis] is used for initiating (D)TLS | [RFC9132] 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 5.3.1. | means of new attributes defined in Section 5.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-rfc8782-bis]. | the one defined in Section 4.7 of [RFC9132]. Section 5.2.1 | |||
Section 5.2.1 specifies the behavior to be followed by Call Home | specifies the behavior to be followed by Call Home DOTS agents. | |||
DOTS agents. | ||||
5.2. DOTS Signal Channel Variations | 5.2. DOTS Signal Channel Variations | |||
5.2.1. Heartbeat Mechanism | 5.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 [RFC9132]). The | |||
[I-D.ietf-dots-rfc8782-bis]). The Call Home DOTS server adjusts the | Call Home DOTS server adjusts the "heartbeat-interval" to accommodate | |||
'heartbeat-interval' to accommodate binding timers used by on-path | binding timers used by on-path NATs and firewalls. Heartbeats will | |||
NATs and firewalls. Heartbeats will be then exchanged by the DOTS | then be exchanged by the DOTS agents following the instructions | |||
agents following the instructions retrieved using the signal channel | retrieved using the signal channel session configuration exchange. | |||
session configuration exchange. | ||||
It is the responsibility of Call Home DOTS servers to ensure that on- | It is the responsibility of Call Home DOTS servers to ensure that on- | |||
path translators/firewalls are maintaining a binding so that the same | path translators/firewalls are maintaining a binding so that the same | |||
external IP address and/or port number is retained for the DOTS | external IP address and/or port number is retained for the DOTS | |||
signal channel session. A Call Home DOTS client MAY trigger their | signal channel session. A Call Home DOTS client MAY trigger their | |||
heartbeat requests immediately after receiving heartbeat probes from | heartbeat requests immediately after receiving heartbeat probes from | |||
its peer Call Home DOTS server. | its peer Call Home DOTS server. | |||
When an outgoing attack that saturates the outgoing link from the | When an outgoing attack that saturates the outgoing link from the | |||
Call Home DOTS server is detected and reported by a Call Home DOTS | Call Home DOTS server is detected and reported by a Call Home DOTS | |||
client, the latter MUST continue to use the DOTS signal channel even | client, the latter MUST continue to use the DOTS signal channel even | |||
if no traffic is received from the Call Home DOTS server. | if no traffic is received from the Call Home DOTS server. | |||
If the Call Home DOTS server receives traffic from the Call Home DOTS | If the Call Home DOTS server receives traffic from the Call Home DOTS | |||
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 threshold of allowed missing heartbeats | |||
('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 establish a new DOTS signal channel session, | server MUST try to establish a new DOTS signal channel session, | |||
preferably by resuming the (D)TLS session. | preferably by resuming the (D)TLS session. | |||
5.2.2. Redirected Signaling | 5.2.2. Redirected Signaling | |||
A Call Home DOTS server MUST NOT support the 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-rfc8782-bis] | mechanism as specified in Section 4.6 of [RFC9132] (i.e., a 5.03 | |||
(i.e., a 5.03 response that conveys an alternate DOTS server's FQDN | response that conveys an alternate DOTS server's Fully Qualified | |||
or alternate DOTS server's IP address(es)). A Call Home DOTS client | Domain Name (FQDN) or IP address(es)). A Call Home DOTS client MUST | |||
MUST silently discard such message as only a Call Home DOTS server | silently discard such a message as only a Call Home DOTS server can | |||
can initiate a new (D)TLS connection. | initiate a new (D)TLS connection. | |||
If a Call Home DOTS client wants to redirect a Call Home DOTS server | 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 | to another Call Home DOTS client, it MUST send a Non-confirmable PUT | |||
request to the predefined resource ".well-known/dots/redirect" with | request to the predefined resource ".well-known/dots/redirect" with | |||
the following attributes in the body of the PUT request: | the following attributes in the body of the PUT request: | |||
alt-ch-client: The FQDN of an alternate Call Home DOTS client. It | alt-ch-client: The FQDN of an alternate Call Home DOTS client. It | |||
is also presented as reference identifier for authentication | is also presented as a reference identifier for authentication | |||
purposes. | purposes. | |||
This is a mandatory attribute for DOTS signal Call Home. It MUST | This is a mandatory attribute for DOTS signal Call Home. It MUST | |||
NOT be used for base DOTS signal channel operations. | NOT be used for base DOTS signal channel operations. | |||
alt-ch-client-record: List of IP addresses for the alternate Call | alt-ch-client-record: List of IP addresses for the alternate Call | |||
Home DOTS client. If no 'alt-ch-client-record' is provided, the | Home DOTS client. If no "alt-ch-client-record" is provided, the | |||
Call Home DOTS server passes the 'alt-ch-client' name to a name | Call Home DOTS server passes the "alt-ch-client" name to a name | |||
resolution library to retrieve one or more IP addresses of the | resolution library to retrieve one or more IP addresses of the | |||
alternate Call Home DOTS client. | alternate Call Home DOTS client. | |||
This is an optional attribute for DOTS signal Call Home. It MUST | This is an optional attribute for DOTS signal Call Home. It MUST | |||
NOT be used for base DOTS signal channel operations. | NOT be used for base DOTS signal channel operations. | |||
ttl: The Time to live (TTL) of the alternate Call Home DOTS client. | ttl: The Time To Live (TTL) of the alternate Call Home DOTS client. | |||
That is, the time interval that the alternate Call Home DOTS | That is, the time interval in which the alternate Call Home DOTS | |||
client may be cached for use by a Call Home DOTS server. | client may be cached for use by a Call Home DOTS server. | |||
This is an optional attribute for DOTS signal Call Home. It MUST | This is an optional attribute for DOTS signal Call Home. It MUST | |||
NOT be used for base DOTS signal channel operations. | NOT be used for base DOTS signal channel operations. | |||
On receipt of this PUT request, the Call Home DOTS server responds | On receipt of this PUT request, the Call Home DOTS server responds | |||
with a 2.01 (Created), closes this connection and establishes a | with a 2.01 (Created), closes this connection, and establishes a | |||
connection with the new Call Home DOTS client. The processing of the | connection with the new Call Home DOTS client. The processing of the | |||
TTL is defined in Section 4.6 of [I-D.ietf-dots-rfc8782-bis]. If the | TTL is defined in Section 4.6 of [RFC9132]. If the Call Home DOTS | |||
Call Home DOTS server cannot service the PUT request, the response is | server cannot service the PUT request, the response is rejected with | |||
rejected with a 4.00 (Bad Request). | a 4.00 (Bad Request). | |||
Figure 9 shows a PUT request example to convey the alternate Call | Figure 9 shows a PUT request example to convey the alternate Call | |||
Home DOTS client 'alt-call-home-client.example' together with its IP | 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 | addresses 2001:db8:6401::1 and 2001:db8:6401::2. The validity of | |||
this alternate Call Home DOTS client is 10 minutes. | this alternate Call Home DOTS client is 10 minutes. | |||
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: "redirect" | Uri-Path: "redirect" | |||
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" | Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" | |||
Uri-Path: "mid=123" | Uri-Path: "mid=123" | |||
Content-Format: "application/dots+cbor" | Content-Format: "application/dots+cbor" | |||
skipping to change at page 16, line 26 ¶ | skipping to change at line 644 ¶ | |||
"alt-call-home-client.example", | "alt-call-home-client.example", | |||
"ietf-dots-call-home:alt-ch-client-record": [ | "ietf-dots-call-home:alt-ch-client-record": [ | |||
"2001:db8:6401::1", | "2001:db8:6401::1", | |||
"2001:db8:6401::2" | "2001:db8:6401::2" | |||
], | ], | |||
"ietf-dots-call-home:ttl": 600 | "ietf-dots-call-home:ttl": 600 | |||
} | } | |||
Figure 9: Example of a PUT Request for Redirected Signaling | Figure 9: Example of a PUT Request for Redirected Signaling | |||
Figure 9 uses the JSON encoding of YANG-modeled data for the CoAP | ||||
message body. The same encoding is used in Figure 10 | ||||
(Section 5.3.1). | ||||
5.3. DOTS Signal Channel Extension | 5.3. DOTS Signal Channel Extension | |||
5.3.1. Mitigation Request | 5.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-rfc8782-bis] to convey the attack | Section 4.4.1 of [RFC9132] to convey the attack source information | |||
source information (e.g., source prefixes, source port numbers). The | (e.g., source prefixes, source port numbers). The DOTS client | |||
DOTS client conveys the following new parameters in the CBOR body of | conveys the following new parameters in the Concise Binary Object | |||
the mitigation request: | Representation (CBOR) body of the mitigation request: | |||
source-prefix: A list of attacker IP prefixes used to attack the | source-prefix: A list of attacker IP prefixes used to attack the | |||
target. Prefixes are represented using Classless Inter-Domain | target. Prefixes are represented using Classless Inter-Domain | |||
Routing (CIDR) notation BCP 122 [RFC4632]. | Routing (CIDR) notation (BCP 122 [RFC4632]). | |||
As a reminder, the prefix length MUST be less than or equal to 32 | As a reminder, the prefix length MUST be less than or equal to 32 | |||
(or 128) for IPv4 (or IPv6). | (or 128) for IPv4 (or IPv6). | |||
The prefix list MUST NOT include broadcast, loopback, or multicast | The prefix list MUST NOT include broadcast, loopback, or multicast | |||
addresses. These addresses are considered as invalid values. | addresses. These addresses are considered invalid values. Note | |||
Note that link-local addresses are allowed. The Call Home DOTS | that link-local addresses are allowed. The Call Home DOTS client | |||
client MUST validate that attacker prefixes are within the scope | MUST validate that attacker prefixes are within the scope of the | |||
of the Call Home DOTS server domain (e.g., prefixes assigned to | Call Home DOTS server domain (e.g., prefixes assigned to the Call | |||
the Call Home DOTS server domain or networks it services). This | Home DOTS server domain or networks it services). This check is | |||
check is meant to avoid contacting Call Home DOTS servers that are | meant to avoid contacting Call Home DOTS servers that are not | |||
not entitled to enforce actions on specific prefixes. | entitled to enforce actions on specific prefixes. | |||
This is an optional attribute for the base DOTS signal channel | This is an optional attribute for the base DOTS signal channel | |||
operations. | operations. | |||
source-port-range: A list of port numbers used by the attack traffic | source-port-range: A list of port numbers used by the attack traffic | |||
flows. | flows. | |||
A port range is defined by two bounds, a lower port number (lower- | A port range is defined by two bounds, a lower port number | |||
port) and an upper port number (upper-port). When only 'lower- | ("lower-port") and an upper port number ("upper-port"). When only | |||
port' is present, it represents a single port number. | "lower-port" is present, it represents a single port number. | |||
For TCP, UDP, Stream Control Transmission Protocol (SCTP) | For TCP, UDP, Stream Control Transmission Protocol (SCTP) | |||
[RFC4960], or Datagram Congestion Control Protocol (DCCP) | [RFC4960], or Datagram Congestion Control Protocol (DCCP) | |||
[RFC4340], a range of ports can be any subrange of 0-65535, for | [RFC4340], a range of ports can be any subrange of 0-65535 -- for | |||
example, 0-1023, 1024-65535, or 1024-49151. | example, 0-1023, 1024-65535, or 1024-49151. | |||
This is an optional attribute for the base DOTS signal channel | This is an optional attribute for the base DOTS signal channel | |||
operations. | operations. | |||
source-icmp-type-range: A list of ICMP types used by the attack | source-icmp-type-range: A list of ICMP types used by the attack | |||
traffic flows. An ICMP type range is defined by two bounds, a | traffic flows. An ICMP type range is defined by two bounds, a | |||
lower ICMP type (lower-type) and an upper ICMP type (upper-type). | lower ICMP type (lower-type) and an upper ICMP type (upper-type). | |||
When only 'lower-type' is present, it represents a single ICMP | When only "lower-type" is present, it represents a single ICMP | |||
type. Both ICMP [RFC0792] and ICMPv6 [RFC4443] types are | type. Both ICMP [RFC0792] and ICMPv6 [RFC4443] types are | |||
supported. Whether ICMP or ICMPv6 types are to be used is | supported. Whether ICMP or ICMPv6 types are to be used is | |||
determined by the address family of the 'target-prefix'. | determined by the address family of the "target-prefix". | |||
This is an optional attribute for the base DOTS signal channel | This is an optional attribute for the base DOTS signal channel | |||
operations. | operations. | |||
The 'source-prefix' parameter is a mandatory attribute when the | The "source-prefix" parameter is a mandatory attribute when the | |||
attack traffic information is signaled by a Call Home DOTS client | attack traffic information is signaled by a Call Home DOTS client | |||
(i.e., the Call Home scenario depicted in Figure 8). The 'target- | (i.e., the Call Home scenario depicted in Figure 8). The "target- | |||
prefix' attribute MUST be included in the mitigation request | prefix" attribute MUST be included in the mitigation request | |||
signaling the attack information to a Call Home DOTS server. The | signaling the attack information to a Call Home DOTS server. The | |||
'target-uri' or 'target-fqdn' parameters can be included in a | "target-uri" or "target-fqdn" parameters can be included in a | |||
mitigation request for diagnostic purposes to notify the Call Home | mitigation request for diagnostic purposes to notify the Call Home | |||
DOTS server domain administrator, but SHOULD NOT be used to determine | DOTS server domain administrator but SHOULD NOT be used to determine | |||
the target IP addresses. 'alias-name' is unlikely to be conveyed in | the target IP addresses. "alias-name" is unlikely to be conveyed in | |||
a Call Home mitigation request given that a target may be any IP | a Call Home mitigation request given that a target may be any IP | |||
resource and that there is no incentive for a Call Home DOTS server | resource and that there is no incentive for a Call Home DOTS server | |||
(embedded, for example, in a CPE) to maintain aliases. | (embedded, for example, in a CPE) to maintain aliases. | |||
In order to help attack source identification by a Call Home DOTS | In order to help attack source identification by a Call Home DOTS | |||
server, the Call Home DOTS client SHOULD include in its mitigation | server, the Call Home DOTS client SHOULD include in its mitigation | |||
request additional information such as 'source-port-range' or | request additional information such as "source-port-range" or | |||
'source-icmp-type-range' to disambiguate nodes sharing the same | "source-icmp-type-range" to disambiguate nodes sharing the same | |||
'source-prefix'. IPv6 addresses/prefixes are sufficient to uniquely | "source-prefix". IPv6 addresses/prefixes are sufficient to uniquely | |||
identify a network endpoint, without need for port numbers or ICMP | identify a network endpoint, without need for port numbers or ICMP | |||
type information. While this is also possible for IPv4, it is much | type information. While this is also possible for IPv4, it is much | |||
less often the case than for IPv6. More address sharing implications | less often the case than for IPv6. More address sharing implications | |||
on the setting of source information ('source-prefix', 'source-port- | on the setting of source information ("source-prefix", "source-port- | |||
range') are discussed in Section 5.3.2. | range") are discussed in Section 5.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 10. | shown in Figure 10. | |||
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" | |||
skipping to change at page 18, line 41 ¶ | skipping to change at line 759 ¶ | |||
], | ], | |||
"ietf-dots-call-home:source-prefix": [ | "ietf-dots-call-home:source-prefix": [ | |||
"2001:db8:123::1/128" | "2001:db8:123::1/128" | |||
], | ], | |||
"lifetime": 3600 | "lifetime": 3600 | |||
} | } | |||
] | ] | |||
} | } | |||
} | } | |||
Figure 10: An Example of Mitigation Request Issued by a Call Home | Figure 10: An Example of a Mitigation Request Issued by a Call | |||
DOTS Client | Home DOTS 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 routable 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 [RFC9132]. | |||
[I-D.ietf-dots-rfc8782-bis]. | ||||
Note: These validation checks do not apply when the source | Note: These validation checks do not apply when the source | |||
information is included as a hint in the context of the base DOTS | information is included as a hint in the context of the base DOTS | |||
signal channel. | signal channel. | |||
The Call Home DOTS server domain administrator consent MAY be | Call Home DOTS server domain administrator consent MAY be required to | |||
required to block the traffic from the compromised device to the | block the traffic from the compromised device to the attack target. | |||
attack target. An implementation MAY have a configuration knob to | An implementation MAY have a configuration knob to block the traffic | |||
block the traffic from the compromised device to the attack target | from the compromised device to the attack target with or without DOTS | |||
with or without DOTS server domain administrator consent. | server domain administrator consent. | |||
If a consent from the Call Home DOTS server domain administrator is | If consent from the Call Home DOTS server domain administrator is | |||
required, the Call Home DOTS server replies with 2.01 (Created) and | required, the Call Home DOTS server replies with 2.01 (Created) and | |||
'status' code set to 1 (attack-mitigation-in-progress). Then, the | the "status" code set to 1 (attack-mitigation-in-progress). Then, | |||
mechanisms defined in Section 4.4.2 of [I-D.ietf-dots-rfc8782-bis] | the mechanisms defined in Section 4.4.2 of [RFC9132] are followed by | |||
are followed by the DOTS agents to update the mitigation status. | the DOTS agents to update the mitigation status. In particular, if | |||
Particularly, if the attack traffic is blocked, the Call Home DOTS | the attack traffic is blocked, the Call Home DOTS server informs the | |||
server informs the Call Home DOTS client that the attack is being | Call Home DOTS client that the attack is being mitigated (i.e., by | |||
mitigated (i.e., by setting the 'status' code to 2 (attack- | setting the "status" code to 2 (attack-successfully-mitigated)). | |||
successfully-mitigated)). | ||||
If the attack traffic information is identified by the Call Home DOTS | If the attack traffic information is identified by the Call Home DOTS | |||
server or the Call Home DOTS server domain administrator as | server or the Call Home DOTS server domain administrator as | |||
legitimate traffic, the mitigation request is rejected with a 4.09 | legitimate traffic, the mitigation request is rejected with a 4.09 | |||
(Conflict) (e.g., when no consent is required from an administrator) | (Conflict) (e.g., when no consent is required from an administrator) | |||
or a notification message with the 'conflict-clause' (Section 4.4.1 | or a notification message with the "conflict-clause" (Section 4.4.1 | |||
of [I-D.ietf-dots-rfc8782-bis]) set to the following new value: | of [RFC9132]) set to the following new value: | |||
4: Mitigation request rejected. This code is returned by the DOTS | 4: Mitigation request rejected. This code is returned by the DOTS | |||
server to indicate the attack traffic has been classified as | server to indicate the attack traffic has been classified as | |||
legitimate traffic. | legitimate traffic. | |||
Once the request is validated by the Call Home DOTS server, | Once the request is validated by the Call Home DOTS server, | |||
appropriate actions are enforced to block the attack traffic within | appropriate actions are enforced to block the attack traffic within | |||
the source network. For example, if the Call Home DOTS server is | the source network. For example, if the Call Home DOTS server is | |||
embedded in a CPE, it can program the packet processor to punt all | embedded in a CPE, it can program the packet processor to punt all | |||
the traffic from the compromised device to the target to slow path. | the traffic from the compromised device to the target to slow path. | |||
The CPE inspects the punted slow path traffic to detect and block the | The CPE inspects the punted slow path traffic to detect and block the | |||
outgoing DDoS attack traffic or quarantine the device (e.g., using | outgoing DDoS attack traffic or quarantine the device (e.g., using | |||
MAC level filtering) until it is remediated, and notifies the CPE | MAC-level filtering) until it is remediated and notifies the CPE | |||
administrator about the compromised device. Note that the Call Home | administrator about the compromised device. Note that the Call Home | |||
DOTS client is informed about the progress of the attack mitigation | DOTS client is informed about the progress of the attack mitigation | |||
following the rules in Section 4.4.2 of [I-D.ietf-dots-rfc8782-bis]. | following the rules in Section 4.4.2 of [RFC9132]. | |||
The DOTS agents follow the same procedures specified in | The DOTS agents follow the same procedures specified in [RFC9132] for | |||
[I-D.ietf-dots-rfc8782-bis] for managing a mitigation request. | managing a mitigation request. | |||
5.3.2. Address Sharing Considerations | 5.3.2. Address Sharing Considerations | |||
Figure 11 depicts an example of a network provider that hosts a Call | Figure 11 depicts an example of a network provider that hosts a Call | |||
Home DOTS client and deploys a Carrier Grade NAT (CGN) between the | Home DOTS client and deploys a Carrier-Grade NAT (CGN) between the | |||
DOTS client domain and DOTS server domain. In such cases, | DOTS client domain and DOTS server domain. In such cases, | |||
communicating an external IP address in a mitigation request by a | communicating an external IP address in a mitigation request by a | |||
Call Home DOTS client is likely to be discarded by the Call Home DOTS | Call Home DOTS client is likely to be discarded by the Call Home DOTS | |||
server because the external IP address is not visible locally to the | server because the external IP address is not visible locally to the | |||
Call Home DOTS server (Figure 11). The Call Home DOTS server is only | Call Home DOTS server (Figure 11). The Call Home DOTS server is only | |||
aware of the internal IP addresses/prefixes bound to its domain | aware of the internal IP addresses/prefixes bound to its domain | |||
(i.e., those used in the Internal Realm shown in Figure 11). Thus, | (i.e., those used in the internal realm shown in Figure 11). Thus, | |||
Call Home DOTS clients that are aware of the presence of on-path CGNs | Call Home DOTS clients that are aware of the presence of on-path CGNs | |||
MUST NOT include the external IP address and/or port number | MUST NOT include the external IP address and/or port number | |||
identifying the suspect attack source (i.e., those used in the | identifying the suspect attack source (i.e., those used in the | |||
External Realm shown in Figure 11), but MUST include the internal IP | external realm shown in Figure 11) but MUST include the internal IP | |||
address and/or port number. To that aim, the Call Home DOTS client | address and/or port number. To that aim, the Call Home DOTS client | |||
SHOULD rely on mechanisms, such as [RFC8512] or [RFC8513], to | SHOULD rely on mechanisms, such as those described in [RFC8512] or | |||
retrieve the internal IP address and port number which are mapped to | [RFC8513], to retrieve the internal IP address and port number that | |||
an external IP address and port number. For the particular case of | are mapped to an external IP address and port number. For the | |||
NAT64 [RFC6146], if the target address is an IPv4 address, the | particular case of NAT64 [RFC6146], if the target address is an IPv4 | |||
IPv4-converted IPv6 address of this target address [RFC6052] SHOULD | address, the IPv4-converted IPv6 address of this target address | |||
be used. | [RFC6052] SHOULD be used. | |||
N | .-------------------. | N | .-------------------. | |||
E | ( )-. | E | ( )-. | |||
T | .' ' | T | .' ' | |||
W | ( Call Home ) | W | ( Call Home ) | |||
O | ( DOTS client -' | O | ( DOTS client -' | |||
R | '-( ) | R | '-( ) | |||
K | '-------+-----------' | K | '-------+-----------' | |||
| | | | | | |||
P | | | P | | | |||
skipping to change at page 21, line 34 ¶ | skipping to change at line 866 ¶ | |||
.' Source Network ' | .' Source Network ' | |||
( ) | ( ) | |||
( Call Home -' | ( Call Home -' | |||
'-( DOTS server ) | '-( DOTS server ) | |||
'------+------------' | '------+------------' | |||
| | | | |||
+-----+-------+ | +-----+-------+ | |||
|Attack Source| | |Attack Source| | |||
+-------------+ | +-------------+ | |||
Figure 11: Example of a CGN between DOTS Domains | Figure 11: Example of a CGN between DOTS Domains | |||
If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the | If a Mapping of Address and Port (MAP) Border Relay [RFC7597] or | |||
provider's domain to service its customers, the identification of an | Lightweight Address Family Transition Router (lwAFTR) [RFC7596] is | |||
attack source bound to an IPv4 address/prefix MUST also rely on | enabled in the provider's domain to service its customers, the | |||
source port numbers because the same IPv4 address is assigned to | identification of an attack source bound to an IPv4 address/prefix | |||
multiple customers. The port information is required to | MUST also rely on source port numbers because the same IPv4 address | |||
unambiguously identify the source of an attack. | is assigned to multiple customers. The port information is required | |||
to 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 12 and 13), the Call Home DOTS server uses the attack traffic | Figures 12 and 13), 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. The Call Home DOTS server proceeds | mitigation request is withdrawn. The Call Home DOTS server proceeds | |||
with a NAT mapping table lookup using the attack information (or a | with a NAT mapping table lookup using the attack information (or a | |||
subset thereof) as a key. The lookup can be local (Figure 12) or via | subset thereof) as a key. The lookup can be local (Figure 12) or via | |||
skipping to change at page 22, line 33 ¶ | skipping to change at line 915 ¶ | |||
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 12: Example of a DOTS Server Domain with a NAT Embedded in a | Figure 12: Example of a DOTS Server Domain with a NAT Embedded in | |||
CPE | a CPE | |||
.-------------------. | .-------------------. | |||
( )-. | ( )-. | |||
.' Network Provider (DMS) ' | .' Network Provider (DMS) ' | |||
( ) | ( ) | |||
( Call Home -' | ( Call Home -' | |||
'-( DOTS client ) | '-( DOTS client ) | |||
'---------+---------' | '---------+---------' | |||
| | | | |||
--- +-----+-----+ | --- +-----+-----+ | |||
skipping to change at page 23, line 32 ¶ | skipping to change at line 945 ¶ | |||
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 13: Example of a Call Home DOTS Server and a NAT Embedded in a | Figure 13: Example of a Call Home DOTS Server and a NAT Embedded | |||
CPE | in a CPE | |||
If for any reason address sharing is deployed in both source and | If, for any reason, address sharing is deployed in both source and | |||
provider networks, both Call Home DOTS agents have to proceed with | provider networks, both Call Home DOTS agents have to proceed with | |||
address mapping lookups following the behavior specified in reference | address mapping lookups following the behavior specified in reference | |||
to Figure 11 (network provider) and Figures 12 and 13 (source | to Figure 11 (network provider) and Figures 12 and 13 (source | |||
network). | network). | |||
6. DOTS Signal Call Home YANG Module | 6. DOTS Signal Call Home YANG Module | |||
6.1. Tree Structure | 6.1. Tree Structure | |||
This document augments the "ietf-dots-signal-channel" (dots-signal) | This document augments the "ietf-dots-signal-channel" (dots-signal) | |||
DOTS signal YANG module defined in [I-D.ietf-dots-rfc8782-bis] for | DOTS signal YANG module defined in [RFC9132] for signaling the attack | |||
signaling the attack traffic information. This document defines the | traffic information. This document defines the YANG module "ietf- | |||
YANG module "ietf-dots-call-home", which has the following tree | dots-call-home", which has the following tree structure: | |||
structure: | ||||
module: ietf-dots-call-home | module: ietf-dots-call-home | |||
augment-structure /dots-signal:dots-signal/dots-signal:message-type | augment-structure /dots-signal:dots-signal/dots-signal:message-type | |||
/dots-signal:mitigation-scope/dots-signal:scope: | /dots-signal:mitigation-scope/dots-signal:scope: | |||
+-- source-prefix* inet:ip-prefix | +-- source-prefix* inet:ip-prefix | |||
+-- source-port-range* [lower-port] | +-- source-port-range* [lower-port] | |||
| +-- lower-port inet:port-number | | +-- lower-port inet:port-number | |||
| +-- upper-port? inet:port-number | | +-- upper-port? inet:port-number | |||
+-- source-icmp-type-range* [lower-type] | +-- source-icmp-type-range* [lower-type] | |||
skipping to change at page 24, line 28 ¶ | skipping to change at line 986 ¶ | |||
+-- (type)? | +-- (type)? | |||
+--:(call-home-only) | +--:(call-home-only) | |||
+-- alt-ch-client inet:domain-name | +-- alt-ch-client inet:domain-name | |||
+-- alt-ch-client-record* inet:ip-address | +-- alt-ch-client-record* inet:ip-address | |||
+-- ttl? uint32 | +-- ttl? uint32 | |||
6.2. YANG/JSON Mapping Parameters to CBOR | 6.2. YANG/JSON Mapping Parameters to CBOR | |||
The YANG/JSON mapping parameters to CBOR are listed in Table 1. | The YANG/JSON mapping parameters to CBOR are listed in Table 1. | |||
o Note: Implementers must check that the mapping output provided by | Note: Implementers must check that the mapping output provided by | |||
their YANG-to-CBOR encoding schemes is aligned with the content of | their YANG-to-CBOR encoding schemes is aligned with the content of | |||
Table 1. | Table 1. | |||
+--------------------+------------+------+---------------+--------+ | +========================+=============+=====+=============+========+ | |||
| Parameter Name | YANG | CBOR | CBOR Major | JSON | | |Parameter Name |YANG Type |CBOR |CBOR Major | JSON | | |||
| | Type | Key | Type & | Type | | | | |Key |Type & | Type | | |||
| | | | Information | | | | | |Value|Information | | | |||
+====================+============+======+===============+========+ | +========================+=============+=====+=============+========+ | |||
|ietf-dots-call-home:| leaf-list | | | | | |ietf-dots-call- |leaf-list |32768|4 array | Array | | |||
| source-prefix | inet: | TBA1 | 4 array | Array | | |home:source-prefix |inet:ip- | |3 text string| String | | |||
| | ip-prefix | | 3 text string | String | | | |prefix | | | | | |||
+--------------------+------------+------+---------------+--------+ | +------------------------+-------------+-----+-------------+--------+ | |||
|ietf-dots-call-home:| | | | | | |ietf-dots-call- |list |32769|4 array | Array | | |||
| source-port-range | list | TBA2 | 4 array | Array | | |home:source-port-range | | | | | | |||
+--------------------+------------+------+---------------+--------+ | +------------------------+-------------+-----+-------------+--------+ | |||
|ietf-dots-call-home:| | | | | | |ietf-dots-call- |list |32770|4 array | Array | | |||
| source-icmp-type- | list | TBA3 | 4 array | Array | | |home:source-icmp-type- | | | | | | |||
| range | | | | | | |range | | | | | | |||
+--------------------+------------+------+---------------+--------+ | +------------------------+-------------+-----+-------------+--------+ | |||
| lower-type | uint8 | TBA4 | 0 unsigned | Number | | |lower-type |uint8 |32771|0 unsigned | Number | | |||
+--------------------+------------+------+---------------+--------+ | +------------------------+-------------+-----+-------------+--------+ | |||
| upper-type | uint8 | TBA5 | 0 unsigned | Number | | |upper-type |uint8 |32772|0 unsigned | Number | | |||
+--------------------+------------+------+---------------+--------+ | +------------------------+-------------+-----+-------------+--------+ | |||
|ietf-dots-call-home:| inet: | | | | | |ietf-dots-call-home:alt-|inet: domain-|32773|3 text string| String | | |||
| alt-ch-client | domain-name| TBA6 | 3 text string | String | | |ch-client |name | | | | | |||
+--------------------+------------+------+---------------+--------+ | +------------------------+-------------+-----+-------------+--------+ | |||
|ietf-dots-call-home:| leaf-list | TBA7 | 4 array | Array | | |ietf-dots-call-home:alt-|leaf-list |32774|4 array | Array | | |||
| alt-ch-client- | inet: | | | | | |ch-client-record |inet:ip- | |3 text string| String | | |||
| record | ip-address| | 3 text string | String | | | |address | | | | | |||
+--------------------+------------+------+---------------+--------+ | +------------------------+-------------+-----+-------------+--------+ | |||
|ietf-dots-call-home:| | | | | | |ietf-dots-call-home:ttl |uint32 |32775|0 unsigned | Number | | |||
| ttl | uint32 | TBA8 | 0 unsigned | Number | | +------------------------+-------------+-----+-------------+--------+ | |||
+--------------------+------------+------+---------------+--------+ | ||||
Table 1: YANG/JSON Mapping Parameters to CBOR | Table 1: YANG/JSON Mapping Parameters to CBOR | |||
The YANG/JSON mappings to CBOR for 'lower-port' and 'upper-port' are | The YANG/JSON mappings to CBOR for "lower-port" and "upper-port" are | |||
already defined in Table 5 of [I-D.ietf-dots-rfc8782-bis]. | already defined in Table 5 of [RFC9132]. | |||
6.3. YANG Module | 6.3. YANG Module | |||
This module uses the common YANG types defined in [RFC6991] and the | This module uses the common YANG types defined in [RFC6991] and the | |||
data structure extension defined in [RFC8791]. | data structure extension defined in [RFC8791]. | |||
<CODE BEGINS> file "ietf-dots-call-home@2020-12-02.yang" | <CODE BEGINS> file "ietf-dots-call-home@2021-09-27.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 dots-call-home; | prefix dots-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"; | |||
} | } | |||
import ietf-dots-signal-channel { | import ietf-dots-signal-channel { | |||
prefix dots-signal; | prefix dots-signal; | |||
reference | reference | |||
"RFC YYYY: Distributed Denial-of-Service Open Threat | "RFC 9132: Distributed Denial-of-Service Open Threat | |||
Signaling (DOTS) Signal Channel Specification"; | Signaling (DOTS) Signal Channel Specification"; | |||
} | } | |||
import ietf-yang-structure-ext { | import ietf-yang-structure-ext { | |||
prefix sx; | prefix sx; | |||
reference | reference | |||
"RFC 8791: YANG Data Structure Extensions"; | "RFC 8791: YANG Data Structure Extensions"; | |||
} | } | |||
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> | |||
Author: Konda, Tirumaleswar Reddy | Author: Konda, Tirumaleswar Reddy | |||
<mailto:TirumaleswarReddy_Konda@McAfee.com>; | <mailto:kondtir@gmail.com>; | |||
Author: Mohamed Boucadair | Author: Mohamed Boucadair | |||
<mailto:mohamed.boucadair@orange.com>; | <mailto:mohamed.boucadair@orange.com>; | |||
Author: 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. | |||
skipping to change at page 26, line 49 ¶ | skipping to change at line 1082 ¶ | |||
Copyright (c) 2021 IETF Trust and the persons identified as | Copyright (c) 2021 IETF Trust and the persons identified as | |||
authors of the code. All rights reserved. | authors of the code. All rights reserved. | |||
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 9066; see | |||
the RFC itself for full legal notices."; | the RFC itself for full legal notices."; | |||
revision 2020-12-02 { | revision 2021-09-27 { | |||
description | description | |||
"Initial revision."; | "Initial revision."; | |||
reference | reference | |||
"RFC XXXX: Distributed Denial-of-Service Open Threat | "RFC 9066: Distributed Denial-of-Service Open Threat | |||
Signaling (DOTS) Signal Channel Call Home"; | Signaling (DOTS) Signal Channel Call Home"; | |||
} | } | |||
sx:augment-structure "/dots-signal:dots-signal" | sx:augment-structure "/dots-signal:dots-signal" | |||
+ "/dots-signal:message-type" | + "/dots-signal:message-type" | |||
+ "/dots-signal:mitigation-scope" | + "/dots-signal:mitigation-scope" | |||
+ "/dots-signal:scope" { | + "/dots-signal:scope" { | |||
description | description | |||
"Attack source details."; | "Attack source details."; | |||
leaf-list source-prefix { | leaf-list source-prefix { | |||
type inet:ip-prefix; | type inet:ip-prefix; | |||
skipping to change at page 27, line 38 ¶ | skipping to change at line 1118 ¶ | |||
leaf lower-port { | leaf lower-port { | |||
type inet:port-number; | type inet:port-number; | |||
description | description | |||
"Lower port number of the port range."; | "Lower port number of the port range."; | |||
} | } | |||
leaf upper-port { | leaf upper-port { | |||
type inet:port-number; | type inet:port-number; | |||
must '. >= ../lower-port' { | must '. >= ../lower-port' { | |||
error-message | error-message | |||
"The upper port number must be greater than | "The upper port number must be greater than | |||
or equal to lower port number."; | or equal to the lower port number."; | |||
} | } | |||
description | description | |||
"Upper port number of the port range."; | "Upper port number of the port range."; | |||
} | } | |||
} | } | |||
list source-icmp-type-range { | list source-icmp-type-range { | |||
key "lower-type"; | key "lower-type"; | |||
description | description | |||
"ICMP/ICMPv6 type range. When only lower-type is | "ICMP/ICMPv6 type range. When only lower-type is | |||
present, it represents a single ICMP/ICMPv6 type. | present, it represents a single ICMP/ICMPv6 type. | |||
The address family of the target-prefix is used | The address family of the target-prefix is used | |||
to determine whether ICMP or ICMPv6 are used."; | to determine whether ICMP or ICMPv6 is used."; | |||
leaf lower-type { | leaf lower-type { | |||
type uint8; | type uint8; | |||
description | description | |||
"Lower ICMP/ICMPv6 type of the ICMP type range."; | "Lower ICMP/ICMPv6 type of the ICMP type range."; | |||
reference | reference | |||
"RFC 792: Internet Control Message Protocol | "RFC 792: Internet Control Message Protocol | |||
RFC 4443: Internet Control Message Protocol (ICMPv6) | RFC 4443: Internet Control Message Protocol (ICMPv6) | |||
for Internet Protocol Version 6 (IPv6) | for the Internet Protocol Version 6 (IPv6) | |||
Specification."; | Specification."; | |||
} | } | |||
leaf upper-type { | leaf upper-type { | |||
type uint8; | type uint8; | |||
must '. >= ../lower-type' { | must '. >= ../lower-type' { | |||
error-message | error-message | |||
"The upper ICMP/ICMPv6 type must be greater than | "The upper ICMP/ICMPv6 type must be greater than | |||
or equal to lower ICMP type."; | or equal to the lower ICMP type."; | |||
} | } | |||
description | description | |||
"Upper type of the ICMP type range."; | "Upper type of the ICMP type range."; | |||
reference | reference | |||
"RFC 792: Internet Control Message Protocol | "RFC 792: Internet Control Message Protocol | |||
RFC 4443: Internet Control Message Protocol (ICMPv6) | RFC 4443: Internet Control Message Protocol (ICMPv6) | |||
for Internet Protocol Version 6 (IPv6) | for the Internet Protocol Version 6 (IPv6) | |||
Specification."; | Specification."; | |||
} | } | |||
} | } | |||
} | } | |||
sx:augment-structure "/dots-signal:dots-signal" | sx:augment-structure "/dots-signal:dots-signal" | |||
+ "/dots-signal:message-type" | + "/dots-signal:message-type" | |||
+ "/dots-signal:redirected-signal" { | + "/dots-signal:redirected-signal" { | |||
description | description | |||
"Augments the redirected signal to communicate an | "Augments the redirected signal to communicate an | |||
alternate Call Home DOTS client."; | alternate Call Home DOTS client."; | |||
choice type { | choice type { | |||
description | description | |||
"Indicates the type of the DOTS session (e.g., base | "Indicates the type of the DOTS session (e.g., base | |||
DOTS signal channel, DOTS Call Home)."; | DOTS signal channel, DOTS Call Home)."; | |||
case call-home-only { | case call-home-only { | |||
description | description | |||
"These attributes appear only in a call home signal | "These attributes appear only in a signal Call Home | |||
channel message from a Call Home DOTS client | channel message from a Call Home DOTS client | |||
to a Call Home DOTS server."; | to a Call Home DOTS server."; | |||
leaf alt-ch-client { | leaf alt-ch-client { | |||
type inet:domain-name; | type inet:domain-name; | |||
mandatory true; | mandatory true; | |||
description | description | |||
"FQDN of an alternate Call Home DOTS client. | "FQDN of an alternate Call Home DOTS client. | |||
This name is also presented as reference | This name is also presented as a reference | |||
identifier for authentication purposes."; | identifier for authentication purposes."; | |||
} | } | |||
leaf-list alt-ch-client-record { | leaf-list alt-ch-client-record { | |||
type inet:ip-address; | type inet:ip-address; | |||
description | description | |||
"List of IP addresses for the alternate Call | "List of IP addresses for the alternate Call | |||
Home DOTS client. | Home DOTS client. | |||
If this data node is not present, a Call Home | If this data node is not present, a Call Home | |||
DOTS server resolves the alt-ch-client into | DOTS server resolves the alt-ch-client into | |||
one or more IP addresses."; | one or more IP addresses."; | |||
} | } | |||
leaf ttl { | leaf ttl { | |||
type uint32; | type uint32; | |||
units "seconds"; | units "seconds"; | |||
description | description | |||
"The Time to live (TTL) of the alternate Call Home | "The Time To Live (TTL) of the alternate Call Home | |||
DOTS client."; | DOTS client."; | |||
reference | reference | |||
"Section 4.6 of RFC YYYY"; | "Section 4.6 of RFC 9132"; | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
} | } | |||
<CODE ENDS> | <CODE ENDS> | |||
7. IANA Considerations | 7. IANA Considerations | |||
7.1. DOTS Signal Channel CBOR Mappings Registry | 7.1. DOTS Signal Channel CBOR Mappings Registry | |||
This specification registers the following comprehension-optional | This specification registers the following comprehension-optional | |||
parameters (Table 2) in the IANA "DOTS Signal Channel CBOR Key | parameters (Table 2) in the IANA "DOTS Signal Channel CBOR Key | |||
Values" registry [Key-Map]. | Values" registry [Key-Map]. | |||
o Note to the RFC Editor: Please delete TBA1-TBA8 once CBOR keys are | +========================+=======+=======+============+===========+ | |||
assigned from the 32768-49151 range. | | Parameter Name | CBOR | CBOR | Change | Reference | | |||
| | Key | Major | Controller | | | ||||
+--------------------+-------+-------+------------+---------------+ | | | Value | Type | | | | |||
| Parameter Name | CBOR | CBOR | Change | Specification | | +========================+=======+=======+============+===========+ | |||
| | Key | Major | Controller | Document(s) | | | ietf-dots-call- | 32768 | 4 | IESG | RFC 9066 | | |||
| | Value | Type | | | | | home:source-prefix | | | | | | |||
+====================+=======+=======+============+===============+ | +------------------------+-------+-------+------------+-----------+ | |||
|ietf-dots-call-home:| | | | | | | ietf-dots-call- | 32769 | 4 | IESG | RFC 9066 | | |||
| source-prefix | TBA1 | 4 | IESG | [RFCXXXX] | | | home:source-port-range | | | | | | |||
+--------------------+-------+-------+------------+---------------+ | +------------------------+-------+-------+------------+-----------+ | |||
|ietf-dots-call-home:| | | | | | | ietf-dots-call- | 32770 | 4 | IESG | RFC 9066 | | |||
| source-port-range | TBA2 | 4 | IESG | [RFCXXXX] | | | home:source-icmp-type- | | | | | | |||
+--------------------+-------+-------+------------+---------------+ | | range | | | | | | |||
|ietf-dots-call-home:| | | | | | +------------------------+-------+-------+------------+-----------+ | |||
| source-icmp-type- | TBA3 | 4 | IESG | [RFCXXXX] | | | lower-type | 32771 | 0 | IESG | RFC 9066 | | |||
| range | | | | | | +------------------------+-------+-------+------------+-----------+ | |||
+--------------------+-------+-------+------------+---------------+ | | upper-type | 32772 | 0 | IESG | RFC 9066 | | |||
| lower-type | TBA4 | 0 | IESG | [RFCXXXX] | | +------------------------+-------+-------+------------+-----------+ | |||
+--------------------+-------+-------+------------+---------------+ | | ietf-dots-call- | 32773 | 3 | IESG | RFC 9066 | | |||
| upper-type | TBA5 | 0 | IESG | [RFCXXXX] | | | home:alt-ch-client | | | | | | |||
+--------------------+-------+-------+------------+---------------+ | +------------------------+-------+-------+------------+-----------+ | |||
|ietf-dots-call-home:| | | | | | | ietf-dots-call- | 32774 | 4 | IESG | RFC 9066 | | |||
| alt-ch-client | TBA6 | 3 | IESG | [RFCXXXX] | | | home:alt-ch-client- | | | | | | |||
+--------------------+-------+-------+------------+---------------+ | | record | | | | | | |||
|ietf-dots-call-home:| | | | | | +------------------------+-------+-------+------------+-----------+ | |||
|alt-ch-client-record| TBA7 | 4 | IESG | [RFCXXXX] | | | ietf-dots-call-home: | 32775 | 0 | IESG | RFC 9066 | | |||
+--------------------+-------+-------+------------+---------------+ | | ttl | | | | | | |||
|ietf-dots-call-home:| | | | | | +------------------------+-------+-------+------------+-----------+ | |||
| ttl | TBA8 | 0 | IESG | [RFCXXXX] | | ||||
+--------------------+-------+-------+------------+---------------+ | ||||
Table 2: Assigned DOTS Signal Channel CBOR Key Values | Table 2: Assigned DOTS Signal Channel CBOR Key Values | |||
7.2. New DOTS Conflict Cause | 7.2. New DOTS Conflict Cause | |||
This document requests IANA to assign a new code from the "DOTS | Per this document, IANA has assigned a new code from the "DOTS Signal | |||
Signal Channel Conflict Cause Codes" registry [Cause]. | Channel Conflict Cause Codes" registry [Cause]. | |||
+-------+----------------------------------+------------+-----------+ | +====+=====================================+=============+==========+ | |||
| Code | Label | Descriptio | Reference | | |Code| Label |Description |Reference | | |||
| | | n | | | +====+=====================================+=============+==========+ | |||
+-------+----------------------------------+------------+-----------+ | |4 | request-rejected-legitimate-traffic |Mitigation |RFC 9066 | | |||
| 4 (TB | request-rejected-legitimate- | Mitigation | [RFCXXXX] | | | | |request | | | |||
| A9) | traffic | request | | | | | |rejected. | | | |||
| | | rejected. | | | | | |This code is | | | |||
| | | This code | | | | | |returned by | | | |||
| | | is | | | | | |the DOTS | | | |||
| | | returned | | | | | |server to | | | |||
| | | by the | | | | | |indicate the | | | |||
| | | DOTS | | | | | |attack | | | |||
| | | server to | | | | | |traffic has | | | |||
| | | indicate | | | | | |been | | | |||
| | | the attack | | | | | |classified as| | | |||
| | | traffic | | | | | |legitimate | | | |||
| | | has been | | | | | |traffic. | | | |||
| | | classified | | | +----+-------------------------------------+-------------+----------+ | |||
| | | as | | | ||||
| | | legitimate | | | Table 3: Assigned DOTS Signal Channel Conflict Cause Code | |||
| | | traffic. | | | ||||
+-------+----------------------------------+------------+-----------+ | ||||
7.3. DOTS Signal Call Home YANG Module | 7.3. DOTS Signal Call Home YANG Module | |||
This document requests IANA to register the following URI in the "ns" | Per this document, IANA has registered the following URI in the "ns" | |||
subregistry within the "IETF XML Registry" [RFC3688]: | subregistry within the "IETF XML Registry" [RFC3688]: | |||
URI: urn:ietf:params:xml:ns:yang:ietf-dots-call-home | URI: urn:ietf:params:xml:ns:yang:ietf-dots-call-home | |||
Registrant Contact: The IETF. | Registrant Contact: The IETF. | |||
XML: N/A; the requested URI is an XML namespace. | XML: N/A; the requested URI is an XML namespace. | |||
This document requests IANA to register the following YANG module in | Per this document, IANA has registered the following YANG module in | |||
the "YANG Module Names" subregistry [RFC6020] within the "YANG | the "YANG Module Names" subregistry [RFC6020] within the "YANG | |||
Parameters" registry: | Parameters" registry: | |||
name: ietf-dots-call-home | name: ietf-dots-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: dots-call-home | prefix: dots-call-home | |||
reference: RFC XXXX | reference: RFC 9066 | |||
8. Security Considerations | 8. 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 (D)TLS connection. DOTS signal | having the DOTS server initiate the (D)TLS connection. Security | |||
channel related security considerations discussed in Section 11 of | considerations related to the DOTS signal channel discussed in | |||
[I-D.ietf-dots-rfc8782-bis] MUST be considered. DOTS agents MUST | Section 11 of [RFC9132] and (D)TLS early data discussed in Section 7 | |||
authenticate each other using (D)TLS before a DOTS signal channel | of [RFC9132] MUST be considered. DOTS agents MUST authenticate each | |||
session is considered valid. | other using (D)TLS before a DOTS signal channel session is considered | |||
valid. | ||||
The Call Home function enables a Call Home DOTS server to be | The Call Home function enables a Call Home DOTS server to be | |||
reachable by only the intended Call Home DOTS client. Appropriate | reachable by only the intended Call Home DOTS client. Appropriate | |||
filters (e.g., access control lists) can be installed on the Call | filters (e.g., access control lists) can be installed on the Call | |||
Home DOTS server and network between the Call Home DOTS agents so | Home DOTS server and network between the Call Home DOTS agents so | |||
that only communications from a trusted Call Home DOTS client to the | that only communications from a trusted Call Home DOTS client to the | |||
Call Home DOTS server are allowed. These filters can be | Call Home DOTS server are allowed. These filters can be | |||
automatically installed by a Call Home DOTS server based on the | automatically installed by a Call Home DOTS server based on the | |||
configured or discovered peer Call Home DOTS client(s). | configured or discovered peer Call Home DOTS client(s). | |||
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 | |||
the attacker doesn't possess a valid key. For instance, in TLS 1.3 | 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 adding to a drop-list the source address after a set | temporarily adding the source address to a drop-list after a set | |||
number of unsuccessful authentication attempts. | number of unsuccessful authentication attempts. | |||
The DOTS Call Home signal channel can be misused by a misbehaving | The DOTS signal Call Home channel can be misused by a misbehaving | |||
Call Home DOTS client by arbitrarily signalling legitimate traffic as | Call Home DOTS client by arbitrarily signaling legitimate traffic as | |||
being attack traffic or falsifying mitigation signals so that some | being attack traffic or falsifying mitigation signals so that some | |||
sources are disconnected or some traffic is rate-limited. Such | sources are disconnected or some traffic is rate-limited. Such | |||
misbehaving Call Home DOTS clients may include sources identified by | misbehaving Call Home DOTS clients may include sources identified by | |||
IP addresses that are used for internal use only (that is, these | IP addresses that are used for internal use only (that is, these | |||
addresses are not visible outside a Call Home DOTS server domain). | addresses are not visible outside a Call Home DOTS server domain). | |||
Absent explicit policy (e.g., the Call Home DOTS client and server | Absent explicit policy (e.g., the Call Home DOTS client and server | |||
are managed by the same administrative entity), such requests should | are managed by the same administrative entity), such requests should | |||
be discarded by the Call Home DOTS server. More generally, Call Home | be discarded by the Call Home DOTS server. More generally, Call Home | |||
DOTS servers should not blindly trust mitigation requests from Call | DOTS servers should not blindly trust mitigation requests from Call | |||
Home DOTS clients. For example, Call Home DOTS servers could use the | Home DOTS clients. For example, Call Home DOTS servers could use the | |||
attack flow information contained in a mitigation request to enable a | attack flow information contained in a mitigation request to enable a | |||
full-fledged packet inspection function to inspect all the traffic | full-fledged packet inspection function to inspect all the traffic | |||
from the compromised device to the target, or could re-direct the | from the compromised device to the target. They could also redirect | |||
traffic from the potentially compromised device to the target towards | the traffic from the potentially compromised device to the target | |||
a DDoS mitigation system that can scrub the suspicious traffic, | towards a DDoS mitigation system that can scrub the suspicious | |||
without blindly blocking all traffic from the indicated attack source | traffic without blindly blocking all traffic from the indicated | |||
to the target. Call Home DOTS servers can also seek the consent of | attack source to the target. Call Home DOTS servers can also seek | |||
DOTS server domain administrator to block the traffic from the | the consent of the DOTS server domain administrator to block the | |||
potentially compromised device to the target (see Section 5.3.1). | traffic from the potentially compromised device to the target (see | |||
Means to seek the consent are implementation-specific. | Section 5.3.1). The means to seek consent are implementation | |||
specific. | ||||
Call Home DOTS agents may interact with on-path address sharing | Call Home DOTS agents may interact with on-path address sharing | |||
functions to retrieve an internal IP addresss/external IP address | functions to retrieve an internal IP address / external IP address | |||
mapping (Section 5.3.2) identifying an attack source. Blocking | mapping (Section 5.3.2) identifying an attack source. Blocking | |||
access or manipulating the mapping information will complicate DDoS | access or manipulating the mapping information will complicate DDoS | |||
attack mitigation close to an attack source. Additional security | attack mitigation close to an attack source. Additional security | |||
considerations are specific to the actual mechanism used to access | considerations are specific to the actual mechanism used to access | |||
that mapping (refer, e.g., to Section 4 of [RFC8512] or Section 4 of | that mapping (refer, e.g., to Section 4 of [RFC8512] or Section 4 of | |||
[RFC8513]). | [RFC8513]). | |||
This document augments YANG data structures that are meant to be used | ||||
as an abstract representation of DOTS signal channel Call Home | ||||
messages. As such, the "ietf-dots-call-home" module does not | ||||
introduce any new vulnerabilities beyond those specified above and in | ||||
[RFC9132]. | ||||
9. Privacy Considerations | 9. 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 introduces privacy threats. | assess whether the DOTS Call Home introduces privacy 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 Call Home DOTS | be used to ease surveillance. In particular, the Call Home DOTS | |||
server is not required to share information that is local to its | server is not required to share information that is local to its | |||
network (e.g., internal identifiers of an attack source) with the | network (e.g., internal identifiers of an attack source) with the | |||
Call Home DOTS client. Also, the recommended data to be included in | Call Home DOTS client. Also, the recommended data to be included in | |||
Call Home DOTS messages is a subset of the Layer 3/Layer 4 | Call Home DOTS messages is a subset of the Layer 3 / Layer 4 | |||
information that can be learnt from the overall traffic flows that | information that can be learned from the overall traffic flows that | |||
exit the Call Home DOTS server domain. Furthermore, Call Home DOTS | exit the Call Home DOTS server domain. Furthermore, Call Home DOTS | |||
clients do not publicly reveal attack identification information; | clients do not publicly reveal attack identification information; | |||
that information is encrypted and only shared with an authorized | that information is encrypted and only shared with an authorized | |||
entity in the domain to which the IP address/prefix is assigned, from | entity in the domain to which the IP address/prefix is assigned, from | |||
which an attack was issued. | which an attack was issued. | |||
The DOTS Call Home does not preclude the validation of mitigation | The DOTS Call Home does not preclude the validation of mitigation | |||
requests received from a Call Home DOTS client. For example, a | requests received from a Call Home DOTS client. For example, a | |||
security service running on the CPE may require an administrator's | security service running on the CPE may require an administrator's | |||
consent before the CPE acts upon the mitigation request indicated by | consent before the CPE acts upon the mitigation request indicated by | |||
skipping to change at page 33, line 45 ¶ | skipping to change at line 1396 ¶ | |||
consent, validate the request by inspecting the relevant traffic for | consent, validate the request by inspecting the relevant traffic for | |||
attack signatures, or proceed with both courses of action. | attack signatures, or proceed with both courses of action. | |||
The DOTS Call Home is only advisory in nature. Concretely, the DOTS | The DOTS Call Home is only advisory in nature. Concretely, the DOTS | |||
Call Home does not impose any action to be enforced within the | Call Home does not impose any action to be enforced within the | |||
network hosting an attack source; it is up to the Call Home DOTS | network hosting an attack source; it is up to the Call Home DOTS | |||
server (and/or network administrator) to decide whether and which | server (and/or network administrator) to decide whether and which | |||
actions are required. | actions are required. | |||
Moreover, the DOTS Call Home avoids misattribution by appropriately | Moreover, the DOTS Call Home avoids misattribution by appropriately | |||
identifying the network to which a suspect attack source belongs to | identifying the network to which a suspect attack source belongs | |||
(e.g., address sharing issues discussed in Section 5.3.1). | (e.g., address sharing issues discussed in Section 5.3.1). | |||
Triggers to send a DOTS mitigation request to a Call Home DOTS server | Triggers to send a DOTS mitigation request to a Call Home DOTS server | |||
are deployment-specific. For example, a Call Home DOTS client may | are deployment specific. For example, a Call Home DOTS client may | |||
rely on the output of some DDoS detection systems (flow exports or | rely on the output of some DDoS detection systems (flow exports or | |||
similar functions) deployed within the DOTS client domain to detect | similar functions) deployed within the DOTS client domain to detect | |||
potential outbound DDoS attacks or on abuse claims received from | potential outbound DDoS attacks or may rely on abuse claims received | |||
remote victim networks. These systems may be misused to track users | from remote victim networks. These systems may be misused to track | |||
and infer their activities. Such misuses are not required to achieve | users and infer their activities. Such misuses are not required to | |||
the functionality defined in this document (that is, protect the | achieve the functionality defined in this document (that is, protect | |||
Internet and avoid altering the IP reputation of source networks). | the Internet and avoid altering the IP reputation of source | |||
It is out of the scope to identify privacy threats specific to a | networks). It is out of the scope to identify privacy threats | |||
given attack detection technology. The reader may refer, for | specific to given attack detection technology. The reader may refer, | |||
example, to Section 11.8 of [RFC7011]. | for example, to Section 11.8 of [RFC7011]. | |||
10. Contributors | ||||
The following individuals have contributed to this document: | ||||
Joshi Harsha | ||||
McAfee, Inc. | ||||
Embassy Golf Link Business Park | ||||
Bangalore, Karnataka 560071 | ||||
India | ||||
Email: harsha_joshi@mcafee.com | ||||
Wei Pan | ||||
Huawei Technologies | ||||
China | ||||
Email: william.panwei@huawei.com | ||||
11. Acknowledgements | ||||
Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Toema | ||||
Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments. | ||||
Benjamin Kaduk's AD review is valuable. Many thanks to him for the | ||||
detailed review. | ||||
Thanks to Radia Perlman and David Schinazi for the directorate | ||||
reviews. | ||||
Thanks to Ebben Aries for the yangdoctors review. | ||||
Thanks to Eric Vyncke, Roman Danyliw, Barry Leiba, Robert Wilton, and | ||||
Erik Kline for the IESG review. | ||||
12. References | 10. References | |||
12.1. Normative References | ||||
[I-D.ietf-dots-rfc8782-bis] | 10.1. Normative References | |||
Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed | ||||
Denial-of-Service Open Threat Signaling (DOTS) Signal | ||||
Channel Specification", draft-ietf-dots-rfc8782-bis-06 | ||||
(work in progress), March 2021. | ||||
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, | [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, | |||
RFC 792, DOI 10.17487/RFC0792, September 1981, | RFC 792, DOI 10.17487/RFC0792, September 1981, | |||
<https://www.rfc-editor.org/info/rfc792>. | <https://www.rfc-editor.org/info/rfc792>. | |||
[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>. | |||
skipping to change at page 36, line 17 ¶ | skipping to change at line 1466 ¶ | |||
<https://www.rfc-editor.org/info/rfc6991>. | <https://www.rfc-editor.org/info/rfc6991>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | |||
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | |||
<https://www.rfc-editor.org/info/rfc8446>. | <https://www.rfc-editor.org/info/rfc8446>. | |||
[RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data | [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data | |||
Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, | Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, | |||
June 2020, <https://www.rfc-editor.org/info/rfc8791>. | June 2020, <https://www.rfc-editor.org/info/rfc8791>. | |||
12.2. Informative References | [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, | |||
"Distributed Denial-of-Service Open Threat Signaling | ||||
(DOTS) Signal Channel Specification", RFC 9132, | ||||
DOI 10.17487/RFC9132, September 2021, | ||||
<https://www.rfc-editor.org/info/rfc9132>. | ||||
10.2. Informative References | ||||
[Cause] IANA, "DOTS Signal Channel Conflict Cause Codes", | [Cause] IANA, "DOTS Signal Channel Conflict Cause Codes", | |||
<https://www.iana.org/assignments/dots/dots.xhtml#dots- | <https://www.iana.org/assignments/dots/>. | |||
signal-channel-conflict-cause-codes>. | ||||
[I-D.ietf-dots-multihoming] | [DOTS-MULTIHOMING] | |||
Boucadair, M., Reddy, T., and W. Pan, "Multi-homing | Boucadair, M., Reddy, T., and W. Pan, "Multi-homing | |||
Deployment Considerations for Distributed-Denial-of- | Deployment Considerations for Distributed-Denial-of- | |||
Service Open Threat Signaling (DOTS)", draft-ietf-dots- | Service Open Threat Signaling (DOTS)", Work in Progress, | |||
multihoming-05 (work in progress), November 2020. | Internet-Draft, draft-ietf-dots-multihoming-09, 2 December | |||
2021, <https://datatracker.ietf.org/doc/html/draft-ietf- | ||||
dots-multihoming-09>. | ||||
[I-D.ietf-dots-use-cases] | [DTLS13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The | |||
Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, | Datagram Transport Layer Security (DTLS) Protocol Version | |||
L., and K. Nishizuka, "Use cases for DDoS Open Threat | 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- | |||
Signaling", draft-ietf-dots-use-cases-25 (work in | dtls13-43, 30 April 2021, | |||
progress), July 2020. | <https://datatracker.ietf.org/doc/html/draft-ietf-tls- | |||
dtls13-43>. | ||||
[I-D.ietf-i2nsf-terminology] | [I2NSF-TERMS] | |||
Hares, S., Strassner, J., Lopez, D. R., Xia, L., and H. | Hares, S., Strassner, J., Lopez, D. R., 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", Work in Progress, Internet-Draft, draft- | |||
progress), July 2019. | ietf-i2nsf-terminology-08, 5 July 2019, | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf- | ||||
terminology-08>. | ||||
[Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", | [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", | |||
<https://www.iana.org/assignments/dots/dots.xhtml#dots- | <https://www.iana.org/assignments/dots/>. | |||
signal-channel-cbor-key-values>. | ||||
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address | [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address | |||
Translator (NAT) Terminology and Considerations", | Translator (NAT) Terminology and Considerations", | |||
RFC 2663, DOI 10.17487/RFC2663, August 1999, | RFC 2663, DOI 10.17487/RFC2663, August 1999, | |||
<https://www.rfc-editor.org/info/rfc2663>. | <https://www.rfc-editor.org/info/rfc2663>. | |||
[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>. | |||
skipping to change at page 39, line 5 ¶ | skipping to change at line 1602 ¶ | |||
[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open | [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open | |||
Threat Signaling (DOTS) Requirements", RFC 8612, | Threat Signaling (DOTS) Requirements", RFC 8612, | |||
DOI 10.17487/RFC8612, May 2019, | DOI 10.17487/RFC8612, May 2019, | |||
<https://www.rfc-editor.org/info/rfc8612>. | <https://www.rfc-editor.org/info/rfc8612>. | |||
[RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., | [RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., | |||
Teague, N., and R. Compton, "DDoS Open Threat Signaling | Teague, N., and R. Compton, "DDoS Open Threat Signaling | |||
(DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, | (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, | |||
August 2020, <https://www.rfc-editor.org/info/rfc8811>. | August 2020, <https://www.rfc-editor.org/info/rfc8811>. | |||
[RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, | ||||
L., and K. Nishizuka, "Use Cases for DDoS Open Threat | ||||
Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021, | ||||
<https://www.rfc-editor.org/info/rfc8903>. | ||||
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. | [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. | |||
Bacher, "Dissemination of Flow Specification Rules", | Bacher, "Dissemination of Flow Specification Rules", | |||
RFC 8955, DOI 10.17487/RFC8955, December 2020, | RFC 8955, DOI 10.17487/RFC8955, December 2020, | |||
<https://www.rfc-editor.org/info/rfc8955>. | <https://www.rfc-editor.org/info/rfc8955>. | |||
[RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., | [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., | |||
"Dissemination of Flow Specification Rules for IPv6", | "Dissemination of Flow Specification Rules for IPv6", | |||
RFC 8956, DOI 10.17487/RFC8956, December 2020, | RFC 8956, DOI 10.17487/RFC8956, December 2020, | |||
<https://www.rfc-editor.org/info/rfc8956>. | <https://www.rfc-editor.org/info/rfc8956>. | |||
[RFC8973] Boucadair, M. and T. Reddy.K, "DDoS Open Threat Signaling | [RFC8973] Boucadair, M. and T. Reddy.K, "DDoS Open Threat Signaling | |||
(DOTS) Agent Discovery", RFC 8973, DOI 10.17487/RFC8973, | (DOTS) Agent Discovery", RFC 8973, DOI 10.17487/RFC8973, | |||
January 2021, <https://www.rfc-editor.org/info/rfc8973>. | January 2021, <https://www.rfc-editor.org/info/rfc8973>. | |||
[RS] RSnake, "Slowloris HTTP DoS", | [RS] RSnake, "Slowloris HTTP DoS", | |||
<https://web.archive.org/web/20150315054838/ | <https://web.archive.org/web/20150315054838/ | |||
http://ha.ckers.org/slowloris/>. | http://ha.ckers.org/slowloris/>. | |||
[Sec-by-design] | [Sec-by-design] | |||
UK Department for Digital Culture, Media & Sport, "Secure | UK Department for Digital, Culture, Media & Sport, "Secure | |||
by Design: Improving the cyber security of consumer | by Design: Improving the cyber security of consumer | |||
Internet of Things Report", March 2018, | Internet of Things Report", March 2018, | |||
<https://www.gov.uk/government/publications/secure-by- | <https://www.gov.uk/government/publications/secure-by- | |||
design-report>. | design-report>. | |||
Appendix A. Some Home Network Issues | Appendix A. Some Home Network Issues | |||
Internet of Things (IoT) devices are becoming more and more | Internet of Things (IoT) devices are becoming more and more | |||
prevalent, in particular in home networks. With compute and memory | prevalent, in particular in home networks. With compute and memory | |||
becoming cheaper and cheaper, various types of IoT devices become | becoming cheaper and cheaper, various types of IoT devices become | |||
skipping to change at page 40, line 9 ¶ | skipping to change at line 1659 ¶ | |||
launching DDoS attacks (Section 3 of [RFC8576]) on victims while the | launching DDoS attacks (Section 3 of [RFC8576]) on victims while the | |||
owner/administrator of the home network is not aware about such | owner/administrator of the home network is not aware about such | |||
misbehaviors. Similar to other DDoS attacks, the victim in this | misbehaviors. Similar to other DDoS attacks, the victim in this | |||
attack can be an application server, a host, a router, a firewall, or | attack can be an application server, a host, a router, a firewall, or | |||
an entire network. Such misbehaviors can cause collateral damage | an entire network. Such misbehaviors can cause collateral damage | |||
that will affect end users, and can also harm the reputation of an | that will affect end users, and can also harm the reputation of an | |||
Internet Service Provider (ISP) for being a source of attack traffic. | Internet Service Provider (ISP) for being a source of attack traffic. | |||
Nowadays, network devices in a home network can offer network | Nowadays, network devices in a home network can offer network | |||
security functions (e.g., firewall [RFC4949] or Intrusion Protection | security functions (e.g., firewall [RFC4949] or Intrusion Protection | |||
System (IPS) service [I-D.ietf-i2nsf-terminology] on a home router) | System (IPS) service [I2NSF-TERMS] on a home router) to protect the | |||
to protect the devices connected to the home network from both | devices connected to the home network from both external and internal | |||
external and internal attacks. It is natural to seek to provide DDoS | attacks. It is natural to seek to provide DDoS defense in these | |||
defense in these devices as well, and over the years several | devices as well, and over the years several techniques have been | |||
techniques have been identified to detect DDoS attacks; some of these | identified to detect DDoS attacks; some of these techniques can be | |||
techniques can be enabled on home network devices but most of them | enabled on home network devices but most of them are used within the | |||
are used within the ISP's network. | ISP's network. | |||
Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris | Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris | |||
[RS], and Transport Layer Security (TLS) renegotiation are difficult | [RS], and Transport Layer Security (TLS) renegotiation are difficult | |||
to detect on a home network device without adversely affecting its | to detect on a home network device without adversely affecting its | |||
performance. The reason is that typically home devices such as home | performance. The reason is that typically home devices such as home | |||
routers have fast path to boost the throughput. For every new TCP/ | routers have fast path to boost the throughput. For every new TCP/ | |||
UDP flow, only the first few packets are punted through the slow | UDP flow, only the first few packets are punted through the slow | |||
path. Hence, it is not possible to detect various DDoS attacks in | path. Hence, it is not possible to detect various DDoS attacks in | |||
the slow path, since the attack payload is sent to the target server | the slow path, since the attack payload is sent to the target server | |||
after the flow is switched to fast path. The reader may refer to | after the flow is switched to fast path. The reader may refer to | |||
skipping to change at page 41, line 31 ¶ | skipping to change at line 1729 ¶ | |||
the home network can mitigate the DDoS attacks launched by the | the home network can mitigate the DDoS attacks launched by the | |||
compromised device in its domain by receiving the mitigation request | compromised device in its domain by receiving the mitigation request | |||
sent by the Call Home DOTS client in the ISP environment. In | sent by the Call Home DOTS client in the ISP environment. In | |||
addition, the DOTS client in the home network can initiate a | addition, the DOTS client in the home network can initiate a | |||
mitigation request to the DOTS server in the ISP environment to ask | mitigation request to the DOTS server in the ISP environment to ask | |||
for help when the home network is under a DDoS attack. Such Call | for help when the home network is under a DDoS attack. Such Call | |||
Home DOTS server and DOTS client in the home network can co-locate in | Home DOTS server and DOTS client in the home network can co-locate in | |||
the same home network element (e.g., the Customer Premises | the same home network element (e.g., the Customer Premises | |||
Equipment). In this case, with the same peer at the same time the | Equipment). In this case, with the same peer at the same time the | |||
home network element will have the base DOTS signal channel defined | home network element will have the base DOTS signal channel defined | |||
in [I-D.ietf-dots-rfc8782-bis] and the DOTS signal channel Call Home | in [RFC9132] and the DOTS signal channel Call Home defined in this | |||
defined in this specification. Thus, these two signal channels need | specification. Thus, these two signal channels need to be | |||
to be distinguished when they are both supported. Two approaches | distinguished when they are both supported. Two approaches have been | |||
have been considered for distinguishing the two DOTS signal channels, | considered for distinguishing the two DOTS signal channels, but only | |||
but only the one that using the dedicated port number has been chosen | the one that using the dedicated port number has been chosen as the | |||
as the best choice. | best choice. | |||
By using a dedicated port number for each, these two signal channels | By using a dedicated port number for each, these two signal channels | |||
can be separated unambiguously and easily. For example, the CPE uses | can be separated unambiguously and easily. For example, the CPE uses | |||
the port number 4646 allocated in [I-D.ietf-dots-rfc8782-bis] to | the port number 4646 allocated in [RFC9132] to initiate the basic | |||
initiate the basic signal channel to the ISP when it acts as the DOTS | signal channel to the ISP when it acts as the DOTS client, and uses | |||
client, and uses another port number to initiate the signal channel | another port number to initiate the signal channel Call Home. Based | |||
Call Home. Based on the different port numbers, the ISP can directly | on the different port numbers, the ISP can directly decide which kind | |||
decide which kind of procedures should follow immediately after it | of procedures should follow immediately after it receives the DOTS | |||
receives the DOTS messages. This approach just requires two (D)TLS | messages. This approach just requires two (D)TLS sessions to be | |||
sessions to be established respectively for the basic signal channel | established respectively for the basic signal channel and signal | |||
and signal channel Call Home. | channel Call Home. | |||
The other approach is signaling the role of each DOTS agent (e.g., by | The other approach is signaling the role of each DOTS agent (e.g., by | |||
using the DOTS data channel as depicted in Figure 14). For example, | using the DOTS data channel as depicted in Figure 14). For example, | |||
the DOTS agent in the home network first initiates a DOTS data | the DOTS agent in the home network first initiates a DOTS data | |||
channel to the peer DOTS agent in the ISP environment, at this time | channel to the peer DOTS agent in the ISP environment, at this time | |||
the DOTS agent in the home network is the DOTS client and the peer | the DOTS agent in the home network is the DOTS client and the peer | |||
DOTS agent in the ISP environment is the DOTS server. After that, | DOTS agent in the ISP environment is the DOTS server. After that, | |||
the DOTS agent in the home network retrieves the DOTS Call Home | the DOTS agent in the home network retrieves the DOTS Call Home | |||
capability of the peer DOTS agent. If the peer supports the DOTS | capability of the peer DOTS agent. If the peer supports the DOTS | |||
Call Home, the DOTS agent needs to subscribe to the peer to use this | Call Home, the DOTS agent needs to subscribe to the peer to use this | |||
extension. Then, the reversal of DOTS role can be recognized as done | extension. Then, the reversal of DOTS role can be recognized as done | |||
by both DOTS agents. When the DOTS agent in the ISP environment, | by both DOTS agents. When the DOTS agent in the ISP environment, | |||
which now is the DOTS client, wants to filter the attackers' traffic, | which now is the DOTS client, wants to filter the attackers' traffic, | |||
it requests the DOTS agent in the home network, which now is the DOTS | it requests the DOTS agent in the home network, which now is the DOTS | |||
server, for help. | server, for help. | |||
augment /ietf-data:dots-data/ietf-data:capabilities: | augment /ietf-data:dots-data/ietf-data:capabilities: | |||
+--ro call-home-support? boolean | +--ro call-home-support? boolean | |||
augment /ietf-data:dots-data/ietf-data:dots-client: | augment /ietf-data:dots-data/ietf-data:dots-client: | |||
+--rw call-home-enable? boolean | +--rw call-home-enable? boolean | |||
Figure 14: Example of DOTS Data Channel Augmentation | Figure 14: Example of DOTS Data Channel Augmentation | |||
Signaling the role will complicate the DOTS protocols, and this | Signaling the role will complicate the DOTS protocols, and this | |||
complexity is not required in context where the DOTS Call Home is not | complexity is not required in context where the DOTS Call Home is not | |||
required or only when the DOTS Call Home is needed. Besides, the | required or only when the DOTS Call Home is needed. Besides, the | |||
DOTS data channel may not work during attack time. Even if changing | DOTS data channel may not work during attack time. Even if changing | |||
the above example from using the DOTS data channel to the DOTS signal | the above example from using the DOTS data channel to the DOTS signal | |||
channel, the more procedures will still reduce the efficiency. Using | channel, the more procedures will still reduce the efficiency. Using | |||
the dedicated port number is much easier and more concise compared to | the dedicated port number is much easier and more concise compared to | |||
the second approach, and its cost that establishing two (D)TLS | the second approach, and its cost that establishing two (D)TLS | |||
sessions is much less. So, using a dedicated port number for the | sessions is much less. So, using a dedicated port number for the | |||
DOTS Call Home is recommended in this specification. The dedicated | DOTS Call Home is recommended in this specification. The dedicated | |||
port number can be configured locally or discovered using means such | port number can be configured locally or discovered using means such | |||
as [RFC8973]. | as [RFC8973]. | |||
Authors' Addresses | Acknowledgements | |||
Tirumaleswar Reddy | Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Toema | |||
Gavrichenkov, Daniel Migault, Sean Turner, and Valery Smyslov for the | ||||
comments. | ||||
Benjamin Kaduk's AD review is valuable. Many thanks to him for the | ||||
detailed review. | ||||
Thanks to Radia Perlman and David Schinazi for the directorate | ||||
reviews. | ||||
Thanks to Ebben Aries for the YANG Doctors review. | ||||
Thanks to Éric Vyncke, Roman Danyliw, Barry Leiba, Robert Wilton, and | ||||
Erik Kline for the IESG review. | ||||
Contributors | ||||
The following individuals have contributed to this document: | ||||
Joshi Harsha | ||||
McAfee, Inc. | McAfee, Inc. | |||
Embassy Golf Link Business Park | Embassy Golf Link Business Park | |||
Bangalore, Karnataka 560071 | Bangalore 560071 | |||
Karnataka | ||||
India | ||||
Email: harsha_joshi@mcafee.com | ||||
Wei Pan | ||||
Huawei Technologies | ||||
China | ||||
Email: william.panwei@huawei.com | ||||
Authors' Addresses | ||||
Tirumaleswar Reddy.K | ||||
Akamai | ||||
Embassy Golf Link Business Park | ||||
Bangalore 560071 | ||||
Karnataka | ||||
India | India | |||
Email: kondtir@gmail.com | Email: kondtir@gmail.com | |||
Mohamed Boucadair (editor) | Mohamed Boucadair (editor) | |||
Orange | Orange | |||
Rennes 35000 | 35000 Rennes | |||
France | France | |||
Email: mohamed.boucadair@orange.com | Email: mohamed.boucadair@orange.com | |||
Jon Shallow | Jon Shallow | |||
UK | United Kingdom | |||
Email: supjps-ietf@jpshallow.com | Email: supjps-ietf@jpshallow.com | |||
End of changes. 157 change blocks. | ||||
530 lines changed or deleted | 512 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/ |