idnits 2.17.1 draft-reddy-dots-home-network-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 412 has weird spacing: '...er-port ine...' == Line 413 has weird spacing: '...er-port ine...' == Line 416 has weird spacing: '...er-type uin...' == Line 417 has weird spacing: '...er-type uin...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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. -- The document date (April 01, 2019) is 1849 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 597, but not defined == Unused Reference: 'RFC4732' is defined on line 777, but no explicit reference was found in the text == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-30 == Outdated reference: A later version (-13) exists of draft-ietf-dots-multihoming-01 == Outdated reference: A later version (-15) exists of draft-ietf-dots-server-discovery-00 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-17 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS T. Reddy 3 Internet-Draft McAfee 4 Intended status: Standards Track M. Boucadair 5 Expires: October 3, 2019 Orange 6 J. Shallow 7 April 01, 2019 9 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 10 Channel Call Home 11 draft-reddy-dots-home-network-04 13 Abstract 15 This document presents DOTS signal channel Call Home service, which 16 enables a DOTS server to initiate a secure connection to a DOTS 17 client, and to receive the attack traffic information from the DOTS 18 client. The DOTS server in turn uses the attack traffic information 19 to identify the compromised devices launching the outgoing DDoS 20 attack and takes appropriate mitigation action. 22 The Call Home service is not specific to the home networks; the 23 solution targets any deployment which requires to block DDoS attack 24 traffic closer to the source(s) of a DDoS attack. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 3, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 4 63 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2. Notational Conventions and Terminology . . . . . . . . . . . 5 65 3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 5 66 3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. DOTS Signal Channel Extension . . . . . . . . . . . . . . 6 68 3.2.1. Mitigation Request . . . . . . . . . . . . . . . . . 6 69 3.2.2. DOTS Signal Call Home YANG Module . . . . . . . . . . 9 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 12 72 4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 12 73 4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 13 74 4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 13 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 77 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 81 9.2. Informative References . . . . . . . . . . . . . . . . . 16 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 1.1. The Problem 88 The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is 89 used to carry information about a network resource or a network (or a 90 part thereof) that is under a Distributed Denial of Service (DDoS) 91 attack. Such information is sent by a DOTS client to one or multiple 92 DOTS servers so that appropriate mitigation actions are undertaken on 93 traffic deemed suspicious. Various use cases are discussed in 94 [I-D.ietf-dots-use-cases]. 96 IoT devices are becoming more and more prevalent in home networks, 97 and with compute and memory becoming cheaper and cheaper, various 98 types of IoT devices become available in the consumer market at 99 affordable price. But on the downside, the main threat being most of 100 these IoT devices are bought off-the-shelf and most manufacturers 101 haven't considered security in the product design. IoT devices 102 deployed in home networks can be easily compromised, they do not have 103 an easy mechanism to upgrade, and IoT manufactures may cease 104 manufacture and/or discontinue patching vulnerabilities on IoT 105 devices. However, these vulnerable and compromised devices will 106 continue be used for a long period of time in the home, and the end- 107 user does not know that IoT devices in his/her home are compromised. 108 The compromised IoT devices are typically used for launching DDoS 109 attacks on the victim while the owner/administrator of the home 110 network is not aware about such misbehaviors. Similar to other DDoS 111 attacks, the victim in this attack can be an application server, a 112 host, a router, a firewall, or an entire network. 114 Nowadays, network devices in a home network offer network security, 115 for instance, firewall/IPS service on a home router or gateway to 116 protect the devices connected to the home network from external and 117 internal attacks. Over the years several techniques have been 118 identified to detect DDoS attacks, some of these techniques can be 119 enabled on home network devices but most of them are used in the 120 Internet Service Provider (ISP)'s network. The ISP offering DDoS 121 mitigation service can detect outgoing DDoS attack traffic 122 originating from its subscribers or the ISP may receive filtering 123 rules (for example, using BGP flowspec [RFC5575]) from downstream 124 service provider to filter, block, or rate-limit DDoS attack traffic 125 originating from the ISP's subscribers to the downstream target. 127 Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris, 128 and TLS re-negotiation are difficult to detect on the home network 129 devices without adversely affecting its performance. The reason is 130 typically home routers have fast path to boost the throughput. For 131 every new TCP/UDP flow, only the first few packets are punted through 132 the slow path. Hence, it is not possible to detect various DDoS 133 attacks in the slow path, since the attack payload is sent to the 134 target server after the flow is switched to fast path. Deep packet 135 inspection (DPI) of all the packets of a flow would be able to detect 136 some of the attacks. However, a full-fledged DPI to detect these 137 type of DDoS attacks is functionally or operationally not possible 138 for all the devices attached to the home network owing to the memory 139 and CPU limitations of the home routers. Further, for certain DDoS 140 attacks the ability to distinguish legitimate traffic from attacker 141 traffic on a per packet basis is complex. This complexity originates 142 from the fact that the packet itself may look "legitimate" and no 143 attack signature can be identified. The anomaly can be identified 144 only after detailed statistical analysis. 146 The ISP on the other hand can detect the DDoS attack originating from 147 a home network, but the ISP does not have a mechanism to detect which 148 device in the home network is generating the DDoS attack traffic. 149 The primary reason being that devices in a IPv4 Home network are 150 typically behind a NAT border. Even in case of a IPv6 Home network, 151 although the ISP can identify the infected device in the Home network 152 launching the DDoS traffic by tracking its unique IPv6 address, the 153 infected device can easily change the IP address to evade 154 remediation. 156 Existing approaches are still suffering from misused access network 157 resources by abusing devices; the support of means for blocking such 158 attacks close to the sources are missing. In particular, the DOTS 159 signal protocol does not discuss cooperative DDoS mitigation between 160 the home network and ISP to the suppress the outbound DDoS attack 161 traffic originating from the home network. 163 1.2. The Solution 165 This specification addresses the problems discussed in Section 1.1 166 and presents DOTS signal channel Call Home extension, which enables 167 the DOTS server to initiate a secure connection to the DOTS client, 168 and the DOTS client then conveys the attack traffic information to 169 the DOTS server. 171 In a typical deployment scenario, the DOTS server is enabled on a 172 CPE, which is aligned with recent trends to enrich the CPE with 173 advanced security features. Unlike classic DOTS deployments 174 [I-D.ietf-dots-use-cases], such DOTS server maintains a single DOTS 175 signal channel session for each DOTS-capable upstream provisioning 176 domain [I-D.ietf-dots-multihoming]. 178 For instance, the DOTS server in the home network initiates the Call 179 Home in 'idle' time and then subsequently the DOTS client in the ISP 180 environment can initiate a mitigation request whenever the ISP 181 detects there is an attack from a compromised device in the DOTS 182 server domain. 184 The DOTS server uses the DDoS attack traffic information to identify 185 the compromised device in its domain launching the DDoS attack, 186 notifies the network administrator, and takes appropriate mitigation 187 action. The mitigation action can be to quarantine the compromised 188 device or block its traffic to the attack target until the mitigation 189 request is withdrawn. 191 1.3. Scope 193 The aforementioned problems may be encountered in other deployments 194 than those discussed in Section 1.1. The solution specified in this 195 document can be used for those deployments to block DDoS attack 196 traffic closer to the source(s) of the attack. 198 It is out of the scope of this document to identify an exhaustive 199 list of such deployments. 201 2. Notational Conventions and Terminology 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 205 "OPTIONAL" in this document are to be interpreted as described in BCP 206 14 [RFC2119][RFC8174] when, and only when, they appear in all 207 capitals, as shown here. 209 The reader should be familiar with the terms defined in 210 [I-D.ietf-dots-requirements]. 212 3. DOTS Signal Channel Call Home 214 3.1. Procedure 216 The DOTS signal channel Call Home extension preserves all but one of 217 the DOTS client/server roles in the DOTS protocol stack, as compared 218 to DOTS client-initiated DOTS signal channel protocol 219 [I-D.ietf-dots-signal-channel]. The one and only role reversal that 220 occurs are at the TCP/TLS or DTLS layers; that is, the DOTS server 221 acts as a DTLS client and the DOTS client acts as a DTLS server or 222 the DOTS server acts as a TCP/TLS client and the DOTS client acts as 223 a TCP/TLS server. The DOTS server initiates TCP/TLS handshake or 224 DTLS handshake to the DOTS client. 226 For example, a home network element (e.g., home router) co-located 227 with a DOTS server (likely, a client-domain DOTS gateway) is the TCP/ 228 TLS server and DTLS server. However, when calling home, the DOTS 229 server initially assumes the role of the TCP/TLS client and DTLS 230 client, but the network element's role as a DOTS server remains the 231 same. Furthermore, existing certificate chains and mutual 232 authentication mechanisms between the DOTS agents are unaffected by 233 the Call Home function. This Call Home function enables the DOTS 234 server co-located with a network element (possibly behind NATs and 235 firewalls) reachable by only the intended DOTS client and hence the 236 DOTS server cannot be subjected to DDoS attacks. Other motivations 237 for introducing the Call Home function are discussed in Section 1.1 238 of [RFC8071]. 240 This document assumes that DOTS servers are provisioned with a way to 241 know how to reach the upstream DOTS client(s), which could occur by a 242 variety of means (e.g., [I-D.ietf-dots-server-discovery]). The 243 specification of such means are out of scope of this document. 245 Figure 1 illustrates a sample Call Home flow exchange: 247 DOTS DOTS 248 Server Client 249 | | 250 | 1. (D)TLS connection | 251 |----------------------------------->| 252 | 2. Mitigation request | 253 |<-----------------------------------| 254 | | 256 Figure 1: DOTS Signal Channel Call Home Sequence Diagram 258 The Call Home procedure is as follows: 260 1. If UDP transport is used, the DOTS server begins by initiating a 261 DTLS connection to the DOTS client. The DOTS client MUST support 262 accepting DTLS connection on the IANA-assigned port number 263 defined in Section 4.1, but MAY be configured to listen to a 264 different port number. 266 If TCP is used, the DOTS server begins by initiating a TCP 267 connection to the DOTS client. The DOTS client MUST support 268 accepting TCP connections on the IANA-assigned port number 269 defined in Section 4.1, but MAY be configured to listen to a 270 different port number. Using this TCP connection, the DOTS 271 server initiates a TLS connection to the DOTS client. 273 The Happy Eyeballs mechanism explained in Section 4.3 of 274 [I-D.ietf-dots-signal-channel] can be used for initiating (D)TLS 275 connections. 277 2. Using this (D)TLS connection, the DOTS client may request, 278 withdraw, or retrieve the status of mitigation requests. 280 3.2. DOTS Signal Channel Extension 282 3.2.1. Mitigation Request 284 This specification extends the mitigation request defined in 285 [I-D.ietf-dots-signal-channel] to convey the attacker source prefixes 286 and source port numbers. The DOTS client conveys the following new 287 parameters in the CBOR body of the mitigation request: 289 source-prefix: A list of attacker prefixes used to attack the 290 target. Prefixes are represented using Classless Inter-Domain 291 Routing (CIDR) notation [RFC4632]. 293 As a reminder, the prefix length MUST be less than or equal to 32 294 (resp. 128) for IPv4 (resp. IPv6). 296 The prefix list MUST NOT include broadcast, loopback, or multicast 297 addresses. These addresses are considered as invalid values. In 298 addition, the DOTS client MUST validate that attacker prefixes are 299 within the scope of the DOTS server domain. 301 This is an optional attribute. 303 source-port-range: A list of port numbers used by the attack traffic 304 flows. 306 A port range is defined by two bounds, a lower port number (lower- 307 port) and an upper port number (upper-port). When only 'lower- 308 port' is present, it represents a single port number. 310 For TCP, UDP, Stream Control Transmission Protocol (SCTP) 311 [RFC4960], or Datagram Congestion Control Protocol (DCCP) 312 [RFC4340], a range of ports can be, for example, 0-1023, 313 1024-65535, or 1024-49151. 315 This is an optional attribute. 317 source-icmp-type: A list of ICMP types used by the attack traffic 318 flows. An ICMP type range is defined by two bounds, a lower ICMP 319 type (lower-type) and an upper ICMP type (upper-type). When only 320 'lower-type' is present, it represents a single ICMP type. 322 This is an optional attribute. 324 The 'source-prefix' parameter is a mandatory attribute when the 325 attack traffic information is signaled by a DOTS client in the Call 326 Home scenario. The 'target-uri' or 'target-fqdn' parameters can be 327 included in a mitigation request for diagnostic purposes to notify 328 the DOTS server domain administrator, but SHOULD NOT be used to 329 determine the target IP addresses. Note that 'target-prefix' becomes 330 a mandatory attribute in the mitigation request signaling the attack 331 information because 'target-uri' and 'target-fqdn' are optional 332 attributes and 'alias-name' will not be conveyed in a mitigation 333 request. 335 In order to help attack source identification by a DOTS server, the 336 DOTS client SHOULD include in its mitigation request additional 337 information such as 'source-port-range' or 'source-icmp-type-range'. 338 The DOTS client MAY NOT include such information if 'source-prefix' 339 conveys an IPv6 address/prefix. 341 If a Carrier Grade NAT (CGN, including NAT64) is located between the 342 DOTS client domain and DOTS server domain, communicating an external 343 IP address in a mitigation request is likely to be discarded by the 344 DOTS server because the external IP address is not visible locally to 345 the DOTS server. The DOTS server is only aware of the internal IP 346 addresses/prefixes bound to its domain. Thus, the DOTS client MUST 347 NOT include the external IP address and/or port number identifying 348 the suspect attack source, but MUST include the internal IP address 349 and/or port number. To that aim, the DOTS client SHOULD rely on 350 mechanisms, such as [RFC8512] or [RFC8513], to retrieve the internal 351 IP address and port number which are mapped to an external IP address 352 and port number. 354 If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the 355 provider's domain to service its customers, the identification of an 356 attack source bound to an IPv4 address/prefix MUST also rely on 357 source port numbers because the same IPv4 address is assigned to 358 multiple customers. The port information is required to 359 unambiguously identify the source of an attack. 361 If a translator is enabled on the boundaries of the domain hosting 362 the DOTS server (a CPE with NAT enabled, typically), the DOTS server 363 uses the attack traffic information conveyed in a mitigation request 364 to find the internal source IP address of the compromised device and 365 blocks the traffic from the compromised device traffic to the attack 366 target until the mitigation request is withdrawn. Doing so allows to 367 isolate the suspicious device while avoiding to disturb other 368 services. 370 The DOTS server domain administrator consent MAY be required to block 371 the traffic from the compromised device to the attack target. An 372 implementation MAY have a configuration knob to block the traffic 373 from the compromised device to the attack target with or without DOTS 374 server domain administrator consent. If the attack traffic is 375 blocked, the DOTS server informs the DOTS client that the attack is 376 being mitigated. 378 If the attack traffic information is identified by the DOTS server or 379 the DOTS server domain administrator as legitimate traffic, the 380 mitigation request is rejected, and 4.09 (Conflict) is returned to 381 the DOTS client. The conflict-clause (defined in Section 4.4.1 of 382 [I-D.ietf-dots-signal-channel]) indicates the cause of the conflict. 383 The following new value is defined: 385 4: Mitigation request rejected. This code is returned by the DOTS 386 server to indicate the attack traffic has been classified as 387 legitimate traffic. 389 If the DOTS server is co-located with a home router, it can program 390 the packet processor to punt all the traffic from the compromised 391 device to the target to slow path. The home router inspects the 392 punted slow path traffic to detect and block the outgoing DDoS attack 393 traffic or quarantine the device (e.g., using MAC level filtering) 394 until it is remediated, and notifies the home administrator about the 395 compromised device. 397 3.2.2. DOTS Signal Call Home YANG Module 399 3.2.2.1. Tree Structure 401 This document augments the "dots-signal-channel" DOTS signal YANG 402 module defined in [I-D.ietf-dots-signal-channel] for signaling the 403 attack traffic information. This document defines the YANG module 404 "ietf-dots-call-home", which has the following tree structure: 406 module: ietf-dots-call-home 407 augment /ietf-signal:dots-signal/ietf-signal:message-type 408 /ietf-signal:mitigation-scope/ietf-signal:scope: 409 +--rw source-prefix* inet:ip-prefix {source-signaling}? 410 +--rw source-port-range* 411 | | [lower-port upper-port] {source-signaling}? 412 | +--rw lower-port inet:port-number 413 | +--rw upper-port inet:port-number 414 +--rw source-icmp-type-range* 415 | [lower-type upper-type] {source-signaling}? 416 +--rw lower-type uint8 417 +--rw upper-type uint8 419 3.2.2.2. YANG Module 421 file "ietf-dots-call-home@2018-04-01.yang" 423 module ietf-dots-call-home { 424 yang-version 1.1; 425 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home"; 426 prefix call-home; 428 import ietf-inet-types { 429 prefix inet; 430 reference 431 "Section 4 of RFC 6991"; 433 } 434 import ietf-dots-signal-channel { 435 prefix ietf-signal; 436 reference 437 "RFC YYYY: Distributed Denial-of-Service Open Threat 438 Signaling (DOTS) Signal Channel Specification"; 439 } 441 organization 442 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 443 contact 444 "WG Web: 445 WG List: 447 Editor: Konda, Tirumaleswar Reddy 448 ; 450 Editor: Mohamed Boucadair 451 ; 453 Editor: Jon Shallow 454 "; 456 description 457 "This module contains YANG definition for the signaling 458 messages exchanged between a DOTS client and a DOTS server 459 for the call home deployment scenario. 461 Copyright (c) 2018 IETF Trust and the persons identified as 462 authors of the code. All rights reserved. 464 Redistribution and use in source and binary forms, with or 465 without modification, is permitted pursuant to, and subject 466 to the license terms contained in, the Simplified BSD License 467 set forth in Section 4.c of the IETF Trust's Legal Provisions 468 Relating to IETF Documents 469 (http://trustee.ietf.org/license-info). 471 This version of this YANG module is part of RFC XXXX; see 472 the RFC itself for full legal notices."; 474 revision 2018-04-01 { 475 description 476 "Initial revision."; 477 reference 478 "RFC XXXX: Distributed Denial-of-Service Open Threat 479 Signaling (DOTS) Signal Channel Call Home"; 480 } 481 feature source-signaling { 482 description 483 "This feature means that source-related information 484 can be supplied in mitigation requests."; 485 } 487 augment "/ietf-signal:dots-signal/ietf-signal:message-type/" 488 + "ietf-signal:mitigation-scope/ietf-signal:scope" { 489 if-feature source-signaling; 490 description "Attacker source details"; 492 leaf-list source-prefix { 493 type inet:ip-prefix; 494 description 495 "IPv4 or IPv6 prefix identifying the attacker(s)."; 496 } 497 list source-port-range { 498 key "lower-port upper-port"; 499 description 500 "Port range. When only lower-port is 501 present, it represents a single port number."; 502 leaf lower-port { 503 type inet:port-number; 504 mandatory true; 505 description 506 "Lower port number of the port range."; 507 } 508 leaf upper-port { 509 type inet:port-number; 510 must ". >= ../lower-port" { 511 error-message 512 "The upper port number must be greater than 513 or equal to lower port number."; 514 } 515 description 516 "Upper port number of the port range."; 517 } 518 } 519 list source-icmp-type-range { 520 key "lower-type upper-type"; 521 description 522 "ICMP type range. When only lower-type is 523 present, it represents a single ICMP type."; 524 leaf lower-type { 525 type uint8; 526 mandatory true; 527 description 528 "Lower ICMP type of the ICMP type range."; 530 } 531 leaf upper-type { 532 type uint8; 533 must ". >= ../lower-type" { 534 error-message 535 "The upper ICMP type must be greater than 536 or equal to lower ICMP type."; 537 } 538 description 539 "Upper type of the ICMP type range."; 540 } 541 } 542 } 543 } 544 546 4. IANA Considerations 548 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number 550 IANA is requested to assign the port number TBD to the DOTS signal 551 channel Call Home protocol for both UDP and TCP from the "Service 552 Name and Transport Protocol Port Number Registry" available at: 553 https://www.iana.org/assignments/service-names-port-numbers/service- 554 names-port-numbers.xhtml. 556 The assignment of port number 4647 is strongly suggested (DOTS signal 557 channel uses port number 4646). 559 4.2. DOTS Signal Channel CBOR Mappings Registry 561 This specification registers the 'source-prefix' and 'source-port- 562 range' parameters in the IANA "DOTS Signal Channel CBOR Mappings" 563 registry established by [I-D.ietf-dots-signal-channel]. 565 The 'source-prefix', 'source-port-range', and 'source-icmp-type- 566 range' are comprehension-optional parameters. 568 o Note to the RFC Editor: Please delete (TBD1)-(TBD5) once CBOR keys 569 are assigned from the 0x8000 - 0xBFFF range. 571 +-------------------+------------+--------+---------------+--------+ 572 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 573 | | Type | Key | Type & | Type | 574 | | | | Information | | 575 +-------------------+------------+--------+---------------+--------+ 576 | source-prefix | leaf-list | 0x8000 | 4 array | Array | 577 | | inet: | (TBD1) | | | 578 | | ip-prefix | | 3 text string | String | 579 | source-port-range | list | 0x8001 | 4 array | Array | 580 | | | (TBD2) | | | 581 | source-icmp-type- | list | 0x8002 | 4 array | Array | 582 | range | | (TBD3) | | | 583 | lower-type | uint8 | 0x8003 | 0 unsigned | Number | 584 | | | (TBD4) | | | 585 | upper-type | uint8 | 0x8004 | 0 unsigned | Number | 586 | | | (TBD5) | | | 587 +-------------------+------------+--------+---------------+--------+ 589 4.3. New DOTS Conflict Cause 591 This document requests IANA to assign a new code from the "DOTS 592 Conflict Cause Codes" registry: 594 +------+------------------+-----------------------------+-----------+ 595 | Code | Label | Description | Reference | 596 +------+------------------+-----------------------------+-----------+ 597 | 4 | request-rejected | Mitigation request | [RFCXXXX] | 598 | | | rejected. This code is | | 599 | | | returned by the DOTS server | | 600 | | | to indicate the attack | | 601 | | | traffic has been classified | | 602 | | | as legitimate traffic. | | 603 +------+------------------+-----------------------------+-----------+ 605 4.4. DOTS Signal Call Home YANG Module 607 This document requests IANA to register the following URI in the 608 "IETF XML Registry" [RFC3688]: 610 URI: urn:ietf:params:xml:ns:yang:ietf-dots-call-home 611 Registrant Contact: The IESG. 612 XML: N/A; the requested URI is an XML namespace. 614 This document requests IANA to register the following YANG module in 615 the "YANG Module Names" registry [RFC7950]. 617 Name: ietf-call-home 618 Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home 619 Maintained by IANA: N 620 Prefix: call-home 621 Reference: RFC XXXX 623 5. Security Considerations 625 This document deviates from classic DOTS signal channel usage by 626 having the DOTS server initiate the TCP/TLS or DTLS connection. DOTS 627 signal channel related security considerations discussed in 628 Section 10 of [I-D.ietf-dots-signal-channel] MUST be considered. 629 DOTS agents MUST authenticate each other using (D)TLS before a DOTS 630 signal channel session is considered valid. 632 An attacker may launch a DoS attack on the DOTS client by having it 633 perform computationally expensive operations, before deducing that 634 the attacker doesn't possess a valid key. For instance, in TLS 1.3 635 [RFC8446], the ServerHello message contains a Key Share value based 636 on an expensive asymmetric key operation for key establishment. 637 Common precautions mitigating DoS attacks are recommended, such as 638 temporarily blacklisting the source address after a set number of 639 unsuccessful authentication attempts. 641 DOTS servers may not blindly trust mitigation requests from DOTS 642 clients. For example, DOTS servers can use the attack flow 643 information in a mitigation request to enable full-fledged packet 644 inspection function to inspect all the traffic from the compromised 645 to the target or to re-direct the traffic from the compromised device 646 to the target to a DDoS mitigation system to scrub the suspicious 647 traffic. DOTS servers can also seek the consent of DOTS server 648 domain administrator to block the traffic from the compromised device 649 to the target (see Section 3.2.1). 651 6. Privacy Considerations 653 The considerations discussed in [RFC6973] were taken into account to 654 assess whether the DOTS Call Home extension introduces privacy 655 threats. 657 Concretely, the protocol does not leak any new information that can 658 be used to ease surveillance. In particular, the DOTS server is not 659 required to share information that is local to its network (e.g., 660 internal identifiers of an attack source) with the DOTS client. 662 The DOTS Call Home extension does not preclude the validation of 663 mitigation requests received from a DOTS client. For example, a 664 security service running on the CPE may require administrator's 665 consent before the CPE acts upon the mitigation request indicated by 666 the DOTS client. How the consent is obtained is out of scope of this 667 document. 669 Note that a DOTS server can seek for an administrator's consent, 670 validate the request by inspecting the traffic, or proceed with both. 672 The DOTS Call Home extension is only advisory in nature. Concretely, 673 the DOTS Call Home extension does not impose any action to be 674 enforced within the home network; it is up to the DOTS server (and/or 675 network administrator) to decide whether and which actions are 676 required. 678 Moreover, the DOTS Call Home extension avoids misattribution by 679 appropriately identifying the network to which a suspect attack 680 source belongs to (e.g., address sharing issues discussed in 681 Section 3.2.1). 683 Triggers to send a DOTS mitigation request to a DOTS server are 684 deployment-specific. For example, a DOTS client may rely on the 685 output of some DDoS detection systems deployed within the DOTS 686 client's network to detect potential outbound DDoS attacks or on 687 abuse claims received from remote victim networks. Such DDoS 688 detection and mitigation techniques are not meant to track the 689 activity of users, but to protect the Internet and avoid altering the 690 IP reputation of the DOTS client's domain. 692 7. Contributors 694 The following individuals have contributed to this document: 696 Joshi Harsha 697 McAfee, Inc. 698 Embassy Golf Link Business Park 699 Bangalore, Karnataka 560071 700 India 702 Email: harsha_joshi@mcafee.com 704 8. Acknowledgements 706 Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, and Toema 707 Gavrichenkov for the comments. 709 9. References 711 9.1. Normative References 713 [I-D.ietf-dots-signal-channel] 714 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 715 Teague, "Distributed Denial-of-Service Open Threat 716 Signaling (DOTS) Signal Channel Specification", draft- 717 ietf-dots-signal-channel-30 (work in progress), March 718 2019. 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, 722 DOI 10.17487/RFC2119, March 1997, 723 . 725 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 726 DOI 10.17487/RFC3688, January 2004, 727 . 729 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 730 RFC 7950, DOI 10.17487/RFC7950, August 2016, 731 . 733 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 734 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 735 May 2017, . 737 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 738 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 739 . 741 9.2. Informative References 743 [I-D.ietf-dots-multihoming] 744 Boucadair, M. and R. K, "Multi-homing Deployment 745 Considerations for Distributed-Denial-of-Service Open 746 Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01 747 (work in progress), January 2019. 749 [I-D.ietf-dots-requirements] 750 Mortensen, A., K, R., and R. Moskowitz, "Distributed 751 Denial of Service (DDoS) Open Threat Signaling 752 Requirements", draft-ietf-dots-requirements-22 (work in 753 progress), March 2019. 755 [I-D.ietf-dots-server-discovery] 756 Boucadair, M., K, R., and P. Patil, "Distributed-Denial- 757 of-Service Open Threat Signaling (DOTS) Server Discovery", 758 draft-ietf-dots-server-discovery-00 (work in progress), 759 March 2019. 761 [I-D.ietf-dots-use-cases] 762 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 763 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 764 Open Threat Signaling", draft-ietf-dots-use-cases-17 (work 765 in progress), January 2019. 767 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 768 Congestion Control Protocol (DCCP)", RFC 4340, 769 DOI 10.17487/RFC4340, March 2006, 770 . 772 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 773 (CIDR): The Internet Address Assignment and Aggregation 774 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 775 2006, . 777 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 778 Denial-of-Service Considerations", RFC 4732, 779 DOI 10.17487/RFC4732, December 2006, 780 . 782 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 783 RFC 4960, DOI 10.17487/RFC4960, September 2007, 784 . 786 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 787 and D. McPherson, "Dissemination of Flow Specification 788 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 789 . 791 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 792 Morris, J., Hansen, M., and R. Smith, "Privacy 793 Considerations for Internet Protocols", RFC 6973, 794 DOI 10.17487/RFC6973, July 2013, 795 . 797 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 798 Farrer, "Lightweight 4over6: An Extension to the Dual- 799 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 800 July 2015, . 802 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 803 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 804 Port with Encapsulation (MAP-E)", RFC 7597, 805 DOI 10.17487/RFC7597, July 2015, 806 . 808 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 809 RFC 8071, DOI 10.17487/RFC8071, February 2017, 810 . 812 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 813 Vinapamula, S., and Q. Wu, "A YANG Module for Network 814 Address Translation (NAT) and Network Prefix Translation 815 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 816 . 818 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 819 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 820 DOI 10.17487/RFC8513, January 2019, 821 . 823 Authors' Addresses 825 Tirumaleswar Reddy 826 McAfee, Inc. 827 Embassy Golf Link Business Park 828 Bangalore, Karnataka 560071 829 India 831 Email: kondtir@gmail.com 833 Mohamed Boucadair 834 Orange 835 Rennes 35000 836 France 838 Email: mohamed.boucadair@orange.com 840 Jon Shallow 841 UK 843 Email: supjps-ietf@jpshallow.com