--- 1/draft-ietf-dots-signal-call-home-02.txt 2019-07-08 02:13:53.227230232 -0700 +++ 2/draft-ietf-dots-signal-call-home-03.txt 2019-07-08 02:13:53.291231854 -0700 @@ -1,110 +1,139 @@ DOTS T. Reddy Internet-Draft McAfee Intended status: Standards Track M. Boucadair -Expires: December 2, 2019 Orange +Expires: January 9, 2020 Orange J. Shallow - May 31, 2019 + July 08, 2019 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home - draft-ietf-dots-signal-call-home-02 + draft-ietf-dots-signal-call-home-03 Abstract This document specifies the DOTS signal channel Call Home service, 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). The DOTS Call Home service is not specific to the home networks; the solution targets any deployment which requires to block 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- + signal-channel) + + 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. 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 December 2, 2019. + This Internet-Draft will expire on January 9, 2020. Copyright Notice Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 - 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 2 - 1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 7 - 3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 8 - 3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 9 - 3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 9 - 3.3.2. DOTS Signal Call Home YANG Module . . . . . . . . . . 14 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 17 - 4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 17 - 4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 18 - 4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 18 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 - 9.2. Informative References . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 5 + 1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 6 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 8 + 3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.2. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 9 + 3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 10 + 3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 10 + 3.3.2. Address Sharing Considerations . . . . . . . . . . . 12 + 3.3.3. DOTS Signal Call Home YANG Module . . . . . . . . . . 15 + + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 19 + 4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 19 + 4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 20 + 4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 21 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 + 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 + 9.2. Informative References . . . . . . . . . . . . . . . . . 24 + Appendix A. Disambiguate Base DOTS Signal vs. Call Home . . . . 26 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 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. 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, and with compute and memory becoming cheaper and cheaper, various types of IoT devices become available in the - consumer market at affordable price. But on the downside, the main + consumer market at affordable 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. IoT devices deployed in home networks can be easily compromised, they do not have an easy mechanism to upgrade, and IoT manufactures may cease manufacture and/or discontinue patching vulnerabilities on IoT devices (Sections 5.4 and 5.5 of [RFC8576]). However, these vulnerable and compromised devices will continue to be used for a long period of time in the home, and the end-user does not know that IoT devices in his/her home are compromised. The compromised IoT devices are typically used for launching DDoS attacks (Section 3 of @@ -145,21 +174,21 @@ on a per packet basis is complex. This complexity is due to that the packet itself may look "legitimate" and no attack signature can be identified. The anomaly can be identified only after detailed statistical analysis. The ISP on the other hand can detect some DDoS attacks originating from a home network (e.g., Section 2.6 of [RFC8517]), but the ISP does not have a mechanism to detect which device in the home network is generating the DDoS attack traffic. The primary reason being that devices in an IPv4 home network are typically behind a Network - Address Translation (NAT) border. Even in case of a IPv6 home + Address Translation (NAT) border. Even in case of an IPv6 home network, although the ISP can identify the infected device in the home network launching the DDoS traffic by tracking its unique IPv6 address, the 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 @@ -264,22 +293,21 @@ list of such deployments. 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 - [I-D.ietf-dots-requirements]. + The reader should be familiar with the terms defined in [RFC8612]. The meaning of the symbols in YANG tree diagrams is defined in [RFC8340]. (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 @@ -306,43 +334,48 @@ enables the DOTS server co-located with a network element (possibly behind NATs and firewalls) reachable by only the intended DOTS client and hence the DOTS server cannot be subjected to DDoS attacks. Figure 2 illustrates a sample Call Home flow exchange: +--------+ +--------+ | DOTS | | DOTS | | server | | client | +---+----+ +----+---+ + (D)TLS client (D)TLS server | | | 1. (D)TLS connection | |----------------------------------->| | 2. Mitigation request | |<-----------------------------------| | ... | Figure 2: DOTS Signal Channel Call Home Sequence Diagram The DOTS signal channel Call Home procedure is as follows: 1. If UDP transport is used, the DOTS server begins by initiating a - DTLS connection to the DOTS client. The DOTS client MUST support - accepting DTLS connection on the IANA-assigned port number - defined in Section 4.1, but MAY be configured to listen to a - different port number. + DTLS connection to the DOTS client. If TCP is used, the DOTS server begins by initiating a TCP - connection to the DOTS client. The DOTS client MUST support - accepting TCP connections on the IANA-assigned port number - defined in Section 4.1, but MAY be configured to listen to a - different port number. Using this TCP connection, the DOTS - server initiates a TLS connection to the DOTS client. + connection to the DOTS client. Using this TCP connection, the + DOTS server initiates a TLS connection to the DOTS client. + + In some cases, a DOTS client and server may have mutual agreement + to use 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, 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] can be used for initiating (D)TLS connections. 2. Using this (D)TLS connection, the DOTS client may request, withdraw, or retrieve the status of mitigation requests. 3.2. Heartbeat Mechanism @@ -363,23 +396,21 @@ It is the responsibility of DOTS servers to ensure that on-path translators/firewalls are maintaining a binding so that the same external IP address and/or port number is retained for the DOTS signal channel session. A DOTS client MAY trigger their heartbeat requests immediately after receiving heartbeat probes from its peer DOTS server. When an outgoing attack that saturates the outgoing link from the DOTS server is detected and reported by a DOTS client, the latter MUST continue to use the signal channel even if no traffic is - received from the DOTS server. It is most likely that the outgoing - traffic is exceeding the DOTS server domain capacity. As a reminder, - the DOTS client cannot initiate a (D)TLS connection. + received from the DOTS server. If the DOTS server receives traffic from the DOTS client, the DOTS server MUST continue to use the signal channel even if the missing heartbeat allowed threshold is reached. If the DOTS server does not receive any traffic from the peer DOTS client, the DOTS server sends heartbeat requests to the DOTS client and after maximum 'missing-hb-allowed' threshold is reached, the DOTS server concludes the session is disconnected. Then, the DOTS server MUST try to resume the (D)TLS session. @@ -392,72 +423,116 @@ Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the attacker source prefixes and 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 - (resp. 128) for IPv4 (resp. IPv6). + (or 128) for IPv4 (or IPv6). The prefix list MUST NOT include broadcast, loopback, or multicast addresses. These addresses are considered as invalid values. In addition, the DOTS client MUST validate that attacker prefixes are within the scope of the DOTS server domain. - This is an optional attribute. + This is an optional attribute for the base DOTS signal channel + operations [I-D.ietf-dots-signal-channel]. source-port-range: A list of port numbers used by the attack traffic flows. A port range is defined by two bounds, a lower port number (lower- port) and an upper port number (upper-port). When only 'lower- port' is present, it represents a single port number. For TCP, UDP, Stream Control Transmission Protocol (SCTP) [RFC4960], or Datagram Congestion Control Protocol (DCCP) - [RFC4340], a range of ports can be, for example, 0-1023, - 1024-65535, or 1024-49151. + [RFC4340], a range of ports can be any subrange of 0-65535, for + example, 0-1023, 1024-65535, or 1024-49151. - This is an optional attribute. + This is an optional attribute for the base DOTS signal channel + operations [I-D.ietf-dots-signal-channel]. - source-icmp-type: A list of ICMP types used by the attack traffic - flows. An ICMP type range is defined by two bounds, a lower ICMP - type (lower-type) and an upper ICMP type (upper-type). When only - 'lower-type' is present, it represents a single ICMP type. + 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 + lower ICMP type (lower-type) and an upper ICMP type (upper-type). + When only 'lower-type' is present, it represents a single ICMP + type. - This is an optional attribute. + This is an optional attribute for the base DOTS signal channel + operations [I-D.ietf-dots-signal-channel]. The 'source-prefix' parameter is a mandatory attribute when the attack traffic information is signaled by a DOTS client in the Call - Home scenario. The 'target-uri' or 'target-fqdn' parameters can be - included in a mitigation request for diagnostic purposes to notify - the DOTS server domain administrator, but SHOULD NOT be used to - determine the target IP addresses. Note that 'target-prefix' becomes - a mandatory attribute in the mitigation request signaling the attack - information because 'target-uri' and 'target-fqdn' are optional - attributes and 'alias-name' will not be conveyed in a mitigation - request. + Home scenario (depicted in Figure 2). The 'target-uri' or 'target- + fqdn' parameters can be included in a mitigation request for + diagnostic purposes to notify the DOTS server domain administrator, + but SHOULD NOT be used to determine the target IP addresses. Note + that 'target-prefix' becomes a mandatory attribute in the mitigation + request signaling the attack information because 'target-uri' and + 'target-fqdn' are optional attributes and 'alias-name' will not be + conveyed in a mitigation request. In order to help attack source identification by a DOTS server, the DOTS client SHOULD include in its mitigation request additional information such as 'source-port-range' or 'source-icmp-type-range'. The DOTS client may not include such information if 'source-prefix' conveys an IPv6 address/prefix. Only immediate mitigation requests (i.e., 'trigger-mitigation' set to 'true') are allowed; DOTS clients MUST NOT send requests with 'trigger-mitigation' set to 'false'. Such requests MUST be discarded by the DOTS server with a 4.00 (Bad Request). + The DOTS server MUST check that the 'source-prefix' is within the + scope of the DOTS server domain in the Call Home scenario. Note that + in such scenario, the DOTS server considers, by default, that any + routeable IP prefix enclosed in 'target-prefix' is within the scope + of the DOTS client. Invalid mitigation requests are handled as per + Section 4.4.1 of [I-D.ietf-dots-signal-channel]. + + The 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 DOTS server informs the DOTS client that the attack is + being mitigated. + + If the attack traffic information is identified by the DOTS server or + the DOTS server domain administrator as legitimate traffic, the + mitigation request is rejected, and 4.09 (Conflict) is returned to + the DOTS client. The conflict-clause (defined in Section 4.4.1 of + [I-D.ietf-dots-signal-channel]) 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 DOTS server, appropriate actions + are enforced to block the attack traffic within the source network. + The 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 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. + +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 DOTS server because the external IP address is not visible locally to the DOTS server (see Figure 3). The DOTS server is only aware of the internal IP addresses/prefixes bound to its domain. Thus, the DOTS client MUST NOT include the external IP address and/or port number identifying the suspect attack source, but MUST include the internal IP address and/or port number. To that aim, the DOTS client SHOULD rely on mechanisms, such as [RFC8512] or [RFC8513], to retrieve the @@ -495,27 +570,20 @@ Figure 3: Example of a CGN between DOTS Domains If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the provider's domain to service its customers, the identification of an attack source bound to an IPv4 address/prefix MUST also rely on source port numbers because the same IPv4 address is assigned to multiple customers. The port information is required to unambiguously identify the source of an attack. - The DOTS server MUST check that the 'source-prefix' is within the - scope of the DOTS server domain in the Call Home scenario. Note that - in such scenario, the DOTS server considers, by default, that any - routeable IP prefix enclosed in 'target-prefix' is within the scope - of the DOTS client. Invalid mitigation requests are handled as per - Section 4.4.1 of [I-D.ietf-dots-signal-channel]. - If a translator is enabled on the boundaries of the domain hosting the DOTS server (e.g., a CPE with NAT enabled as shown in Figures 4 and 5), the DOTS server uses the attack traffic information conveyed in a mitigation request to find the internal source IP address of the compromised device and blocks the traffic from the compromised device traffic to the attack target until the mitigation request is withdrawn. Doing so allows to isolate the suspicious device while avoiding to disturb other services. .-------------------. @@ -538,21 +606,23 @@ N | .' ' E | ( ) T | ( DOTS server -' W | '-( ) O | '------+------------' R | | K | +-----+-------+ | |Attack Source| +-------------+ - Figure 4: Example of a DOTS Server Domain with a NAT Embeded in a CPE + Figure 4: Example of a DOTS Server Domain with a NAT Embedded in a + CPE + .-------------------. ( )-. .' Network Provider ' ( (DMS) ) ( DOTS client -' '-( ) '---------+---------' | | --- +-----+-----+ @@ -566,75 +636,44 @@ N | .' ' E | ( Local Area Network ) T | ( -' W | '-( ) O | '------+------------' R | | K | +-----+-------+ | |Attack Source| +-------------+ - Figure 5: Example of a DOTS Server and a NAT Embeded in a CPE - - The DOTS server domain administrator consent MAY be required to block - the 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 DOTS server informs the DOTS client that the attack is - being mitigated. - - If the attack traffic information is identified by the DOTS server or - the DOTS server domain administrator as legitimate traffic, the - mitigation request is rejected, and 4.09 (Conflict) is returned to - the DOTS client. The conflict-clause (defined in Section 4.4.1 of - [I-D.ietf-dots-signal-channel]) 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 DOTS server, appropriate actions - are enforced to block the attack traffic within the source network. - The 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 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. + Figure 5: Example of a DOTS Server and a NAT Embedded in a CPE -3.3.2. DOTS Signal Call Home YANG Module +3.3.3. DOTS Signal Call Home YANG Module -3.3.2.1. Tree Structure +3.3.3.1. Tree Structure This document augments the "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: 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 -3.3.2.2. YANG Module +3.3.3.2. YANG Module This module uses the common YANG types defined in [RFC6991]. file "ietf-dots-call-home@2019-04-25.yang" module ietf-dots-call-home { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home"; prefix call-home; @@ -759,28 +797,37 @@ 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. + 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 'source-prefix' and 'source-port- - range' parameters in the IANA "DOTS Signal Channel CBOR Mappings" - registry established by [I-D.ietf-dots-signal-channel]. + This specification registers the 'source-prefix', 'source-port- + range', and 'source-icmp-type-range' parameters in the IANA "DOTS + Signal Channel CBOR Key Values" registry established by + [I-D.ietf-dots-signal-channel] (Figure 6). The 'source-prefix', 'source-port-range', and 'source-icmp-type- range' are comprehension-optional parameters. o Note to the RFC Editor: Please delete (TBD1)-(TBD5) once CBOR keys are assigned from the 0x8000 - 0xBFFF range. +-------------------+------------+--------+---------------+--------+ | Parameter Name | YANG | CBOR | CBOR Major | JSON | | | Type | Key | Type & | Type | @@ -792,53 +839,66 @@ | source-port-range | list | 0x8001 | 4 array | Array | | | | (TBD2) | | | | source-icmp-type- | list | 0x8002 | 4 array | Array | | range | | (TBD3) | | | | lower-type | uint8 | 0x8003 | 0 unsigned | Number | | | | (TBD4) | | | | upper-type | uint8 | 0x8004 | 0 unsigned | Number | | | | (TBD5) | | | +-------------------+------------+--------+---------------+--------+ + Figure 6: 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 - Conflict Cause Codes" registry: + Signal Channel Conflict Cause Codes" registry: - +------+------------------+-----------------------------+-----------+ - | Code | Label | Description | Reference | - +------+------------------+-----------------------------+-----------+ - | 4 | request-rejected | Mitigation request | [RFCXXXX] | - | | | rejected. This code is | | - | | | returned by the DOTS server | | - | | | to indicate the attack | | - | | | traffic has been classified | | - | | | as legitimate traffic. | | - +------+------------------+-----------------------------+-----------+ + +-----+-----------------------------------+-------------+-----------+ + | Cod | Label | Description | Reference | + | e | | | | + +-----+-----------------------------------+-------------+-----------+ + | 4 | request-rejected-legitimate- | Mitigation | [RFCXXXX] | + | | traffic | request | | + | | | rejected. | | + | | | This code | | + | | | is returned | | + | | | by the DOTS | | + | | | server to | | + | | | indicate | | + | | | the attack | | + | | | traffic has | | + | | | been | | + | | | classified | | + | | | as | | + | | | legitimate | | + | | | traffic. | | + +-----+-----------------------------------+-------------+-----------+ 4.4. DOTS Signal Call Home YANG Module - This document requests IANA to register the following URI in the - "IETF XML Registry" [RFC3688]: + 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" registry [RFC7950]. + the "YANG Module Names" subregistry [RFC7950] within the "YANG + Parameters" registry: - Name: ietf-call-home - Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home - Maintained by IANA: N - Prefix: call-home - Reference: RFC XXXX + name: ietf-call-home + namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home + maintained by IANA: N + prefix: 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 authenticate each other using (D)TLS before a DOTS signal channel session is considered valid. @@ -848,25 +908,25 @@ [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 unsuccessful authentication attempts. DOTS servers may not blindly trust mitigation requests from DOTS clients. For example, DOTS servers can use the attack flow information in a mitigation request to enable full-fledged packet inspection function to inspect all the traffic from the compromised - to the target or to re-direct the traffic from the compromised device - to the target to a DDoS mitigation system to scrub the suspicious - traffic. DOTS servers can also seek the consent of DOTS server - domain administrator to block the traffic from the compromised device - to the target (see Section 3.3.1). + device to the target or to re-direct the traffic from the compromised + device to the target to a DDoS mitigation system to scrub the + suspicious traffic. DOTS servers can also seek the consent of DOTS + server domain administrator to block the traffic from the compromised + device to the target (see Section 3.3.1). 6. Privacy Considerations The considerations discussed in [RFC6973] were taken into account to assess whether the DOTS Call Home extension introduces privacy threats. Concretely, the protocol does not leak any new information that can be used to ease surveillance. In particular, the DOTS server is not required to share information that is local to its network (e.g., @@ -907,20 +967,26 @@ 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 + 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] @@ -959,30 +1025,24 @@ . 9.2. Informative References [I-D.ietf-dots-multihoming] Boucadair, M. and R. K, "Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01 (work in progress), January 2019. - [I-D.ietf-dots-requirements] - Mortensen, A., K, R., and R. Moskowitz, "Distributed - Denial of Service (DDoS) Open Threat Signaling - Requirements", draft-ietf-dots-requirements-22 (work in - progress), March 2019. - [I-D.ietf-dots-server-discovery] Boucadair, M. and R. K, "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Server Discovery", draft- - ietf-dots-server-discovery-03 (work in progress), May + ietf-dots-server-discovery-04 (work in progress), June 2019. [I-D.ietf-dots-use-cases] Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Open Threat Signaling", draft-ietf-dots-use-cases-17 (work in progress), January 2019. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, @@ -1048,21 +1108,104 @@ Jacquenet, "An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective", RFC 8517, DOI 10.17487/RFC8517, February 2019, . [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of Things (IoT) Security: State of the Art and Challenges", RFC 8576, DOI 10.17487/RFC8576, April 2019, . + [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open + Threat Signaling (DOTS) Requirements", RFC 8612, + DOI 10.17487/RFC8612, May 2019, + . + +Appendix A. Disambiguate Base DOTS Signal vs. Call Home + + With the call home extension, 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 the home network can + mitigate the DDoS attacks launched by the compromised device in its + domain by receiving the mitigation request sent by the DOTS client in + the ISP environment. In addition, the DOTS client in the home + network can initiate a mitigation request to the DOTS server in the + ISP environment to ask for help when the home network is under a DDoS + attack. Such DOTS server and DOTS client in the home network can co- + locate in the same home network element (e.g., the Customer Premises + Equipment). In this case, with the same peer at the same time the + home network element will have the basic DOTS signal channel defined + in [I-D.ietf-dots-signal-channel] and the call home DOTS signal + channel defined in this specification. Thus these two signal + channels need to be distinguished when they are both supported. + + In the call home scenario, the DOTS server in, for example, the home + network can mitigate the DDoS attacks launched by the compromised + device in its domain by receiving the mitigation request sent by the + DOTS client in the ISP environment. In addition, the DOTS client in + the home network can initiate a mitigation request to the DOTS server + in the ISP environment to ask for help when the home network is under + a DDoS attack. Such DOTS server and DOTS client in the home network + can co-locate in the same home network element (e.g., the Customer + Premises Equipment). In this case, with the same peer at the same + time the home network element will have the basic DOTS signal channel + defined in [I-D.ietf-dots-signal-channel] and the call home DOTS + signal channel 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 defined in [I-D.ietf-dots-signal-channel] 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 call home signal + channel. Based on the different ports, 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 call + home signal channel. + + 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 + home network first initiates a DOTS data 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 DOTS agent in the ISP + environment is the DOTS server. After that, the DOTS agent in the + home network retrieves the DOTS call home capability of the peer DOTS + agent. If the peer supports the call home extension, the DOTS agent + needs to subscribe to the peer to use this extension. Then the + reversal of DOTS role can be recognized as done by both DOTS agents. + When the DOTS agent in the ISP environment, 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 server, for help. + + Signaling the role will complicate the DOTS protocol, and this + complexity is not required in context where call home extension is + not required or only when call home extension is needed. Besides, + the 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 channel, the more procedures will still reduce the + efficiency. Using the dedicated port number is much easier and more + concise compared to the second approach, and its cost that + establishing two (D)TLS sessions is much less. So, using a dedicated + port number for the call home extension is chosen in this + specification. + Authors' Addresses + Tirumaleswar Reddy McAfee, Inc. Embassy Golf Link Business Park Bangalore, Karnataka 560071 India Email: kondtir@gmail.com Mohamed Boucadair Orange