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