--- 1/draft-ietf-dots-signal-call-home-05.txt 2019-09-10 02:13:22.486558733 -0700 +++ 2/draft-ietf-dots-signal-call-home-06.txt 2019-09-10 02:13:22.618562081 -0700 @@ -1,21 +1,21 @@ DOTS T. Reddy Internet-Draft McAfee Intended status: Standards Track M. Boucadair -Expires: January 31, 2020 Orange +Expires: March 13, 2020 Orange J. Shallow - July 30, 2019 + September 10, 2019 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home - draft-ietf-dots-signal-call-home-05 + draft-ietf-dots-signal-call-home-06 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). @@ -57,21 +57,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 January 31, 2020. + This Internet-Draft will expire on March 13, 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 @@ -80,43 +80,45 @@ 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.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 6 - 1.4. Co-existence of Base DOTS Signal Channel & DOTS Call Home 7 + 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. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 13 - 3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 14 - 3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 14 - 3.3.2. Address Sharing Considerations . . . . . . . . . . . 17 - 3.3.3. DOTS Signal Call Home YANG Module . . . . . . . . . . 20 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 - 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 24 - 4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 24 - 4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 25 - 4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 26 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 - 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 - 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 28 - 9.2. Informative References . . . . . . . . . . . . . . . . . 29 - Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home . . 31 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 + 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 + 3.3.2. Address Sharing Considerations . . . . . . . . . . . 18 + 3.3.3. DOTS Signal Call Home YANG Module . . . . . . . . . . 21 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 25 + 4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 26 + 4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 27 + 4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 28 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 + 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29 + 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 30 + 9.2. Informative References . . . . . . . . . . . . . . . . . 31 + Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home . . 34 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 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 @@ -549,24 +550,26 @@ [I-D.ietf-dots-signal-channel] 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]. - Section 3.2 specifies the behavior to be followed by Call Home + Section 3.2.1 specifies the behavior to be followed by Call Home DOTS agents. -3.2. Heartbeat Mechanism +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. @@ -586,20 +589,72 @@ client, the Call Home DOTS server MUST continue to use the DOTS signal channel even if the missing heartbeats allowed threshold ('missing-hb-allowed') is reached. 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. + + 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. + + 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). + + 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" + Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" + Uri-Path: "mid=123" + Content-Format: "application/dots+cbor" + + { + "ietf-dots-signal-channel:redirected-signal": { + "ietf-dots-call-home:alt-ch-client": + "alt-call-home-client.example", + "ietf-dots-call-home:alt-ch-client-record": [ + "2001:db8:6401::1", + "2001:db8:6401::2" + ], + "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 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: @@ -661,21 +716,21 @@ Address sharing implications on the setting of source information ('source-prefix', 'source-port-range') are discussed in Section 3.3.2. Only immediate mitigation requests (i.e., 'trigger-mitigation' set to 'true') are allowed; Call Home DOTS clients MUST NOT send requests with 'trigger-mitigation' set to 'false'. Such requests MUST be discarded by the Call Home DOTS server with a 4.00 (Bad Request). An example of a mitigation request sent by a Call Home DOTS client is - shown in Figure 8. + shown in Figure 9. Header: PUT (Code=0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "mid=56" Content-Format: "application/dots+cbor" { @@ -687,21 +742,21 @@ ], "ietf-dots-call-home:source-prefix": [ "2001:db8:123::/128" ], "lifetime": 3600 } ] } } - Figure 8: An Example of Mitigation Request Issued by a Call Home DOTS + 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]. @@ -743,21 +798,21 @@ The DOTS agents follow the same procedures specified in [I-D.ietf-dots-signal-channel] 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 9). The Call Home + 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 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 Call Home DOTS client SHOULD rely on mechanisms, such as [RFC8512] or [RFC8513], to retrieve the internal IP address and port number which are mapped to an external IP address and port number. N | .-------------------. @@ -782,32 +837,32 @@ .' Source Network ' ( ) ( Call Home -' '-( DOTS server ) '------+------------' | +-----+-------+ |Attack Source| +-------------+ - Figure 9: Example of a CGN between DOTS Domains + Figure 10: 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. If a translator is enabled on the boundaries of the domain hosting the Call Home DOTS server (e.g., a CPE with NAT enabled as shown in - Figures 10 and 11), the Call Home DOTS server uses the attack traffic + Figures 11 and 12), the Call Home 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. .-------------------. ( )-. .' Network Provider (DMS)' ( ) @@ -826,21 +881,21 @@ N | .' ' E | ( Call Home ) T | ( DOTS server -' W | '-( ) O | '-------+-----------' R | | K | +------+------+ | |Attack Source| +-------------+ - Figure 10: Example of a DOTS Server Domain with a NAT Embedded in a + Figure 11: Example of a DOTS Server Domain with a NAT Embedded in a CPE .-------------------. ( )-. .' Network Provider (DMS) ' ( ) ( Call Home -' '-( DOTS client ) '---------+---------' | @@ -856,21 +911,21 @@ N | .' ' E | ( Local Area Network ) T | ( -' W | '-( ) O | '--------+----------' R | | K | +------+------+ | |Attack Source| +-------------+ - Figure 11: Example of a Call Home DOTS Server and a NAT Embedded in a + 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: @@ -879,26 +934,31 @@ 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}? 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" + file "ietf-dots-call-home@2019-09-06.yang" module ietf-dots-call-home { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home"; prefix call-home; import ietf-inet-types { prefix inet; reference "Section 4 of RFC 6991"; @@ -936,36 +996,43 @@ 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-04-25 { + revision 2019-09-06 { 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."; + can be supplied in mitigation requests. This is + typically applicable for DOTS Call Home."; + } + feature call-home { + 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."; leaf-list source-prefix { type inet:ip-prefix; description "IPv4 or IPv6 prefix identifying the attacker(s)."; } list source-port-range { key "lower-port"; @@ -1005,20 +1072,46 @@ 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; + description + "The alternate Call Home DOTS client."; + + 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: @@ -1034,47 +1127,54 @@ 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', '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 12). + [I-D.ietf-dots-signal-channel] (Figure 13). 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 + o Note to the RFC Editor: Please delete (TBD1)-(TBD8) once CBOR keys are assigned from the 0x8000 - 0xBFFF range. +-------------------+------------+--------+---------------+--------+ | Parameter Name | YANG | CBOR | CBOR Major | JSON | | | Type | Key | Type & | Type | | | | | Information | | +-------------------+------------+--------+---------------+--------+ | source-prefix | leaf-list | 0x8000 | 4 array | Array | | | inet: | (TBD1) | | | | | ip-prefix | | 3 text string | String | | 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) | | | + | alt-ch-client | string | 0x8005 | 3 text string | String | + | | | (TBD6) | | | + | alt-ch-client- | leaf-list | 0x8006 | 4 array | Array | + | record | inet: | (TBD7) | | | + | | ip-address| | 3 text string | String | + | ttl | uint32 | 0x8007 | 0 unsigned | Number | + | | | (TBD8) | | | +-------------------+------------+--------+---------------+--------+ - Figure 12: Assigned DOTS Signal Channel CBOR Key Values + Figure 13: 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: +-----+-----------------------------------+-------------+-----------+ | Cod | Label | Description | Reference | | e | | | | +-----+-----------------------------------+-------------+-----------+ @@ -1207,21 +1307,21 @@ Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments. 9. References 9.1. Normative References [I-D.ietf-dots-signal-channel] K, R., 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-35 (work in progress), July 2019. + ietf-dots-signal-channel-37 (work in progress), July 2019. [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, . @@ -1248,29 +1348,28 @@ 9.2. Informative References [I-D.ietf-dots-multihoming] Boucadair, M., K, R., and W. Pan, "Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS)", draft-ietf-dots-multihoming-02 (work in progress), July 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-04 (work in progress), June - 2019. + Open Threat Signaling (DOTS) Agent Discovery", draft-ietf- + dots-server-discovery-05 (work in progress), August 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-18 (work - in progress), July 2019. + 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. [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] McPherson, D., Raszuk, R., Pithawala, B., akarch@cisco.com, a., and S. Hares, "Dissemination of Flow