Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home

The DOTS signal channel protocol 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 . 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 are available in the consumer market at affordable price. 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 easy mechanism to upgrade, and IoT manufactures may cease manufacture and/or discontinue patching vulnerabilities on IoT devices. However, these vulnerable and compromised devices will continue 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 on the victim while the owner/administrator of the home network is not aware about such misbehaviors. Similar to other DDoS attack, the victim in this attack can be an application server, a host, a router, a firewall, or an entire network. Nowadays, network devices in a home network offer network security, for instance, firewall/IPS service on a home router or gateway to protect the devices connected to the home network from external and internal attacks. Over the years several techniques have been identified to detect DDoS attacks, some of these techniques can be enabled on home network devices but most of them are used in the Internet Service Provider (ISP)'s network. The ISP offering DDoS mitigation service can detect outgoing DDoS attack traffic originating from its subscribers or the ISP may receive filtering rules (for example, using BGP flowspec ) from downstream service provider to filter, block, or rate-limit DDoS attack traffic originating from the ISP's subscribers to the downstream target. Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris, and TLS re-negotiation are difficult to detect on the home network devices without adversely affecting its performance. The reason is typically home routers have fast path to boost the throughput. For every new TCP/UDP flow, only the first few packets are punted through the slow 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 after the flow is switched to fast path. Deep packet inspection (DPI) of all the packets of a flow would be able to detect some of the attacks. However, a full-fledged DPI to detect these type of DDoS attacks is functionally or operationally not possible for all the devices attached to the home network owing to the memory and CPU limitations of the home routers. Further, for certain DDoS attacks the ability to distinguish legitimate traffic from attacker traffic on a per packet basis is complex. This complexity originates from the fact 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 the DDoS attack originating from a home network, 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 a IPv4 Home network are typically behind a NAT border. Even in case of a 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 the IP 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 do not discuss cooperative DDoS mitigation between the home network and ISP to the suppress the outbound DDoS attack traffic originating from the home network.

This specification addresses the problems discussed in and presents DOTS signal channel Call Home extension, which enables the DOTS server to initiate a secure connection to the DOTS client, and the DOTS client then conveys the attack traffic information to the DOTS server. The DOTS server uses the DDoS attack traffic information to identify the compromised device in its domain launching the DDoS attack, notifies the network administrator, and takes appropriate mitigation action. The mitigation action can be to quarantine the compromised device or block its traffic to the attack target until the mitigation request is withdrawn. For instance, the DOTS server in the home network initiates the Call Home during peace time and then subsequently the DOTS client in the ISP environment can initiate mitigation requests whenever the ISP detects there is an attack from a compromised device in the DOTS server's domain.

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 when, and only when, they appear in all capitals, as shown here. The reader should be familiar with the terms defined in .

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. The one and only role reversal that occurs are at the TCP/TLS or DTLS layers; that is, the DOTS server acts as a DTLS client and the DOTS client acts as a DTLS server or the DOTS server acts as a TCP/TLS client and the DOTS client acts as a TCP/TLS server. The DOTS server initiates TCP/TLS handshake or DTLS handshake to the DOTS client. For example, a home network element (e.g., home router) co-located with a DOTS server (likely, a client-domain DOTS gateway) is the TCP/TLS server and DTLS server. However, when calling home, the DOTS server initially assumes the role of the TCP/TLS client and DTLS client, but the network element's role as a DOTS server remains the same. Further, existing certificate chains and mutual authentication mechanisms between the DOTS agents are unaffected by 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 DOTS client and hence the DOTS server cannot be subjected to DDoS attacks. Other motivations for introducing Call Home are discussed in Section 1.1 of . illustrates sample Call Home flow exchange:

| | 2. Mitigation request | |<-----------------------------------| | | ]]> This diagram makes the following points: 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 defined in , but MAY be configured to listen to a different port. 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 defined in , but MAY be configured to listen to a different port. Using this TCP connection, the DOTS server initiates an TLS connection to the DOTS client. The happy eyeballs mechanism explained in Section 4.3 of can be used for initiation of both TCP and UDP sessions. Using this (D)TLS connection, the DOTS client requests, withdraws, or retrieves the status of mitigation requests.

This specification extends the mitigation request defined in to convey the attacker source prefixes and source port numbers. The DOTS client in the mitigation request conveys the following new parameters in the CBOR body of the mitigation request: A list of attacker prefixes used to attack the target. Prefixes are represented using Classless Inter-Domain Routing (CIDR) notation . As a reminder, the prefix length MUST be less than or equal to 32 (resp. 128) for IPv4 (resp. 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's domain.This is an optional attribute. 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) , or Datagram Congestion Control Protocol (DCCP) , a range of ports can be, for example, 0-1023, 1024-65535, or 1024-49151. This is an optional attribute. A list of ICMP types used by the attack traffic flows. A ICMP type range is defined by two bounds, a lower ICMP type number (lower-type) and an upper ICMP type number (upper-type). When only ‘lower-type’ is present, it represents a single ICMP type number. This is an optional attribute. This is an optional attribute. The 'source-prefix' and 'target-prefix' parameters are mandatory attributes when the attack traffic information is signaled by the DOTS client. The 'target-uri' or 'target-fqdn' parameters can be included in the mitigation request for diagnostic purpose to notify the DOTS server domain administrator but SHOULD not be used to determine the target IP addresses. The DOTS server uses the attack traffic information to find the pre-NAT 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. 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 ) indicates the cause of the conflict. The following new value is defined: Mitigation request rejected. This code is returned by the DOTS server to indicate the attack traffic has been classified as legitimate traffic. If the DOTS server is co-located with a home router, it can program the packet processor to punt all the traffic from the compromised device to the target to slow path. The home router 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 home administrator about the compromised device. TBD: a) Do we also want to convey Attack Name/type or ID (the home router may not be capable of detecting new emerging/sophisticated attacks) ? b) Is DOTS data channel Call Home service required (if required, can RESTCONF Call Home defined in RFC8071 be used) ?

This document augments the "dots-signal-channel" DOTS signal YANG module defined in for signaling the attack traffic information. This document defines the YANG module "ietf-dots-signal-call-home", which has the following structure:

file "ietf-dots-signal-call-home@2018-09-28.yang" module ietf-dots-signal-call-home { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-call-home"; prefix signal-call-home; import ietf-inet-types { prefix inet; reference "Section 4 of RFC 6991"; } import ietf-dots-signal-channel { prefix ietf-signal; reference "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification"; } organization "IETF DDoS Open Threat Signaling (DOTS) Working Group"; contact "WG Web: WG List: Editor: Konda, Tirumaleswar Reddy ; Editor: Mohamed Boucadair ; Editor: Jon Shallow "; description "This module contains YANG definition for the signaling messages exchanged between a DOTS client and a DOTS server. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. 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 2018-09-28 { description "Initial revision."; reference "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home"; } augment "/ietf-signal:dots-signal" { when "message-type='mitigation-scope'"; description "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 upper-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" { 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 upper-type"; description "ICMP type range. When only lower-type is present, it represents a single ICMP type number."; leaf lower-type { type uint8; mandatory true; description "Lower ICMP type number of the ICMP type range."; } leaf upper-type { type uint8; must ". >= ../lower-type" { error-message "The upper ICMP type number must be greater than or equal to lower ICMP type number."; } description "Upper type number of the ICMP type range."; } } } }]]>

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. The assignment of port number 4647 is strongly suggested (DOTS signal channel uses port number 4646).

This specification registers the 'source-prefix' and 'source-port-range' parameters in the IANA "DOTS Signal Channel CBOR Mappings" registry established by . The source-prefix and source-port-range are comprehension-optional parameters.

This document requests IANA to register the following URIs in the "IETF XML Registry" :

This document requests IANA to register the following YANG modules in the "YANG Module Names" registry .

This document deviates from standard DOTS signal channel usage by having the DOTS server initiate the TCP/TLS or DTLS connection. DOTS signal channel related security considerations discussed in Section 10 of 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 , 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.

TBC.