--- 1/draft-ietf-dots-signal-call-home-08.txt 2020-09-14 23:13:04.955354622 -0700 +++ 2/draft-ietf-dots-signal-call-home-09.txt 2020-09-14 23:13:05.031356711 -0700 @@ -1,21 +1,21 @@ DOTS T. Reddy Internet-Draft McAfee Intended status: Standards Track M. Boucadair -Expires: September 3, 2020 Orange +Expires: March 18, 2021 Orange J. Shallow - March 2, 2020 + September 14, 2020 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home - draft-ietf-dots-signal-call-home-08 + draft-ietf-dots-signal-call-home-09 Abstract This document specifies the DOTS signal channel Call Home, which enables a DOTS server to initiate a secure connection to a DOTS client, and to receive the attack traffic information from the DOTS client. The DOTS server in turn uses the attack traffic information to identify the compromised devices launching the outgoing DDoS attack and takes appropriate mitigation action(s). @@ -34,22 +34,22 @@ (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- - signal-channel) + (DOTS) Signal Channel Specification" (used to be I-D.ietf-dots- + rfc8782-bis) Please update TBD statements with the assignment made by IANA to DOTS Signal Channel Call Home. Also, please update the "revision" date of the YANG module. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -57,42 +57,42 @@ 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 3, 2020. + This Internet-Draft will expire on March 18, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 5 + 1.2. The Call Home Solution . . . . . . . . . . . . . . . . . 5 1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 6 1.4. Co-existence of Base DOTS Signal Channel & DOTS Call Home 8 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 12 3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. DOTS Signal Channel Variations . . . . . . . . . . . . . 13 3.2.1. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 13 3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 14 3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 15 3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 15 @@ -104,31 +104,31 @@ 4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 28 4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 29 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.1. Normative References . . . . . . . . . . . . . . . . . . 31 9.2. Informative References . . . . . . . . . . . . . . . . . 32 Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home . . 35 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction 1.1. The Problem - The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is - used to carry information about a network resource or a network (or a - part thereof) that is under a Distributed Denial of Service (DDoS) - attack [RFC4732]. Such information is sent by a DOTS client to one - or multiple DOTS servers so that appropriate mitigation actions are + The DOTS signal channel protocol [I-D.ietf-dots-rfc8782-bis] is used + to carry information about a network resource or a network (or a part + thereof) that is under a Distributed Denial of Service (DDoS) attack + [RFC4732]. Such information is sent by a DOTS client to one or + multiple DOTS servers so that appropriate mitigation actions are undertaken on traffic deemed suspicious. Various use cases are discussed in [I-D.ietf-dots-use-cases]. Internet of Things (IoT) devices are becoming more and more prevalent in home networks, in particular. With compute and memory becoming cheaper and cheaper, various types of IoT devices become available in the consumer market at affordable prices. But on the downside, the main threat being most of these IoT devices are bought off-the-shelf and most manufacturers haven't considered security in the product design (e.g., [Sec]). IoT devices deployed in home networks can be @@ -193,21 +193,21 @@ infected device can easily change its IPv6 address to evade remediation. Existing approaches are still suffering from misused access network resources by abusing devices; the support of means for blocking such attacks close to the sources are missing. In particular, the DOTS signal protocol does not discuss cooperative DDoS mitigation between the network hosting an attack source and the ISP to the suppress the outbound DDoS attack traffic originating from that network. -1.2. The Solution +1.2. The Call Home Solution This specification addresses the problems discussed in Section 1.1 and presents an extension to the DOTS signal channel: DOTS signal channel Call Home. 'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers to a DOTS signal channel established at the initiative of a DOTS server. That is, the DOTS server initiates a secure connection to a DOTS client, and uses that connection to receive the attack traffic information (e.g., attack sources) from the DOTS client. More @@ -325,21 +325,21 @@ Figure 2: DOTS Signal Channel Call Home Reference Architecture It is out of the scope of this document to identify an exhaustive list of such deployments. 1.4. Co-existence of Base DOTS Signal Channel & DOTS Call Home The DOTS signal channel Call Home does not require nor preclude the activation of the base DOTS signal channel - [I-D.ietf-dots-signal-channel]. Some sample deployment schemes are + [I-D.ietf-dots-rfc8782-bis]. Some sample deployment schemes are discussed in this section for illustration purposes. The network that hosts an attack source may also be subject to inbound DDoS attacks. In that case, both the base DOTS signal channel and DOTS signal channel Call Home may be enabled as shown in Figure 3 (Same DMS provider) or Figure 4 (Distinct DMS providers). DOTS Signal Channel Base DOTS Call Home Signal Channel +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ @@ -465,44 +465,44 @@ 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. The reader should be familiar with the terms defined in [RFC8612]. - 'Base DOTS signal channel' refers to [I-D.ietf-dots-signal-channel]. + 'Base DOTS signal channel' refers to [I-D.ietf-dots-rfc8782-bis]. - The meaning of the symbols in YANG tree diagrams is defined in - [RFC8340]. + The meaning of the symbols in YANG tree diagrams are defined in + [RFC8340] and [RFC8791]. (D)TLS is used for statements that apply to both Transport Layer Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS) [RFC6347]. Specific terms are used for any statement that applies to either protocol alone. 3. DOTS Signal Channel Call Home 3.1. Procedure 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-initiated DOTS signal channel protocol - [I-D.ietf-dots-signal-channel]. The role reversal that occurs is at - the (D)TLS layer; that is, (1) the Call Home DOTS server acts as a - DTLS client and the Call Home DOTS client acts as a DTLS server or - (2) the Call Home DOTS server acts as a TLS client initiating the - underlying TCP connection and the Call Home DOTS client acts as a TLS - server. The Call Home DOTS server initiates (D)TLS handshake to the - Call Home DOTS client. + [I-D.ietf-dots-rfc8782-bis]. The role reversal that occurs is at the + (D)TLS layer; that is, (1) the Call Home DOTS server acts as a DTLS + client and the Call Home DOTS client acts as a DTLS server or (2) the + Call Home DOTS server acts as a TLS client initiating the underlying + TCP connection and the Call Home DOTS client acts as a TLS server. + The Call Home DOTS server initiates (D)TLS handshake to the Call Home + DOTS client. For example, a home network element (e.g., home router) co-located with a Call Home DOTS server is the (D)TLS server. However, when calling home, the DOTS server initially assumes the role of the (D)TLS client, but the network element's role as a DOTS server remains the same. Furthermore, existing certificate chains and mutual authentication mechanisms between the DOTS agents are unaffected by the Call Home function. This Call Home function enables the DOTS server co-located with a network element (possibly behind NATs and firewalls) reachable by only the intended Call Home @@ -540,45 +540,45 @@ a specific port number, such as by explicit configuration or dynamic discovery [I-D.ietf-dots-server-discovery]. Absent such mutual agreement, the DOTS signal channel Call Home MUST run over port number TBD (that is, Call Home DOTS clients must support accepting DTLS (or TCP) connections on TBD) as defined in Section 4.1, for both UDP and TCP. The interaction between the base DOTS signal channel and the Call Home is discussed in Appendix A. The Happy Eyeballs mechanism explained in Section 4.3 of - [I-D.ietf-dots-signal-channel] is used for initiating (D)TLS + [I-D.ietf-dots-rfc8782-bis] is used for initiating (D)TLS connections. 2. Using this (D)TLS connection, the Call Home DOTS client may request, withdraw, or retrieve the status of mitigation requests. The Call Home DOTS client supplies the source information by means of new attributes defined in Section 3.3.1. The Heartbeat mechanism used for the DOTS Call Home deviates from - the one defined in Section 4.7 of [I-D.ietf-dots-signal-channel]. + the one defined in Section 4.7 of [I-D.ietf-dots-rfc8782-bis]. Section 3.2.1 specifies the behavior to be followed by Call Home DOTS agents. 3.2. DOTS Signal Channel Variations 3.2.1. Heartbeat Mechanism Once the (D)TLS section is established between the DOTS agents, the Call Home DOTS client contacts the Call Home DOTS server to retrieve the session configuration parameters (Section 4.5 of - [I-D.ietf-dots-signal-channel]). The Call Home DOTS server adjusts - the 'heartbeat-interval' to accommodate binding timers used by on- - path NATs and firewalls. Heartbeats will be then exchanged by the - DOTS agents following the instructions retrieved using the signal - channel session configuration exchange. + [I-D.ietf-dots-rfc8782-bis]). The Call Home DOTS server adjusts the + 'heartbeat-interval' to accommodate binding timers used by on-path + NATs and firewalls. Heartbeats will be then exchanged by the DOTS + agents following the instructions retrieved using the signal channel + session configuration exchange. It is the responsibility of Call Home DOTS servers to ensure that on- path translators/firewalls are maintaining a binding so that the same external IP address and/or port number is retained for the DOTS signal channel session. A Call Home DOTS client MAY trigger their heartbeat requests immediately after receiving heartbeat probes from its peer Call Home DOTS server. When an outgoing attack that saturates the outgoing link from the Call Home DOTS server is detected and reported by a Call Home DOTS @@ -592,42 +592,41 @@ 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 the maximum 'missing-hb-allowed' threshold, the Call Home DOTS server concludes the session is disconnected. Then, the Call Home DOTS server MUST try to resume the (D)TLS session. 3.2.2. Redirected Signaling A Call Home DOTS server MUST NOT support the Redirected Signaling - mechanism as specified in Section 4.6 of - [I-D.ietf-dots-signal-channel] (i.e., a 5.03 response that conveys an - alternate DOTS server's FQDN or alternate DOTS server's IP - address(es)). A Call Home DOTS client MUST silently discard such - message as only a Call Home DOTS server can initiate a new (D)TLS - connection. + mechanism as specified in Section 4.6 of [I-D.ietf-dots-rfc8782-bis] + (i.e., a 5.03 response that conveys an alternate DOTS server's FQDN + or alternate DOTS server's IP address(es)). A Call Home DOTS client + MUST silently discard such message as only a Call Home DOTS server + can initiate a new (D)TLS connection. If a Call Home DOTS client wants to redirect a Call Home DOTS server to another Call Home DOTS client, it MUST send a Non-confirmable PUT request to the predefined resource ".well-known/dots/redirect" with the new Call Home DOTS client FQDN or IP address in the body of the PUT similar to what is described in Section 4.6 of - [I-D.ietf-dots-signal-channel]. Furthermore, a new clause called - 'ttl" is defined to return the Time to live (TTL) of the alternate - Call Home DOTS client. + [I-D.ietf-dots-rfc8782-bis]. Furthermore, a new clause called 'ttl" + is defined to return the Time to live (TTL) of the alternate Call + Home DOTS client. On receipt of this PUT request, the Call Home DOTS server responds with a 2.01 (Created), closes this connection and establishes a connection with the new Call Home DOTS client. The processing of the - TTL is defined in Section 4.6 of [I-D.ietf-dots-signal-channel]. If - the Call Home DOTS server cannot service the PUT request, the - response is rejected with a 4.00 (bad Request). + TTL is defined in Section 4.6 of [I-D.ietf-dots-rfc8782-bis]. If the + Call Home DOTS server cannot service the PUT request, the response is + rejected with a 4.00 (bad Request). Figure 8 shows a PUT request example to convey the alternate Call Home DOTS client 'alt-call-home-client.example' together with its IP addresses 2001:db8:6401::1 and 2001:db8:6401::2. The validity of this alternate Call Home DOTS client is 10 minutes. Header: PUT (Code=0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "redirect" @@ -646,21 +645,21 @@ "ietf-dots-call-home:ttl": 600 } Figure 8: Example of a PUT Request for Redirected Signaling 3.3. DOTS Signal Channel Extension 3.3.1. Mitigation Request This specification extends the mitigation request defined in - Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the attack + Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis] to convey the attack source information (e.g., source prefixes, source port numbers). The DOTS client conveys the following new parameters in the CBOR body of the mitigation request: source-prefix: A list of attacker prefixes used to attack the target. Prefixes are represented using Classless Inter-Domain Routing (CIDR) notation [RFC4632]. As a reminder, the prefix length MUST be less than or equal to 32 (or 128) for IPv4 (or IPv6). @@ -751,60 +750,60 @@ Figure 9: An Example of Mitigation Request Issued by a Call Home DOTS Client 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 DOTS Call Home scenario, the Call Home DOTS server considers, by default, that any routeable IP prefix enclosed in 'target-prefix' is within the scope of the Call Home DOTS client. Invalid mitigation requests are handled as per Section 4.4.1 of - [I-D.ietf-dots-signal-channel]. + [I-D.ietf-dots-rfc8782-bis]. Note: These validation checks do not apply when the source information is included as a hint in the context of the base DOTS signal channel. The Call Home DOTS server domain administrator consent MAY be required to block the traffic from the compromised device to the attack target. An implementation MAY have a configuration knob to block the traffic from the compromised device to the attack target with or without DOTS server domain administrator consent. If the attack traffic is blocked, the Call Home DOTS server informs the Call Home DOTS client that the attack is being mitigated. If the attack traffic information is identified by the Call Home DOTS server or the Call Home DOTS server domain administrator as legitimate traffic, the mitigation request is rejected, and 4.09 (Conflict) is returned to the Call Home DOTS client. The conflict- - clause (defined in Section 4.4.1 of [I-D.ietf-dots-signal-channel]) + clause (defined in Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis]) indicates the cause of the conflict. The following new value is defined: 4: Mitigation request rejected. This code is returned by the DOTS server to indicate the attack traffic has been classified as legitimate traffic. Once the request is validated by the Call Home DOTS server, appropriate actions are enforced to block the attack traffic within the source network. The Call Home DOTS client is informed about the progress of the attack mitigation following the rules in - [I-D.ietf-dots-signal-channel]. For example, if the Call Home DOTS + [I-D.ietf-dots-rfc8782-bis]. For example, if the Call Home DOTS server is 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 CPE inspects the punted slow path traffic to detect and block the outgoing DDoS attack traffic or quarantine the device (e.g., using MAC level filtering) until it is remediated, and notifies the CPE administrator about the compromised device. The DOTS agents follow the same procedures specified in - [I-D.ietf-dots-signal-channel] for managing a mitigation request. + [I-D.ietf-dots-rfc8782-bis] for managing a mitigation request. 3.3.2. Address Sharing Considerations If a Carrier Grade NAT (CGN, including NAT64) is located between the DOTS client domain and DOTS server domain, communicating an external IP address in a mitigation request is likely to be discarded by the Call Home DOTS server because the external IP address is not visible locally to the Call Home DOTS server (see Figure 10). The Call Home DOTS server is only aware of the internal IP addresses/prefixes bound to its domain. Thus, the Call Home DOTS client MUST NOT include the @@ -919,95 +918,108 @@ +-------------+ Figure 12: Example of a Call Home DOTS Server and a NAT Embedded in a CPE 3.3.3. DOTS Signal Call Home YANG Module 3.3.3.1. Tree Structure This document augments the "ietf-dots-signal-channel" DOTS signal - YANG module defined in [I-D.ietf-dots-signal-channel] for signaling - the attack traffic information. This document defines the YANG - module "ietf-dots-call-home", which has the following tree structure: + YANG module defined in [I-D.ietf-dots-rfc8782-bis] for signaling the + attack traffic information. This document defines the YANG module + "ietf-dots-call-home", which has the following tree structure: module: ietf-dots-call-home - augment /ietf-signal:dots-signal/ietf-signal:message-type - /ietf-signal:mitigation-scope/ietf-signal:scope: - +--rw source-prefix* inet:ip-prefix {source-signaling}? - +--rw source-port-range* [lower-port] {source-signaling}? - | +--rw lower-port inet:port-number - | +--rw upper-port? inet:port-number - +--rw source-icmp-type-range* - | [lower-type] {source-signaling}? - +--rw lower-type uint8 - +--rw upper-type? uint8 - augment /ietf-signal:dots-signal/ietf-signal:message-type - /ietf-signal:redirected-signal: - +--rw alt-ch-client string {call-home}? - +--rw alt-ch-client-record* inet:ip-address {call-home}? - +--rw ttl uint32 {call-home}? + + augment-structure /signal:dots-signal/signal:message-type + /signal:mitigation-scope/signal:scope: + +-- source-prefix* inet:ip-prefix + +-- source-port-range* [lower-port] + | +-- lower-port inet:port-number + | +-- upper-port? inet:port-number + +-- source-icmp-type-range* [lower-type] + +-- lower-type uint8 + +-- upper-type? uint8 + augment-structure /signal:dots-signal/signal:message-type + /signal:redirected-signal: + +-- (type)? + +--:(call-home-only) + +-- alt-ch-client? string + +-- alt-ch-client-record* inet:ip-address + +-- ttl? uint32 3.3.3.2. YANG/JSON Mapping Parameters to CBOR The YANG/JSON mapping parameters to CBOR are listed in Table 1. +--------------------+------------+------+---------------+--------+ | Parameter Name | YANG | CBOR | CBOR Major | JSON | | | Type | Key | Type & | Type | | | | | Information | | - +--------------------+------------+------+---------------+--------+ + +====================+============+======+===============+========+ |ietf-dots-call-home:| leaf-list | | | | | source-prefix | inet: | TBA1 | 4 array | Array | | | ip-prefix | | 3 text string | String | + +--------------------+------------+------+---------------+--------+ |ietf-dots-call-home:| | | | | | source-port-range | list | TBA2 | 4 array | Array | + +--------------------+------------+------+---------------+--------+ |ietf-dots-call-home:| | | | | | source-icmp-type- | list | TBA3 | 4 array | Array | | range | | | | | - |ietf-dots-call-home:| | | | | + +--------------------+------------+------+---------------+--------+ | lower-type | uint8 | TBA4 | 0 unsigned | Number | - |ietf-dots-call-home:| | | | | + +--------------------+------------+------+---------------+--------+ | upper-type | uint8 | TBA5 | 0 unsigned | Number | + +--------------------+------------+------+---------------+--------+ |ietf-dots-call-home:| | | | | | alt-ch-client | string | TBA6 | 3 text string | String | + +--------------------+------------+------+---------------+--------+ |ietf-dots-call-home:| leaf-list | TBA7 | 4 array | Array | | alt-ch-client- | inet: | | | | | record | ip-address| | 3 text string | String | + +--------------------+------------+------+---------------+--------+ |ietf-dots-call-home:| | | | | | ttl | uint32 | TBA8 | 0 unsigned | Number | +--------------------+------------+------+---------------+--------+ Table 1: YANG/JSON Mapping Parameters to CBOR 3.3.3.3. YANG Module - This module uses the common YANG types defined in [RFC6991]. - - file "ietf-dots-call-home@2019-09-06.yang" + This module uses the common YANG types defined in [RFC6991] and the + data structure defined in [RFC8791]. + file "ietf-dots-call-home@2020-07-07.yang" module ietf-dots-call-home { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home"; - prefix call-home; + prefix dots-call-home; import ietf-inet-types { prefix inet; reference "Section 4 of RFC 6991"; + } import ietf-dots-signal-channel { - prefix ietf-signal; + prefix signal; reference "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification"; } + import ietf-yang-structure-ext { + prefix sx; + reference + "RFC 8791: YANG Data Structure Extensions"; + } organization "IETF DDoS Open Threat Signaling (DOTS) Working Group"; contact "WG Web: WG List: Author: Konda, Tirumaleswar Reddy ; @@ -1028,64 +1039,51 @@ Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - revision 2019-09-06 { + revision 2020-07-07 { description "Initial revision."; + reference "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home"; } - - feature source-signaling { - description - "This feature means that source-related information - can be supplied in mitigation requests. This is - typically applicable for DOTS Call Home."; - } - feature call-home { + sx:augment-structure "/signal:dots-signal/signal:message-type/" + + "signal:mitigation-scope/signal:scope" { description - "This feature means that Call Home functionality - is supported."; - } - - augment "/ietf-signal:dots-signal/ietf-signal:message-type/" - + "ietf-signal:mitigation-scope/ietf-signal:scope" { - if-feature source-signaling; - description "Attacker source details."; - + "Attacker source details."; leaf-list source-prefix { type inet:ip-prefix; description "IPv4 or IPv6 prefix identifying the attacker(s)."; } list source-port-range { key "lower-port"; description "Port range. When only lower-port is present, it represents a single port number."; leaf lower-port { type inet:port-number; mandatory true; description "Lower port number of the port range."; } leaf upper-port { type inet:port-number; - must ". >= ../lower-port" { + must '. >= ../lower-port' { error-message "The upper port number must be greater than or equal to lower port number."; } description "Upper port number of the port range."; } } list source-icmp-type-range { key "lower-type"; @@ -1093,124 +1091,129 @@ "ICMP type range. When only lower-type is present, it represents a single ICMP type."; leaf lower-type { type uint8; mandatory true; description "Lower ICMP type of the ICMP type range."; } leaf upper-type { type uint8; - must ". >= ../lower-type" { + must '. >= ../lower-type' { error-message "The upper ICMP type must be greater than or equal to lower ICMP type."; } description "Upper type of the ICMP type range."; } } } - - augment "/ietf-signal:dots-signal/ietf-signal:message-type/" - + "ietf-signal:redirected-signal" { - if-feature call-home; + sx:augment-structure "/signal:dots-signal/signal:message-type/" + + "signal:redirected-signal" { description "The alternate Call Home DOTS client."; - + choice type { + description + "Indicates the type of the DOTS session."; + case call-home-only { + description + "These attributes appear only in a call home signal + channel message from the Call Home DOTS client + to the Call Home DOTS server."; leaf alt-ch-client { type string; description "FQDN of an alternate Call Home DOTS client."; } leaf-list alt-ch-client-record { type inet:ip-address; description "List of records for the alternate Call Home DOTS client."; } leaf ttl { type uint32; units "seconds"; description "The Time to live (TTL) of the alternate Call Home DOTS client."; } } } + } + } 4. IANA Considerations 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number IANA is requested to assign the port number TBD to the DOTS signal channel Call Home protocol for both UDP and TCP from the "Service - Name and Transport Protocol Port Number Registry" available at: - https://www.iana.org/assignments/service-names-port-numbers/service- - names-port-numbers.xhtml. + Name and Transport Protocol Port Number Registry" [ServicePorts]. Service Name: dots-call-home Port Number: TBD Transport Protocol(s): TCP/UDP Description: DOTS Signal Channel Call Home Assignee: IESG Contact: IETF Chair Reference: RFC XXXX The assignment of port number 4647 is strongly suggested (DOTS signal channel uses port number 4646). 4.2. DOTS Signal Channel CBOR Mappings Registry This specification registers the following comprehension-optional parameters (Table 2) in the IANA "DOTS Signal Channel CBOR Key - Values" registry established by [I-D.ietf-dots-signal-channel] and - maintained at https://www.iana.org/assignments/dots/dots.xhtml#dots- - signal-channel-cbor-key-values. + 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 | Specification | | | Key | Major | Controller | Document(s) | | | Value | Type | | | - +--------------------+-------+-------+------------+---------------+ + +====================+=======+=======+============+===============+ |ietf-dots-call-home:| | | | | | source-prefix | TBA1 | 4 | IESG | [RFCXXXX] | + +--------------------+-------+-------+------------+---------------+ |ietf-dots-call-home:| | | | | | source-port-range | TBA2 | 4 | IESG | [RFCXXXX] | + +--------------------+-------+-------+------------+---------------+ |ietf-dots-call-home:| | | | | | source-icmp-type- | TBA3 | 4 | IESG | [RFCXXXX] | | range | | | | | - |ietf-dots-call-home:| | | | | + +--------------------+-------+-------+------------+---------------+ | lower-type | TBA4 | 0 | IESG | [RFCXXXX] | - |ietf-dots-call-home:| | | | | + +--------------------+-------+-------+------------+---------------+ | upper-type | TBA5 | 0 | IESG | [RFCXXXX] | + +--------------------+-------+-------+------------+---------------+ |ietf-dots-call-home:| | | | | | alt-ch-client | TBA6 | 3 | IESG | [RFCXXXX] | + +--------------------+-------+-------+------------+---------------+ |ietf-dots-call-home:| | | | | |alt-ch-client-record| TBA7 | 4 | IESG | [RFCXXXX] | + +--------------------+-------+-------+------------+---------------+ |ietf-dots-call-home:| | | | | | ttl | TBA8 | 0 | IESG | [RFCXXXX] | +--------------------+-------+-------+------------+---------------+ Table 2: Assigned DOTS Signal Channel CBOR Key Values 4.3. New DOTS Conflict Cause This document requests IANA to assign a new code from the "DOTS - Signal Channel Conflict Cause Codes" registry established by - [I-D.ietf-dots-signal-channel] and maintained at - https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel- - conflict-cause-codes. + Signal Channel Conflict Cause Codes" registry [Cause]. +-------+----------------------------------+------------+-----------+ | Code | Label | Descriptio | Reference | | | | n | | +-------+----------------------------------+------------+-----------+ | 4 (TB | request-rejected-legitimate- | Mitigation | [RFCXXXX] | | A9) | traffic | request | | | | | rejected. | | | | | This code | | | | | is | | @@ -1231,35 +1234,35 @@ 4.4. DOTS Signal Call Home YANG Module This document requests IANA to register the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-dots-call-home Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document requests IANA to register the following YANG module in - the "YANG Module Names" subregistry [RFC7950] within the "YANG + the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry: name: ietf-dots-call-home namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home maintained by IANA: N - prefix: call-home + prefix: dots-call-home reference: RFC XXXX 5. Security Considerations This document deviates from classic DOTS signal channel usage by having the DOTS server initiate the (D)TLS connection. DOTS signal - channel related security considerations discussed in Section 10 of - [I-D.ietf-dots-signal-channel] MUST be considered. DOTS agents MUST + channel related security considerations discussed in Section 11 of + [I-D.ietf-dots-rfc8782-bis] MUST be considered. DOTS agents MUST authenticate each other using (D)TLS before a DOTS signal channel session is considered valid. An attacker may launch a DoS attack on the DOTS client by having it perform computationally expensive operations, before deducing that the attacker doesn't possess a valid key. For instance, in TLS 1.3 [RFC8446], the ServerHello message contains a Key Share value based on an expensive asymmetric key operation for key establishment. Common precautions mitigating DoS attacks are recommended, such as temporarily blacklisting the source address after a set number of @@ -1336,86 +1339,98 @@ 8. Acknowledgements Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Toema Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments. 9. References 9.1. Normative References - [I-D.ietf-dots-signal-channel] - Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and - N. Teague, "Distributed Denial-of-Service Open Threat - Signaling (DOTS) Signal Channel Specification", draft- - ietf-dots-signal-channel-41 (work in progress), January - 2020. + [I-D.ietf-dots-rfc8782-bis] + Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed + Denial-of-Service Open Threat Signaling (DOTS) Signal + Channel Specification", draft-ietf-dots-rfc8782-bis-00 + (work in progress), August 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . + [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for + the Network Configuration Protocol (NETCONF)", RFC 6020, + DOI 10.17487/RFC6020, October 2010, + . + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . - [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", - RFC 7950, DOI 10.17487/RFC7950, August 2016, - . - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . + [RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data + Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, + June 2020, . + 9.2. Informative References + [Cause] IANA, "DOTS Signal Channel Conflict Cause Codes", + . + [I-D.ietf-dots-multihoming] Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing Deployment Considerations for Distributed-Denial-of- Service Open Threat Signaling (DOTS)", draft-ietf-dots- - multihoming-03 (work in progress), January 2020. + multihoming-04 (work in progress), May 2020. [I-D.ietf-dots-server-discovery] Boucadair, M. and T. Reddy.K, "Distributed-Denial-of- Service Open Threat Signaling (DOTS) Agent Discovery", draft-ietf-dots-server-discovery-10 (work in progress), February 2020. [I-D.ietf-dots-use-cases] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Open Threat - Signaling", draft-ietf-dots-use-cases-20 (work in - progress), September 2019. + Signaling", draft-ietf-dots-use-cases-25 (work in + progress), July 2020. [I-D.ietf-i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Birkholz, "Interface to Network Security Functions (I2NSF) Terminology", draft-ietf-i2nsf-terminology-08 (work in progress), July 2019. [I-D.ietf-idr-flow-spec-v6] Loibl, C., Raszuk, R., and S. Hares, "Dissemination of Flow Specification Rules for IPv6", draft-ietf-idr-flow- - spec-v6-10 (work in progress), November 2019. + spec-v6-14 (work in progress), August 2020. + + [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", + . [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, . [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, . @@ -1498,20 +1513,25 @@ Threat Signaling (DOTS) Requirements", RFC 8612, DOI 10.17487/RFC8612, May 2019, . [Sec] UK Department for Digital Culture, Media & Sport, "Secure by Design: Improving the cyber security of consumer Internet of Things Report", March 2018, . + [ServicePorts] + IANA, "Service Name and Transport Protocol Port Number + Registry", . + Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home With the DOTS signal channel Call Home, there is a chance that two DOTS agents can simultaneously establish two DOTS signal channels with different directions (base DOTS signal channel and DOTS signal channel Call Home). Here is one example drawn from the home network. Nevertheless, the outcome of the discussion is not specific to these networks, but applies to any DOTS Call Home scenario. In the Call Home scenario, the DOTS server in, for example, the home @@ -1526,21 +1546,21 @@ peer at the same time the home network element will have the base DOTS signal channel and the DOTS signal channel Call Home defined in this specification. Thus, these two signal channels need to be distinguished when they are both supported. Two approaches have been considered for distinguishing the two DOTS signal channels, but only the one that using the dedicated port number has been chosen as the best choice. By using a dedicated port number for each, these two signal channels can be separated unambiguously and easily. For example, the CPE uses - the port number 4646 allocated in [I-D.ietf-dots-signal-channel] to + the port number 4646 allocated in [I-D.ietf-dots-rfc8782-bis] to initiate the basic signal channel to the ISP when it acts as the DOTS client, and uses the port number TBD to initiate the signal channel Call Home. Based on the different port numbers, the ISP can directly decide which kind of procedures should follow immediately after it receives the DOTS messages. This approach just requires two (D)TLS sessions to be established respectively for the basic signal channel and signal channel Call Home. The other approach is signaling the role of each DOTS agent (e.g., by using the DOTS data channel). For example, the DOTS agent in the