--- 1/draft-ietf-dots-signal-call-home-10.txt 2020-10-28 00:13:09.692185304 -0700 +++ 2/draft-ietf-dots-signal-call-home-11.txt 2020-10-28 00:13:09.780187764 -0700 @@ -1,21 +1,21 @@ DOTS T. Reddy Internet-Draft McAfee Intended status: Standards Track M. Boucadair -Expires: April 25, 2021 Orange +Expires: April 30, 2021 Orange J. Shallow - October 22, 2020 + October 27, 2020 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home - draft-ietf-dots-signal-call-home-10 + draft-ietf-dots-signal-call-home-11 Abstract This document specifies the DOTS signal channel Call Home, which enables a Call Home DOTS server to initiate a secure connection to a Call Home DOTS client, and to receive attack traffic information from the Call Home DOTS client. The Call Home DOTS server in turn uses the attack traffic information to identify compromised devices launching outgoing DDoS attacks and take appropriate mitigation action(s). @@ -58,21 +58,21 @@ 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 April 25, 2021. + This Internet-Draft will expire on April 30, 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 @@ -98,31 +98,31 @@ 5.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 16 5.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 16 5.3.2. Address Sharing Considerations . . . . . . . . . . . 20 6. DOTS Signal Call Home YANG Module . . . . . . . . . . . . . . 23 6.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 23 6.2. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . 24 6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 29 7.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 30 - 7.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 30 - 7.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 31 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 - 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33 - 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 - 12.2. Informative References . . . . . . . . . . . . . . . . . 36 - Appendix A. Disambiguating Base DOTS Signal vs. DOTS Call Home . 39 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 + 7.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 31 + 7.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 32 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 + 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34 + 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 35 + 12.2. Informative References . . . . . . . . . . . . . . . . . 37 + Appendix A. Disambiguating Base DOTS Signal vs. DOTS Call Home . 40 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 1. Introduction 1.1. The Problem 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 @@ -735,30 +735,30 @@ When only 'lower-type' is present, it represents a single ICMP type. Both ICMP [RFC0792] and ICMPv6 [RFC4443] types are supported. Whether ICMP or ICMPv6 types are to be used is determined by the address family of the 'target-prefix'. This is an optional attribute for the base DOTS signal channel operations. The 'source-prefix' parameter is a mandatory attribute when the attack traffic information is signaled by a Call Home DOTS client - (i.e., the Call Home scenario depicted in Figure 7). 'target-prefix' - attribute MUST be included in the mitigation request signaling the - attack information to a Call Home DOTS server. The 'target-uri' or - 'target-fqdn' parameters can be included in a mitigation request for - diagnostic purposes to notify the Call Home DOTS server domain - administrator, but SHOULD NOT be used to determine the target IP - addresses. 'alias-name' is unlikely to be conveyed in a Call Home - mitigation request given that a target may be any IP resource and - that there is no incentive for a Call Home DOTS server (embedded, for - example, in a CPE) to maintain aliases. + (i.e., the Call Home scenario depicted in Figure 7). The 'target- + prefix' attribute MUST be included in the mitigation request + signaling the attack information to a Call Home DOTS server. The + 'target-uri' or 'target-fqdn' parameters can be included in a + mitigation request for diagnostic purposes to notify the Call Home + DOTS server domain administrator, but SHOULD NOT be used to determine + the target IP addresses. 'alias-name' is unlikely to be conveyed in + a Call Home mitigation request given that a target may be any IP + resource and that there is no incentive for a Call Home DOTS server + (embedded, for example, in a CPE) to maintain aliases. In order to help attack source identification by a Call Home DOTS server, the Call Home DOTS client SHOULD include in its mitigation request additional information such as 'source-port-range' or 'source-icmp-type-range' to disambiguate nodes sharing the same 'source-prefix'. IPv6 addresses/prefixes are sufficient to uniquely identify a network endpoint, without need for port numbers or ICMP type information. While this is also possible for IPv4, it is much less often the case than for IPv6. More address sharing implications on the setting of source information ('source-prefix', 'source-port- @@ -820,31 +820,26 @@ If a consent from the Call Home DOTS server domain administrator is required, the Call Home DOTS server replies with 2.01 (Created) and 'status' code set to 1 (attack-mitigation-in-progress). Then, the mechanisms defined in Section 4.4.2 of [I-D.ietf-dots-rfc8782-bis] are followed by the DOTS agents to update the mitigation status. Particularly, if the attack traffic is blocked, the Call Home DOTS server informs the Call Home DOTS client that the attack is being mitigated (i.e., by setting the 'status' code to 2 (attack- successfully-mitigated)). - If the Call Home DOTS server rejects the mitigation request without - waiting for a consent from the Call Home DOTS server domain - administrator, the 'conflict-cause' set to '4' is returned in 4.09 - (Conflict) sent back to the Call Home DOTS client. - 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 with a 4.09 - (Conflict) or a notification message with the 'conflict-clause' - (Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis]) set to the following - new value: + (Conflict) (e.g., when no consent is required from an administrator) + or a notification message with the 'conflict-clause' (Section 4.4.1 + of [I-D.ietf-dots-rfc8782-bis]) set to the following new value: 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. 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. @@ -855,21 +850,21 @@ DOTS client is informed about the progress of the attack mitigation following the rules in Section 4.4.2 of [I-D.ietf-dots-rfc8782-bis]. The DOTS agents follow the same procedures specified in [I-D.ietf-dots-rfc8782-bis] for managing a mitigation request. 5.3.2. Address Sharing Considerations Figure 10 depictes an example of a network provider that hosts a Call Home DOTS client and deploys a Carrier Grade NAT (CGN) between the - DOTS client domain and DOTS server domain. In such case, + DOTS client domain and DOTS server domain. In such cases, communicating an external IP address in a mitigation request by a Call Home DOTS client is likely to be discarded by the Call Home DOTS server because the external IP address is not visible locally to the Call Home DOTS server (Figure 10). The Call Home DOTS server is only aware of the internal IP addresses/prefixes bound to its domain (i.e., those used in the Internal Realm shown in Figure 10). Thus, Call Home DOTS clients that are aware of the presence of on-path CGNs MUST NOT include the external IP address and/or port number identifying the suspect attack source (i.e., those used in the External Realm shown in Figure 10), but MUST include the internal IP @@ -1254,35 +1249,36 @@ } } } 7. IANA Considerations 7.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" [ServicePorts]. + channel Call Home protocol for both UDP and TCP and update the + following entry from the "Service 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 Protocol. The service name is used to construct the SRV service names "_dots-call-home._udp" and "_dots-call-home._tcp" for discovering Call Home DOTS clients used to establish DOTS signal channel call home. Assignee: IESG Contact: IETF Chair - Reference: RFC XXXX + Reference: [RFCXXXX][I-D.ietf-dots-server-discovery] The assignment of port number 4647 is strongly suggested (DOTS signal channel uses port number 4646). 7.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 [Key-Map].