idnits 2.17.1 draft-ietf-dots-signal-call-home-14.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFCXXXX]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1003 has weird spacing: '...er-port ine...' == Line 1006 has weird spacing: '...er-type uin...' -- The document date (May 26, 2021) is 1037 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 1294, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-dots-rfc8782-bis-06 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-13) exists of draft-ietf-dots-multihoming-05 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 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, Ed. 5 Expires: November 27, 2021 Orange 6 J. Shallow 7 May 26, 2021 9 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 10 Channel Call Home 11 draft-ietf-dots-signal-call-home-14 13 Abstract 15 This document specifies the DOTS signal channel Call Home, which 16 enables a Call Home DOTS server to initiate a secure connection to a 17 Call Home DOTS client, and to receive attack traffic information from 18 the Call Home DOTS client. The Call Home DOTS server in turn uses 19 the attack traffic information to identify compromised devices 20 launching outgoing DDoS attacks and take appropriate mitigation 21 action(s). 23 The DOTS signal channel Call Home is not specific to home networks; 24 the solution targets any deployment in which it is required to block 25 DDoS attack traffic closer to the source(s) of a DDoS attack. 27 Editorial Note (To be removed by RFC Editor) 29 Please update these statements within the document with the RFC 30 number to be assigned to this document: 32 o "This version of this YANG module is part of RFC XXXX;" 34 o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling 35 (DOTS) Signal Channel Call Home"; 37 o "| [RFCXXXX] |" 39 o reference: RFC XXXX 41 Please update this statement with the RFC number to be assigned to 42 the following documents: 44 o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling 45 (DOTS) Signal Channel Specification" (used to be I-D.ietf-dots- 46 rfc8782-bis) 48 Please update TBD/TBA statements with the assignments made by IANA to 49 DOTS Signal Channel Call Home. 51 Also, please update the "revision" date of the YANG module. 53 Status of This Memo 55 This Internet-Draft is submitted in full conformance with the 56 provisions of BCP 78 and BCP 79. 58 Internet-Drafts are working documents of the Internet Engineering 59 Task Force (IETF). Note that other groups may also distribute 60 working documents as Internet-Drafts. The list of current Internet- 61 Drafts is at https://datatracker.ietf.org/drafts/current/. 63 Internet-Drafts are draft documents valid for a maximum of six months 64 and may be updated, replaced, or obsoleted by other documents at any 65 time. It is inappropriate to use Internet-Drafts as reference 66 material or to cite them other than as "work in progress." 68 This Internet-Draft will expire on November 27, 2021. 70 Copyright Notice 72 Copyright (c) 2021 IETF Trust and the persons identified as the 73 document authors. All rights reserved. 75 This document is subject to BCP 78 and the IETF Trust's Legal 76 Provisions Relating to IETF Documents 77 (https://trustee.ietf.org/license-info) in effect on the date of 78 publication of this document. Please review these documents 79 carefully, as they describe your rights and restrictions with respect 80 to this document. Code Components extracted from this document must 81 include Simplified BSD License text as described in Section 4.e of 82 the Trust Legal Provisions and are provided without warranty as 83 described in the Simplified BSD License. 85 Table of Contents 87 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 88 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 89 3. Applicability Scope . . . . . . . . . . . . . . . . . . . . . 7 90 4. Co-existence of Base DOTS Signal Channel and DOTS Call Home . 8 91 5. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 12 92 5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 12 93 5.2. DOTS Signal Channel Variations . . . . . . . . . . . . . 14 94 5.2.1. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 14 95 5.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 15 97 5.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 16 98 5.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 16 99 5.3.2. Address Sharing Considerations . . . . . . . . . . . 20 100 6. DOTS Signal Call Home YANG Module . . . . . . . . . . . . . . 23 101 6.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 23 102 6.2. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . 24 103 6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 105 7.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 29 106 7.2. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 30 107 7.3. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 31 108 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 109 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33 110 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 111 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 113 12.1. Normative References . . . . . . . . . . . . . . . . . . 35 114 12.2. Informative References . . . . . . . . . . . . . . . . . 36 115 Appendix A. Some Home Network Issues . . . . . . . . . . . . . . 39 116 Appendix B. Disambiguating Base DOTS Signal vs. DOTS Call Home . 41 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 119 1. Introduction 121 The Distributed Denial-of-Service Open Threat Signaling (DOTS) signal 122 channel protocol [I-D.ietf-dots-rfc8782-bis] is used to carry 123 information about a network resource or a network (or a part thereof) 124 that is under a Distributed Denial of Service (DDoS) attack 125 [RFC4732]. Such information is sent by a DOTS client to one or 126 multiple DOTS servers so that appropriate mitigation actions are 127 undertaken on traffic deemed suspicious. Various use cases are 128 discussed in [I-D.ietf-dots-use-cases]. 130 However, [I-D.ietf-dots-rfc8782-bis] only covers how to mitigate when 131 being attacked (i.e., protect a network from inbound DDoS attacks). 132 It does not cover how to control the attacks close to their source(s) 133 that are misusing network resources (i.e., outbound DDoS attacks). 134 In particular, the DOTS signal protocol does not discuss cooperative 135 DDoS mitigation between the network hosting an attack source and the 136 Internet Service Provider (ISP) to suppress the outbound DDoS attack 137 traffic originating from that network. As a reminder, the base basic 138 DOTS architecture is depicted in Figure 1 (Section 2 of [RFC8811]). 140 +-----------+ +-------------+ 141 | Mitigator | ~~~~~~~~~~ | DOTS Server | 142 +-----------+ +-------------+ 143 | 144 | 145 | 146 +---------------+ +-------------+ 147 | Attack Target | ~~~~~~ | DOTS Client | 148 +---------------+ +-------------+ 150 Figure 1: Basic DOTS Architecture 152 Appendix A details why the rise of Internet of Things (IoT) compounds 153 the possibility of these being used as malicious actors which need to 154 be controlled. Similar issues can be encountered in enterprise 155 networks, data centers, etc. The ISP offering a DDoS mitigation 156 service can detect outgoing DDoS attack traffic originating from its 157 subscribers or the ISP may receive filtering rules (e.g., using BGP 158 Flowspec [RFC8955][RFC8956]) from a transit provider to filter, 159 block, or rate-limit DDoS attack traffic originating from the ISP's 160 subscribers to a downstream target. Nevertheless, the DOTS signal 161 channel does not provide means for the ISP to request blocking such 162 attacks close to the sources without altering legitimate traffic. 163 This document fills that void by specifying an extension to the DOTS 164 signal channel: DOTS signal channel Call Home. 166 Note: Another design approach would be to extend the DOTS signal 167 channel with a new attribute to explicitly indicate whether a 168 mitigation request is about an outbound DDoS attack. In such an 169 approach, it is assumed that a DOTS server is deployed within the 170 domain that is hosting the attack source(s), while a DOTS client 171 is enabled within an upstream network (e.g., access network). 172 However, initiating a DOTS signal channel from an upstream network 173 to a source network is complicated because of the presence of 174 translators and firewalls. Moreover, the use of the same signal 175 channel to handle both inbound and outbound attacks complicates 176 both the heartbeat and redirection mechanisms that are executed as 177 a function of the attack direction (see Sections 5.2.1 and 5.2.2). 178 Also, the DOTS server will be subject to fingerprinting (e.g., 179 using scanning tools) and DoS attacks (e.g., by having the DOTS 180 server to perform computationally expensive operations). Various 181 management and deployment considerations that motivate the Call 182 Home functionality are listed in Section 1.1 of [RFC8071]. 184 'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers 185 to a DOTS signal channel established at the initiative of a DOTS 186 server thanks to a role reversal at the (D)TLS layer (Section 5.1). 187 That is, the DOTS server initiates a secure connection to a DOTS 188 client, and uses that connection to receive the attack traffic 189 information (e.g., attack sources) from the DOTS client. 191 A high-level DOTS Call Home functional architecture is shown in 192 Figure 2. Attack source(s) are within the DOTS server domain. 194 Scope 195 +.-.-.-.-.-.-.-.-.-.-.-.+ 196 +---------------+ : +-------------+ : 197 | Alert | ~~~:~~~ | Call Home | : 198 | | : | DOTS client | : 199 +---------------+ : +------+------+ : 200 : | : 201 : | : 202 : | : 203 +---------------+ : +------+------+ : 204 | Attack | ~~~:~~~ | Call Home | : 205 | Source(s) | : | DOTS server | : 206 +---------------+ : +-------------+ : 207 +.-.-.-.-.-.-.-.-.-.-.-.+ 209 Figure 2: Basic DOTS Signal Channel Call Home Functional Architecture 211 DOTS agents involved in the DOTS Call Home otherwise adhere to the 212 DOTS roles as defined in [RFC8612]. For clarity, this document uses 213 "Call Home DOTS client" (or "Call Home DOTS server") to refer to a 214 DOTS client (or DOTS server) deployed in a Call Home scenario 215 (Figure 2). DOTS Call Home agents may (or not) be co-located with 216 DOTS agents that are compliant with [I-D.ietf-dots-rfc8782-bis] (see 217 Section 4 for more details). 219 A Call Home DOTS client relies upon a variety of triggers to make use 220 of the Call Home function (e.g., scrubbing the traffic from the 221 attack source, receiving an alert from an attack target, a peer DDoS 222 Mitigation System (DMS), or a transit provider). The definition of 223 these triggers is deployment-specific. It is therefore out of the 224 scope of this document to elaborate on how these triggers are made 225 available to a Call Home DOTS client. 227 In a typical deployment scenario, the Call Home DOTS server is 228 enabled on a Customer Premises Equipment (CPE), which is aligned with 229 recent trends to enrich the CPE with advanced security features. For 230 example, the DOTS Call Home service can be part of services supported 231 by an ISP-managed CPE or a managed security service subscribed by the 232 user. Unlike classic DOTS deployments [I-D.ietf-dots-use-cases], a 233 Call Home DOTS server maintains a single DOTS signal channel session 234 for each DOTS-capable upstream provisioning domain 235 [I-D.ietf-dots-multihoming]. 237 For instance, the Call Home DOTS server in the home network initiates 238 the signal channel Call Home in 'idle' time and then subsequently the 239 Call Home DOTS client in the ISP environment can initiate a 240 mitigation request whenever the ISP detects there is an attack from a 241 compromised device in the DOTS server domain (i.e., from within the 242 home network). 244 The Call Home DOTS server uses the DDoS attack traffic information to 245 identify the compromised device in its domain that is responsible for 246 launching the DDoS attack, optionally notifies a network 247 administrator, and takes appropriate mitigation action(s). For 248 example, a mitigation action can be to quarantine the compromised 249 device or block its traffic to the attack target(s) until the 250 mitigation request is withdrawn. 252 This document assumes that Call Home DOTS servers are provisioned 253 with a way to know how to reach the upstream Call Home DOTS 254 client(s), which could occur by a variety of means (e.g., [RFC8973]). 255 The specification of such means are out of scope of this document. 257 More information about the applicability scope of the DOTS signal 258 channel Call Home is provided in Section 3. 260 2. Terminology 262 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 263 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 264 "OPTIONAL" in this document are to be interpreted as described in BCP 265 14 [RFC2119][RFC8174] when, and only when, they appear in all 266 capitals, as shown here. 268 The reader should be familiar with the terms defined in Section 1.2 269 of [RFC8612]. 271 DDoS Mitigation System (DMS) refers to a system that performs DDoS 272 mitigation. 274 'Base DOTS signal channel' refers to [I-D.ietf-dots-rfc8782-bis]. 276 The meaning of the symbols in YANG tree diagrams are defined in 277 [RFC8340] and [RFC8791]. 279 (D)TLS is used for statements that apply to both Transport Layer 280 Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS) 281 [RFC6347]. Specific terms are used for any statement that applies to 282 either protocol alone. 284 3. Applicability Scope 286 The problems discussed in Section 1 may be encountered in many 287 deployments (e.g., home networks, enterprise networks, transit 288 networks, data centers). The solution specified in this document can 289 be used for those deployments to block DDoS attack traffic closer to 290 the source(s) of the attack. That is, attacks that are issued, e.g., 291 from within an enterprise network or a data center, will thus be 292 blocked before exiting these networks. 294 An instantiation of the Call Home functional architecture is depicted 295 in Figure 3. 297 +-------------+ 298 |Attack Target| 299 +-----+-------+ 300 | /\ Target Network 301 ......................|.||.................... 302 .--------+-||-------. 303 ( || )-. 304 .' || ' 305 ( Internet || ) 306 ( || -' 307 '-( || ) 308 '------+-||---------' 309 ......................|.||..................... 310 .--------+-||-------. Network 311 ( || )-. Provider 312 .' Call Home || ' (DMS) 313 ( DOTS client || ) 314 ( || -' 315 '-( || ) 316 '------+-||---------' 317 ......................|.||....................... 318 .--------+-||-------. Source Network 319 ( || )-. 320 .' Call Home || ' 321 ( DOTS server || Outbound ) 322 ( || DDoS -' 323 '-( || Attack ) 324 '------+-||---------' 325 | || 326 +-----+-++----+ 327 |Attack Source| 328 +-------------+ 330 Figure 3: DOTS Signal Channel Call Home Reference Architecture 332 It is out of the scope of this document to identify an exhaustive 333 list of such deployments. 335 Call Home DOTS agent relationships are similar to those discussed in 336 Section 2.3 of [RFC8811]. For example, multiple Call Home DOTS 337 servers of the same domain can be associated with the same Call Home 338 DOTS client. A Call Home DOTS client may decide to contact these 339 Call Home DOTS servers sequentially, fork a mitigation request to all 340 of them, or select one Call Home DOTS server to place a mitigation 341 request. Such decision is implementation-specific. 343 For some mitigations, a feedback may be required from an 344 administrator to confirm a filtering action. Means to seek for an 345 administrator's consent are deployment-specific. Indeed, a variety 346 of implementation options can be considered as a function of the Call 347 Home DOTS deployment: push notifications using a dedicated 348 application, Syslog, etc. It is out of the scope of this document to 349 make recommendations about how such interactions are implemented (see 350 Figure 2). 352 The Call Home DOTS server can be enabled on a border router or a 353 dedicated appliance. For the particular case of home networks, the 354 Call Home DOTS server functionality can be enabled on a managed CPE 355 or be bundled with a CPE management application that is provided by 356 an ISP to its subscribers. These managed services are likely to be 357 designed to hide the complexity of managing (including configuring) 358 the CPE. For example, managed CPEs support means to notify the user 359 when a new device is detected in order to seek a confirmation whether 360 access should be granted or not to the device. These means can be 361 upgraded to interface with the Call Home DOTS server. Customized 362 settings can be configured by users to control the notifications 363 (e.g., triggers, type) and default actions. 365 4. Co-existence of Base DOTS Signal Channel and DOTS Call Home 367 The DOTS signal channel Call Home does not require nor preclude the 368 activation of the base DOTS signal channel 369 [I-D.ietf-dots-rfc8782-bis]. Some sample deployment schemes are 370 discussed in this section for illustration purposes. 372 The network that hosts an attack source may also be subject to 373 inbound DDoS attacks. In that case, both the base DOTS signal 374 channel and DOTS signal channel Call Home may be enabled as shown in 375 Figure 4 (Same DMS provider) or Figure 5 (Distinct DMS providers). 377 DOTS Signal Channel Base DOTS 378 Call Home Signal Channel 379 +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ 380 : +------+ :: +------+ : 381 : | DOTS | :: | DOTS | : 382 : |client| :: |server| : 383 : +--+---+ :: +---+--+ : 384 : /\ | :: | : Network 385 : || | :: | :Provider 386 : || | :: | : (DMS) 387 ...:.....||......|.....::.....|.............:........ 388 Outbound || | :: | || Inbound 389 DDoS || | :: | || DDoS 390 Attack || | :: | \/ Attack 391 : +--+---+ :: +---+--+ : 392 : | DOTS | :: | DOTS | : 393 : |server| :: |client| : 394 : +------+ :: +------+ : 395 +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ 396 Network #A 398 Figure 4: Activation of Base DOTS Signal Channel and Call Home (Same 399 DMS Provider) 401 Note that a DMS provider may not be on the default forwarding path of 402 an inbound DDoS attack traffic targeting a network (e.g., Network #B 403 in Figure 5). Nevertheless, the DOTS signal channel Call Home 404 requires the DMS provider to be on the default forwarding path of the 405 outbound traffic from a given network. 407 DOTS Signal Channel Base DOTS 408 Call Home Signal Channel 409 +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ 410 : Network +------+ :: +------+ Third : 411 : Provider | DOTS | :: | DOTS | Party : 412 : (DMS) |client| :: |server| DMS : 413 : +--+---+ :: +---+--+ Provider : 414 : /\ | :: | : 415 : || | :: | : 416 : || | :: | : 417 ...:.....||......|.....::.....|.............:........ 418 Outbound || | :: | || Inbound 419 DDoS || | :: | || DDoS 420 Attack || | :: | \/ Attack 421 : +--+---+ :: +---+--+ : 422 : | DOTS | :: | DOTS | : 423 : |server| :: |client| : 424 : +------+ :: +------+ : 425 +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ 426 Network #B 428 Figure 5: Activation of Base DOTS Signal Channel and Call Home 429 (Distinct DMS Providers) 431 Figures 6 and 7 depict examples where the same node embeds both base 432 DOTS and DOTS Call Home agents. For example, a DOTS server and a 433 Call Home DOTS client may be enabled on the same device within the 434 infrastructure of a DMS provider (e.g., Node #i in Figure 6) or a 435 DOTS client and a Call Home DOTS server may be enabled on the same 436 device within a source network (e.g., Node #j with Network #D shown 437 in Figure 7) . 439 Whether the same or distinct nodes are used to host base DOTS and 440 DOTS Call Home agents is specific to each domain. 442 DOTS Signal Channel Base DOTS 443 Call Home Signal Channel 444 +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ 445 : +----------------------+ : 446 : | Node #i | : 447 : | +------+ +------+ | : 448 : | | DOTS | | DOTS | | : 449 : | |client| |server| | : 450 : | +--+---+ +---+--+ | : 451 : +----|-----::-----|----+ : Network 452 : /\ | :: | :Provider 453 : || | :: | : (DMS) 454 ...:.....||......|.....::.....|.............:........ 455 Outbound || | :: | || Inbound 456 DDoS || | :: | || DDoS 457 Attack || | :: | \/ Attack 458 : +--+---+ :: +---+--+ : 459 : | DOTS | :: | DOTS | : 460 : |server| :: |client| : 461 : +------+ :: +------+ : 462 +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ 463 Network #C 465 Figure 6: An Example of the Same Node Embedding both a Call Home DOTS 466 Client and a DOTS Server at the Network Provider's Side 467 DOTS Signal Channel Base DOTS 468 Call Home Signal Channel 469 +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ 470 : +----------------------+ : 471 : | Node #k | : 472 : | +------+ +------+ | : 473 : | | DOTS | | DOTS | | : 474 : | |client| |server| | : 475 : | +--+---+ +---+--+ | : 476 : +----|-----::-----|----+ : Network 477 : /\ | :: | :Provider 478 : || | :: | : (DMS) 479 ...:.....||......|.....::.....|.............:........ 480 Outbound || | :: | || Inbound 481 DDoS || | :: | || DDoS 482 Attack || | :: | \/ Attack 483 : +----|-----::-----|----+ : 484 : | +--+---+ +---+--+ | : 485 : | | DOTS | | DOTS | | : 486 : | |server| |client| | : 487 : | +------+ +------+ | : 488 : | Node #j | : 489 : +----------------------+ : 490 +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ 491 Network #D 493 Figure 7: Another Example where the Same Node Embeds both a DOTS 494 Client and a Call Home DOTS Server 496 Appendix B elaborates on the considerations to unambiguously 497 distinguish DOTS messages which belong to each of these channels. 499 5. DOTS Signal Channel Call Home 501 5.1. Procedure 503 The DOTS signal channel Call Home preserves all but one of the DOTS 504 client/server roles in the DOTS protocol stack, as compared to DOTS 505 client-initiated DOTS signal channel protocol 506 [I-D.ietf-dots-rfc8782-bis]. The role reversal that occurs is at the 507 (D)TLS layer; that is, (1) the Call Home DOTS server acts as a DTLS 508 client and the Call Home DOTS client acts as a DTLS server or (2) the 509 Call Home DOTS server acts as a TLS client initiating the underlying 510 TCP connection and the Call Home DOTS client acts as a TLS server. 511 The Call Home DOTS server initiates (D)TLS handshake to the Call Home 512 DOTS client. 514 For example, a home network element (e.g., home router) co-located 515 with a Call Home DOTS server is the (D)TLS client. That is, the Call 516 Home DOTS server assumes the role of the (D)TLS client, but the 517 network element's role as a DOTS server remains the same. 519 Existing certificate chains and mutual authentication mechanisms 520 between the DOTS agents are unaffected by the Call Home function. 521 From a deployment standpoint, and given the scale of Call Home DOTS 522 servers that may be involved, enabling means for automating the 523 provisioning of credentials on Call Home DOTS servers to authenticate 524 to the Call Home DOTS client is encouraged. It is out of the scope 525 of this document to elaborate on these means. 527 Figure 8 illustrates a sample DOTS Call Home flow exchange: 529 +-----------+ +-----------+ 530 | Call Home | | Call Home | 531 | DOTS | | DOTS | 532 | server | | client | 533 +-----+-----+ +-----+-----+ 534 (D)TLS client (D)TLS server 535 | | 536 | 1. (D)TLS connection | 537 |----------------------------------->| 538 | 2. Mitigation request | 539 |<-----------------------------------| 540 | ... | 542 Figure 8: DOTS Signal Channel Call Home Sequence Diagram 544 The DOTS signal channel Call Home procedure is as follows: 546 1. If UDP transport is used, the Call Home DOTS server begins by 547 initiating a DTLS connection to the Call Home DOTS client. 549 If TCP is used, the Call Home DOTS server begins by initiating a 550 TCP connection to the Call Home DOTS client. Once connected, the 551 Call Home DOTS server continues to initiate a TLS connection to 552 the Call Home DOTS client. 554 Peer DOTS agents may have mutual agreement to use a specific port 555 number, such as by explicit configuration or dynamic discovery 556 [RFC8973]. The interaction between the base DOTS signal channel 557 and the Call Home is discussed in Appendix B. 559 The Happy Eyeballs mechanism explained in Section 4.3 of 560 [I-D.ietf-dots-rfc8782-bis] is used for initiating (D)TLS 561 connections. 563 2. Using this (D)TLS connection, the Call Home DOTS client may 564 request, withdraw, or retrieve the status of mitigation requests. 565 The Call Home DOTS client supplies the source information by 566 means of new attributes defined in Section 5.3.1. 568 The Heartbeat mechanism used for the DOTS Call Home deviates from 569 the one defined in Section 4.7 of [I-D.ietf-dots-rfc8782-bis]. 570 Section 5.2.1 specifies the behavior to be followed by Call Home 571 DOTS agents. 573 5.2. DOTS Signal Channel Variations 575 5.2.1. Heartbeat Mechanism 577 Once the (D)TLS section is established between the DOTS agents, the 578 Call Home DOTS client contacts the Call Home DOTS server to retrieve 579 the session configuration parameters (Section 4.5 of 580 [I-D.ietf-dots-rfc8782-bis]). The Call Home DOTS server adjusts the 581 'heartbeat-interval' to accommodate binding timers used by on-path 582 NATs and firewalls. Heartbeats will be then exchanged by the DOTS 583 agents following the instructions retrieved using the signal channel 584 session configuration exchange. 586 It is the responsibility of Call Home DOTS servers to ensure that on- 587 path translators/firewalls are maintaining a binding so that the same 588 external IP address and/or port number is retained for the DOTS 589 signal channel session. A Call Home DOTS client MAY trigger their 590 heartbeat requests immediately after receiving heartbeat probes from 591 its peer Call Home DOTS server. 593 When an outgoing attack that saturates the outgoing link from the 594 Call Home DOTS server is detected and reported by a Call Home DOTS 595 client, the latter MUST continue to use the DOTS signal channel even 596 if no traffic is received from the Call Home DOTS server. 598 If the Call Home DOTS server receives traffic from the Call Home DOTS 599 client, the Call Home DOTS server MUST continue to use the DOTS 600 signal channel even if the missing heartbeats allowed threshold 601 ('missing-hb-allowed') is reached. 603 If the Call Home DOTS server does not receive any traffic from the 604 peer Call Home DOTS client during the time span required to exhaust 605 the maximum 'missing-hb-allowed' threshold, the Call Home DOTS server 606 concludes the session is disconnected. Then, the Call Home DOTS 607 server MUST try to establish a new DOTS signal channel session, 608 preferably by resuming the (D)TLS session. 610 5.2.2. Redirected Signaling 612 A Call Home DOTS server MUST NOT support the Redirected Signaling 613 mechanism as specified in Section 4.6 of [I-D.ietf-dots-rfc8782-bis] 614 (i.e., a 5.03 response that conveys an alternate DOTS server's FQDN 615 or alternate DOTS server's IP address(es)). A Call Home DOTS client 616 MUST silently discard such message as only a Call Home DOTS server 617 can initiate a new (D)TLS connection. 619 If a Call Home DOTS client wants to redirect a Call Home DOTS server 620 to another Call Home DOTS client, it MUST send a Non-confirmable PUT 621 request to the predefined resource ".well-known/dots/redirect" with 622 the following attributes in the body of the PUT request: 624 alt-ch-client: The FQDN of an alternate Call Home DOTS client. It 625 is also presented as reference identifier for authentication 626 purposes. 628 This is a mandatory attribute for DOTS signal Call Home. It MUST 629 NOT be used for base DOTS signal channel operations. 631 alt-ch-client-record: List of IP addresses for the alternate Call 632 Home DOTS client. If no 'alt-ch-client-record' is provided, the 633 Call Home DOTS server passes the 'alt-ch-client' name to a name 634 resolution library to retrieve one or more IP addresses of the 635 alternate Call Home DOTS client. 637 This is an optional attribute for DOTS signal Call Home. It MUST 638 NOT be used for base DOTS signal channel operations. 640 ttl: The Time to live (TTL) of the alternate Call Home DOTS client. 641 That is, the time interval that the alternate Call Home DOTS 642 client may be cached for use by a Call Home DOTS server. 644 This is an optional attribute for DOTS signal Call Home. It MUST 645 NOT be used for base DOTS signal channel operations. 647 On receipt of this PUT request, the Call Home DOTS server responds 648 with a 2.01 (Created), closes this connection and establishes a 649 connection with the new Call Home DOTS client. The processing of the 650 TTL is defined in Section 4.6 of [I-D.ietf-dots-rfc8782-bis]. If the 651 Call Home DOTS server cannot service the PUT request, the response is 652 rejected with a 4.00 (Bad Request). 654 Figure 9 shows a PUT request example to convey the alternate Call 655 Home DOTS client 'alt-call-home-client.example' together with its IP 656 addresses 2001:db8:6401::1 and 2001:db8:6401::2. The validity of 657 this alternate Call Home DOTS client is 10 minutes. 659 Header: PUT (Code=0.03) 660 Uri-Path: ".well-known" 661 Uri-Path: "dots" 662 Uri-Path: "redirect" 663 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 664 Uri-Path: "mid=123" 665 Content-Format: "application/dots+cbor" 667 { 668 "ietf-dots-signal-channel:redirected-signal": { 669 "ietf-dots-call-home:alt-ch-client": 670 "alt-call-home-client.example", 671 "ietf-dots-call-home:alt-ch-client-record": [ 672 "2001:db8:6401::1", 673 "2001:db8:6401::2" 674 ], 675 "ietf-dots-call-home:ttl": 600 676 } 678 Figure 9: Example of a PUT Request for Redirected Signaling 680 5.3. DOTS Signal Channel Extension 682 5.3.1. Mitigation Request 684 This specification extends the mitigation request defined in 685 Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis] to convey the attack 686 source information (e.g., source prefixes, source port numbers). The 687 DOTS client conveys the following new parameters in the CBOR body of 688 the mitigation request: 690 source-prefix: A list of attacker IP prefixes used to attack the 691 target. Prefixes are represented using Classless Inter-Domain 692 Routing (CIDR) notation BCP 122 [RFC4632]. 694 As a reminder, the prefix length MUST be less than or equal to 32 695 (or 128) for IPv4 (or IPv6). 697 The prefix list MUST NOT include broadcast, loopback, or multicast 698 addresses. These addresses are considered as invalid values. 699 Note that link-local addresses are allowed. The Call Home DOTS 700 client MUST validate that attacker prefixes are within the scope 701 of the Call Home DOTS server domain (e.g., prefixes assigned to 702 the Call Home DOTS server domain or networks it services). This 703 check is meant to avoid contacting Call Home DOTS servers that are 704 not entitled to enforce actions on specific prefixes. 706 This is an optional attribute for the base DOTS signal channel 707 operations. 709 source-port-range: A list of port numbers used by the attack traffic 710 flows. 712 A port range is defined by two bounds, a lower port number (lower- 713 port) and an upper port number (upper-port). When only 'lower- 714 port' is present, it represents a single port number. 716 For TCP, UDP, Stream Control Transmission Protocol (SCTP) 717 [RFC4960], or Datagram Congestion Control Protocol (DCCP) 718 [RFC4340], a range of ports can be any subrange of 0-65535, for 719 example, 0-1023, 1024-65535, or 1024-49151. 721 This is an optional attribute for the base DOTS signal channel 722 operations. 724 source-icmp-type-range: A list of ICMP types used by the attack 725 traffic flows. An ICMP type range is defined by two bounds, a 726 lower ICMP type (lower-type) and an upper ICMP type (upper-type). 727 When only 'lower-type' is present, it represents a single ICMP 728 type. Both ICMP [RFC0792] and ICMPv6 [RFC4443] types are 729 supported. Whether ICMP or ICMPv6 types are to be used is 730 determined by the address family of the 'target-prefix'. 732 This is an optional attribute for the base DOTS signal channel 733 operations. 735 The 'source-prefix' parameter is a mandatory attribute when the 736 attack traffic information is signaled by a Call Home DOTS client 737 (i.e., the Call Home scenario depicted in Figure 8). The 'target- 738 prefix' attribute MUST be included in the mitigation request 739 signaling the attack information to a Call Home DOTS server. The 740 'target-uri' or 'target-fqdn' parameters can be included in a 741 mitigation request for diagnostic purposes to notify the Call Home 742 DOTS server domain administrator, but SHOULD NOT be used to determine 743 the target IP addresses. 'alias-name' is unlikely to be conveyed in 744 a Call Home mitigation request given that a target may be any IP 745 resource and that there is no incentive for a Call Home DOTS server 746 (embedded, for example, in a CPE) to maintain aliases. 748 In order to help attack source identification by a Call Home DOTS 749 server, the Call Home DOTS client SHOULD include in its mitigation 750 request additional information such as 'source-port-range' or 751 'source-icmp-type-range' to disambiguate nodes sharing the same 752 'source-prefix'. IPv6 addresses/prefixes are sufficient to uniquely 753 identify a network endpoint, without need for port numbers or ICMP 754 type information. While this is also possible for IPv4, it is much 755 less often the case than for IPv6. More address sharing implications 756 on the setting of source information ('source-prefix', 'source-port- 757 range') are discussed in Section 5.3.2. 759 Only immediate mitigation requests (i.e., 'trigger-mitigation' set to 760 'true') are allowed; Call Home DOTS clients MUST NOT send requests 761 with 'trigger-mitigation' set to 'false'. Such requests MUST be 762 discarded by the Call Home DOTS server with a 4.00 (Bad Request). 764 An example of a mitigation request sent by a Call Home DOTS client is 765 shown in Figure 10. 767 Header: PUT (Code=0.03) 768 Uri-Path: ".well-known" 769 Uri-Path: "dots" 770 Uri-Path: "mitigate" 771 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 772 Uri-Path: "mid=56" 773 Content-Format: "application/dots+cbor" 775 { 776 "ietf-dots-signal-channel:mitigation-scope": { 777 "scope": [ 778 { 779 "target-prefix": [ 780 "2001:db8:c000::/128" 781 ], 782 "ietf-dots-call-home:source-prefix": [ 783 "2001:db8:123::1/128" 784 ], 785 "lifetime": 3600 786 } 787 ] 788 } 789 } 791 Figure 10: An Example of Mitigation Request Issued by a Call Home 792 DOTS Client 794 The Call Home DOTS server MUST check that the 'source-prefix' is 795 within the scope of the Call Home DOTS server domain. Note that in a 796 DOTS Call Home scenario, the Call Home DOTS server considers, by 797 default, that any routeable IP prefix enclosed in 'target-prefix' is 798 within the scope of the Call Home DOTS client. Invalid mitigation 799 requests are handled as per Section 4.4.1 of 800 [I-D.ietf-dots-rfc8782-bis]. 802 Note: These validation checks do not apply when the source 803 information is included as a hint in the context of the base DOTS 804 signal channel. 806 The Call Home DOTS server domain administrator consent MAY be 807 required to block the traffic from the compromised device to the 808 attack target. An implementation MAY have a configuration knob to 809 block the traffic from the compromised device to the attack target 810 with or without DOTS server domain administrator consent. 812 If a consent from the Call Home DOTS server domain administrator is 813 required, the Call Home DOTS server replies with 2.01 (Created) and 814 'status' code set to 1 (attack-mitigation-in-progress). Then, the 815 mechanisms defined in Section 4.4.2 of [I-D.ietf-dots-rfc8782-bis] 816 are followed by the DOTS agents to update the mitigation status. 817 Particularly, if the attack traffic is blocked, the Call Home DOTS 818 server informs the Call Home DOTS client that the attack is being 819 mitigated (i.e., by setting the 'status' code to 2 (attack- 820 successfully-mitigated)). 822 If the attack traffic information is identified by the Call Home DOTS 823 server or the Call Home DOTS server domain administrator as 824 legitimate traffic, the mitigation request is rejected with a 4.09 825 (Conflict) (e.g., when no consent is required from an administrator) 826 or a notification message with the 'conflict-clause' (Section 4.4.1 827 of [I-D.ietf-dots-rfc8782-bis]) set to the following new value: 829 4: Mitigation request rejected. This code is returned by the DOTS 830 server to indicate the attack traffic has been classified as 831 legitimate traffic. 833 Once the request is validated by the Call Home DOTS server, 834 appropriate actions are enforced to block the attack traffic within 835 the source network. For example, if the Call Home DOTS server is 836 embedded in a CPE, it can program the packet processor to punt all 837 the traffic from the compromised device to the target to slow path. 838 The CPE inspects the punted slow path traffic to detect and block the 839 outgoing DDoS attack traffic or quarantine the device (e.g., using 840 MAC level filtering) until it is remediated, and notifies the CPE 841 administrator about the compromised device. Note that the Call Home 842 DOTS client is informed about the progress of the attack mitigation 843 following the rules in Section 4.4.2 of [I-D.ietf-dots-rfc8782-bis]. 845 The DOTS agents follow the same procedures specified in 846 [I-D.ietf-dots-rfc8782-bis] for managing a mitigation request. 848 5.3.2. Address Sharing Considerations 850 Figure 11 depicts an example of a network provider that hosts a Call 851 Home DOTS client and deploys a Carrier Grade NAT (CGN) between the 852 DOTS client domain and DOTS server domain. In such cases, 853 communicating an external IP address in a mitigation request by a 854 Call Home DOTS client is likely to be discarded by the Call Home DOTS 855 server because the external IP address is not visible locally to the 856 Call Home DOTS server (Figure 11). The Call Home DOTS server is only 857 aware of the internal IP addresses/prefixes bound to its domain 858 (i.e., those used in the Internal Realm shown in Figure 11). Thus, 859 Call Home DOTS clients that are aware of the presence of on-path CGNs 860 MUST NOT include the external IP address and/or port number 861 identifying the suspect attack source (i.e., those used in the 862 External Realm shown in Figure 11), but MUST include the internal IP 863 address and/or port number. To that aim, the Call Home DOTS client 864 SHOULD rely on mechanisms, such as [RFC8512] or [RFC8513], to 865 retrieve the internal IP address and port number which are mapped to 866 an external IP address and port number. For the particular case of 867 NAT64 [RFC6146], if the target address is an IPv4 address, the 868 IPv4-converted IPv6 address of this target address [RFC6052] SHOULD 869 be used. 871 N | .-------------------. 872 E | ( )-. 873 T | .' ' 874 W | ( Call Home ) 875 O | ( DOTS client -' 876 R | '-( ) 877 K | '-------+-----------' 878 | | 879 P | | 880 R | +---+---+ 881 O | | CGN | External Realm 882 V |..............| |...................... 883 I | | | Internal Realm 884 D | +---+---+ 885 E | | 886 R | | 887 --- | 888 .---------+---------. 889 ( )-. 890 .' Source Network ' 891 ( ) 892 ( Call Home -' 893 '-( DOTS server ) 894 '------+------------' 895 | 896 +-----+-------+ 897 |Attack Source| 898 +-------------+ 900 Figure 11: Example of a CGN between DOTS Domains 902 If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the 903 provider's domain to service its customers, the identification of an 904 attack source bound to an IPv4 address/prefix MUST also rely on 905 source port numbers because the same IPv4 address is assigned to 906 multiple customers. The port information is required to 907 unambiguously identify the source of an attack. 909 If a translator is enabled on the boundaries of the domain hosting 910 the Call Home DOTS server (e.g., a CPE with NAT enabled as shown in 911 Figures 12 and 13), the Call Home DOTS server uses the attack traffic 912 information conveyed in a mitigation request to find the internal 913 source IP address of the compromised device and blocks the traffic 914 from the compromised device traffic to the attack target until the 915 mitigation request is withdrawn. The Call Home DOTS server proceeds 916 with a NAT mapping table lookup using the attack information (or a 917 subset thereof) as a key. The lookup can be local (Figure 12) or via 918 a dedicated administration interface that is offered by the CPE 919 (Figure 13). This identification allows the suspicious device to be 920 isolated while avoiding disturbances of other services. 922 .-------------------. 923 ( )-. 924 .' Network Provider (DMS)' 925 ( ) 926 ( Call Home -' 927 '-( DOTS client ) 928 '-------+-----------' 929 | 930 --- +---+---+ 931 S | | CPE | External Realm 932 O |..............| |................ 933 U | | NAT | Internal Realm 934 R | +---+---+ 935 C | | 936 E | .---------+---------. 937 | ( )-. 938 N | .' ' 939 E | ( Call Home ) 940 T | ( DOTS server -' 941 W | '-( ) 942 O | '-------+-----------' 943 R | | 944 K | +------+------+ 945 | |Attack Source| 946 +-------------+ 948 Figure 12: Example of a DOTS Server Domain with a NAT Embedded in a 949 CPE 951 .-------------------. 952 ( )-. 953 .' Network Provider (DMS) ' 954 ( ) 955 ( Call Home -' 956 '-( DOTS client ) 957 '---------+---------' 958 | 959 --- +-----+-----+ 960 S | | CPE/NAT | External Realm 961 O |..............| |................ 962 U | | Call Home | Internal Realm 963 R | |DOTS server| 964 C | +-----+-----+ 965 E | | 966 | .-----------+-------. 967 | ( )-. 968 N | .' ' 969 E | ( Local Area Network ) 970 T | ( -' 971 W | '-( ) 972 O | '--------+----------' 973 R | | 974 K | +------+------+ 975 | |Attack Source| 976 +-------------+ 978 Figure 13: Example of a Call Home DOTS Server and a NAT Embedded in a 979 CPE 981 If for any reason address sharing is deployed in both source and 982 provider networks, both Call Home DOTS agents have to proceed with 983 address mapping lookups following the behavior specified in reference 984 to Figure 11 (network provider) and Figures 12 and 13 (source 985 network). 987 6. DOTS Signal Call Home YANG Module 989 6.1. Tree Structure 991 This document augments the "ietf-dots-signal-channel" (dots-signal) 992 DOTS signal YANG module defined in [I-D.ietf-dots-rfc8782-bis] for 993 signaling the attack traffic information. This document defines the 994 YANG module "ietf-dots-call-home", which has the following tree 995 structure: 997 module: ietf-dots-call-home 999 augment-structure /dots-signal:dots-signal/dots-signal:message-type 1000 /dots-signal:mitigation-scope/dots-signal:scope: 1001 +-- source-prefix* inet:ip-prefix 1002 +-- source-port-range* [lower-port] 1003 | +-- lower-port inet:port-number 1004 | +-- upper-port? inet:port-number 1005 +-- source-icmp-type-range* [lower-type] 1006 +-- lower-type uint8 1007 +-- upper-type? uint8 1008 augment-structure /dots-signal:dots-signal/dots-signal:message-type 1009 /dots-signal:redirected-signal: 1010 +-- (type)? 1011 +--:(call-home-only) 1012 +-- alt-ch-client inet:domain-name 1013 +-- alt-ch-client-record* inet:ip-address 1014 +-- ttl? uint32 1016 6.2. YANG/JSON Mapping Parameters to CBOR 1018 The YANG/JSON mapping parameters to CBOR are listed in Table 1. 1020 o Note: Implementers must check that the mapping output provided by 1021 their YANG-to-CBOR encoding schemes is aligned with the content of 1022 Table 1. 1024 +--------------------+------------+------+---------------+--------+ 1025 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 1026 | | Type | Key | Type & | Type | 1027 | | | | Information | | 1028 +====================+============+======+===============+========+ 1029 |ietf-dots-call-home:| leaf-list | | | | 1030 | source-prefix | inet: | TBA1 | 4 array | Array | 1031 | | ip-prefix | | 3 text string | String | 1032 +--------------------+------------+------+---------------+--------+ 1033 |ietf-dots-call-home:| | | | | 1034 | source-port-range | list | TBA2 | 4 array | Array | 1035 +--------------------+------------+------+---------------+--------+ 1036 |ietf-dots-call-home:| | | | | 1037 | source-icmp-type- | list | TBA3 | 4 array | Array | 1038 | range | | | | | 1039 +--------------------+------------+------+---------------+--------+ 1040 | lower-type | uint8 | TBA4 | 0 unsigned | Number | 1041 +--------------------+------------+------+---------------+--------+ 1042 | upper-type | uint8 | TBA5 | 0 unsigned | Number | 1043 +--------------------+------------+------+---------------+--------+ 1044 |ietf-dots-call-home:| inet: | | | | 1045 | alt-ch-client | domain-name| TBA6 | 3 text string | String | 1046 +--------------------+------------+------+---------------+--------+ 1047 |ietf-dots-call-home:| leaf-list | TBA7 | 4 array | Array | 1048 | alt-ch-client- | inet: | | | | 1049 | record | ip-address| | 3 text string | String | 1050 +--------------------+------------+------+---------------+--------+ 1051 |ietf-dots-call-home:| | | | | 1052 | ttl | uint32 | TBA8 | 0 unsigned | Number | 1053 +--------------------+------------+------+---------------+--------+ 1055 Table 1: YANG/JSON Mapping Parameters to CBOR 1057 The YANG/JSON mappings to CBOR for 'lower-port' and 'upper-port' are 1058 already defined in Table 5 of [I-D.ietf-dots-rfc8782-bis]. 1060 6.3. YANG Module 1062 This module uses the common YANG types defined in [RFC6991] and the 1063 data structure extension defined in [RFC8791]. 1065 file "ietf-dots-call-home@2020-12-02.yang" 1066 module ietf-dots-call-home { 1067 yang-version 1.1; 1068 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home"; 1069 prefix dots-call-home; 1071 import ietf-inet-types { 1072 prefix inet; 1073 reference 1074 "Section 4 of RFC 6991"; 1075 } 1076 import ietf-dots-signal-channel { 1077 prefix dots-signal; 1078 reference 1079 "RFC YYYY: Distributed Denial-of-Service Open Threat 1080 Signaling (DOTS) Signal Channel Specification"; 1081 } 1082 import ietf-yang-structure-ext { 1083 prefix sx; 1084 reference 1085 "RFC 8791: YANG Data Structure Extensions"; 1086 } 1088 organization 1089 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 1090 contact 1091 "WG Web: 1092 WG List: 1094 Author: Konda, Tirumaleswar Reddy 1095 ; 1097 Author: Mohamed Boucadair 1098 ; 1100 Author: Jon Shallow 1101 "; 1102 description 1103 "This module contains YANG definitions for the signaling 1104 messages exchanged between a DOTS client and a DOTS server 1105 for the Call Home deployment scenario. 1107 Copyright (c) 2021 IETF Trust and the persons identified as 1108 authors of the code. All rights reserved. 1110 Redistribution and use in source and binary forms, with or 1111 without modification, is permitted pursuant to, and subject 1112 to the license terms contained in, the Simplified BSD License 1113 set forth in Section 4.c of the IETF Trust's Legal Provisions 1114 Relating to IETF Documents 1115 (http://trustee.ietf.org/license-info). 1117 This version of this YANG module is part of RFC XXXX; see 1118 the RFC itself for full legal notices."; 1120 revision 2020-12-02 { 1121 description 1122 "Initial revision."; 1123 reference 1124 "RFC XXXX: Distributed Denial-of-Service Open Threat 1125 Signaling (DOTS) Signal Channel Call Home"; 1126 } 1127 sx:augment-structure "/dots-signal:dots-signal" 1128 + "/dots-signal:message-type" 1129 + "/dots-signal:mitigation-scope" 1130 + "/dots-signal:scope" { 1131 description 1132 "Attack source details."; 1133 leaf-list source-prefix { 1134 type inet:ip-prefix; 1135 description 1136 "IPv4 or IPv6 prefix identifying the attack source(s)."; 1137 } 1138 list source-port-range { 1139 key "lower-port"; 1140 description 1141 "Port range. When only lower-port is 1142 present, it represents a single port number."; 1143 leaf lower-port { 1144 type inet:port-number; 1145 description 1146 "Lower port number of the port range."; 1147 } 1148 leaf upper-port { 1149 type inet:port-number; 1150 must '. >= ../lower-port' { 1151 error-message 1152 "The upper port number must be greater than 1153 or equal to lower port number."; 1154 } 1155 description 1156 "Upper port number of the port range."; 1157 } 1158 } 1159 list source-icmp-type-range { 1160 key "lower-type"; 1161 description 1162 "ICMP/ICMPv6 type range. When only lower-type is 1163 present, it represents a single ICMP/ICMPv6 type. 1165 The address family of the target-prefix is used 1166 to determine whether ICMP or ICMPv6 are used."; 1167 leaf lower-type { 1168 type uint8; 1169 description 1170 "Lower ICMP/ICMPv6 type of the ICMP type range."; 1171 reference 1172 "RFC 792: Internet Control Message Protocol 1173 RFC 4443: Internet Control Message Protocol (ICMPv6) 1174 for Internet Protocol Version 6 (IPv6) 1175 Specification."; 1176 } 1177 leaf upper-type { 1178 type uint8; 1179 must '. >= ../lower-type' { 1180 error-message 1181 "The upper ICMP/ICMPv6 type must be greater than 1182 or equal to lower ICMP type."; 1183 } 1184 description 1185 "Upper type of the ICMP type range."; 1186 reference 1187 "RFC 792: Internet Control Message Protocol 1188 RFC 4443: Internet Control Message Protocol (ICMPv6) 1189 for Internet Protocol Version 6 (IPv6) 1190 Specification."; 1191 } 1192 } 1193 } 1194 sx:augment-structure "/dots-signal:dots-signal" 1195 + "/dots-signal:message-type" 1196 + "/dots-signal:redirected-signal" { 1197 description 1198 "Augments the redirected signal to communicate an 1199 alternate Call Home DOTS client."; 1200 choice type { 1201 description 1202 "Indicates the type of the DOTS session (e.g., base 1203 DOTS signal channel, DOTS Call Home)."; 1204 case call-home-only { 1205 description 1206 "These attributes appear only in a call home signal 1207 channel message from a Call Home DOTS client 1208 to a Call Home DOTS server."; 1209 leaf alt-ch-client { 1210 type inet:domain-name; 1211 mandatory true; 1212 description 1213 "FQDN of an alternate Call Home DOTS client. 1215 This name is also presented as reference 1216 identifier for authentication purposes."; 1217 } 1218 leaf-list alt-ch-client-record { 1219 type inet:ip-address; 1220 description 1221 "List of IP addresses for the alternate Call 1222 Home DOTS client. 1224 If this data node is not present, a Call Home 1225 DOTS server resolves the alt-ch-client into 1226 one or more IP addresses."; 1227 } 1228 leaf ttl { 1229 type uint32; 1230 units "seconds"; 1231 description 1232 "The Time to live (TTL) of the alternate Call Home 1233 DOTS client."; 1234 reference 1235 "Section 4.6 of RFC YYYY"; 1236 } 1237 } 1238 } 1239 } 1240 } 1241 1243 7. IANA Considerations 1245 7.1. DOTS Signal Channel CBOR Mappings Registry 1247 This specification registers the following comprehension-optional 1248 parameters (Table 2) in the IANA "DOTS Signal Channel CBOR Key 1249 Values" registry [Key-Map]. 1251 o Note to the RFC Editor: Please delete TBA1-TBA8 once CBOR keys are 1252 assigned from the 32768-49151 range. 1254 +--------------------+-------+-------+------------+---------------+ 1255 | Parameter Name | CBOR | CBOR | Change | Specification | 1256 | | Key | Major | Controller | Document(s) | 1257 | | Value | Type | | | 1258 +====================+=======+=======+============+===============+ 1259 |ietf-dots-call-home:| | | | | 1260 | source-prefix | TBA1 | 4 | IESG | [RFCXXXX] | 1261 +--------------------+-------+-------+------------+---------------+ 1262 |ietf-dots-call-home:| | | | | 1263 | source-port-range | TBA2 | 4 | IESG | [RFCXXXX] | 1264 +--------------------+-------+-------+------------+---------------+ 1265 |ietf-dots-call-home:| | | | | 1266 | source-icmp-type- | TBA3 | 4 | IESG | [RFCXXXX] | 1267 | range | | | | | 1268 +--------------------+-------+-------+------------+---------------+ 1269 | lower-type | TBA4 | 0 | IESG | [RFCXXXX] | 1270 +--------------------+-------+-------+------------+---------------+ 1271 | upper-type | TBA5 | 0 | IESG | [RFCXXXX] | 1272 +--------------------+-------+-------+------------+---------------+ 1273 |ietf-dots-call-home:| | | | | 1274 | alt-ch-client | TBA6 | 3 | IESG | [RFCXXXX] | 1275 +--------------------+-------+-------+------------+---------------+ 1276 |ietf-dots-call-home:| | | | | 1277 |alt-ch-client-record| TBA7 | 4 | IESG | [RFCXXXX] | 1278 +--------------------+-------+-------+------------+---------------+ 1279 |ietf-dots-call-home:| | | | | 1280 | ttl | TBA8 | 0 | IESG | [RFCXXXX] | 1281 +--------------------+-------+-------+------------+---------------+ 1283 Table 2: Assigned DOTS Signal Channel CBOR Key Values 1285 7.2. New DOTS Conflict Cause 1287 This document requests IANA to assign a new code from the "DOTS 1288 Signal Channel Conflict Cause Codes" registry [Cause]. 1290 +-------+----------------------------------+------------+-----------+ 1291 | Code | Label | Descriptio | Reference | 1292 | | | n | | 1293 +-------+----------------------------------+------------+-----------+ 1294 | 4 (TB | request-rejected-legitimate- | Mitigation | [RFCXXXX] | 1295 | A9) | traffic | request | | 1296 | | | rejected. | | 1297 | | | This code | | 1298 | | | is | | 1299 | | | returned | | 1300 | | | by the | | 1301 | | | DOTS | | 1302 | | | server to | | 1303 | | | indicate | | 1304 | | | the attack | | 1305 | | | traffic | | 1306 | | | has been | | 1307 | | | classified | | 1308 | | | as | | 1309 | | | legitimate | | 1310 | | | traffic. | | 1311 +-------+----------------------------------+------------+-----------+ 1313 7.3. DOTS Signal Call Home YANG Module 1315 This document requests IANA to register the following URI in the "ns" 1316 subregistry within the "IETF XML Registry" [RFC3688]: 1318 URI: urn:ietf:params:xml:ns:yang:ietf-dots-call-home 1319 Registrant Contact: The IETF. 1320 XML: N/A; the requested URI is an XML namespace. 1322 This document requests IANA to register the following YANG module in 1323 the "YANG Module Names" subregistry [RFC6020] within the "YANG 1324 Parameters" registry: 1326 name: ietf-dots-call-home 1327 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home 1328 maintained by IANA: N 1329 prefix: dots-call-home 1330 reference: RFC XXXX 1332 8. Security Considerations 1334 This document deviates from classic DOTS signal channel usage by 1335 having the DOTS server initiate the (D)TLS connection. DOTS signal 1336 channel related security considerations discussed in Section 11 of 1337 [I-D.ietf-dots-rfc8782-bis] MUST be considered. DOTS agents MUST 1338 authenticate each other using (D)TLS before a DOTS signal channel 1339 session is considered valid. 1341 The Call Home function enables a Call Home DOTS server to be 1342 reachable by only the intended Call Home DOTS client. Appropriate 1343 filters (e.g., access control lists) can be installed on the Call 1344 Home DOTS server and network between the Call Home DOTS agents so 1345 that only communications from a trusted Call Home DOTS client to the 1346 Call Home DOTS server are allowed. These filters can be 1347 automatically installed by a Call Home DOTS server based on the 1348 configured or discovered peer Call Home DOTS client(s). 1350 An attacker may launch a DoS attack on the DOTS client by having it 1351 perform computationally expensive operations, before deducing that 1352 the attacker doesn't possess a valid key. For instance, in TLS 1.3 1353 [RFC8446], the ServerHello message contains a Key Share value based 1354 on an expensive asymmetric key operation for key establishment. 1355 Common precautions mitigating DoS attacks are recommended, such as 1356 temporarily adding to a drop-list the source address after a set 1357 number of unsuccessful authentication attempts. 1359 The DOTS Call Home signal channel can be misused by a misbehaving 1360 Call Home DOTS client by arbitrarily signalling legitimate traffic as 1361 being attack traffic or falsifying mitigation signals so that some 1362 sources are disconnected or some traffic is rate-limited. Such 1363 misbehaving Call Home DOTS clients may include sources identified by 1364 IP addresses that are used for internal use only (that is, these 1365 addresses are not visible outside a Call Home DOTS server domain). 1366 Absent explicit policy (e.g., the Call Home DOTS client and server 1367 are managed by the same administrative entity), such requests should 1368 be discarded by the Call Home DOTS server. More generally, Call Home 1369 DOTS servers should not blindly trust mitigation requests from Call 1370 Home DOTS clients. For example, Call Home DOTS servers could use the 1371 attack flow information contained in a mitigation request to enable a 1372 full-fledged packet inspection function to inspect all the traffic 1373 from the compromised device to the target, or could re-direct the 1374 traffic from the potentially compromised device to the target towards 1375 a DDoS mitigation system that can scrub the suspicious traffic, 1376 without blindly blocking all traffic from the indicated attack source 1377 to the target. Call Home DOTS servers can also seek the consent of 1378 DOTS server domain administrator to block the traffic from the 1379 potentially compromised device to the target (see Section 5.3.1). 1380 Means to seek the consent are implementation-specific. 1382 Call Home DOTS agents may interact with on-path address sharing 1383 functions to retrieve an internal IP addresss/external IP address 1384 mapping (Section 5.3.2) identifying an attack source. Blocking 1385 access or manipulating the mapping information will complicate DDoS 1386 attack mitigation close to an attack source. Additional security 1387 considerations are specific to the actual mechanism used to access 1388 that mapping (refer, e.g., to Section 4 of [RFC8512] or Section 4 of 1389 [RFC8513]). 1391 9. Privacy Considerations 1393 The considerations discussed in [RFC6973] were taken into account to 1394 assess whether the DOTS Call Home introduces privacy threats. 1396 Concretely, the protocol does not leak any new information that can 1397 be used to ease surveillance. In particular, the Call Home DOTS 1398 server is not required to share information that is local to its 1399 network (e.g., internal identifiers of an attack source) with the 1400 Call Home DOTS client. Also, the recommended data to be included in 1401 Call Home DOTS messages is a subset of the Layer 3/Layer 4 1402 information that can be learnt from the overall traffic flows that 1403 exit the Call Home DOTS server domain. Furthermore, Call Home DOTS 1404 clients do not publicly reveal attack identification information; 1405 that information is encrypted and only shared with an authorized 1406 entity in the domain to which the IP address/prefix is assigned, from 1407 which an attack was issued. 1409 The DOTS Call Home does not preclude the validation of mitigation 1410 requests received from a Call Home DOTS client. For example, a 1411 security service running on the CPE may require an administrator's 1412 consent before the CPE acts upon the mitigation request indicated by 1413 the Call Home DOTS client. How the consent is obtained is out of 1414 scope of this document. 1416 Note that a Call Home DOTS server can seek an administrator's 1417 consent, validate the request by inspecting the relevant traffic for 1418 attack signatures, or proceed with both courses of action. 1420 The DOTS Call Home is only advisory in nature. Concretely, the DOTS 1421 Call Home does not impose any action to be enforced within the 1422 network hosting an attack source; it is up to the Call Home DOTS 1423 server (and/or network administrator) to decide whether and which 1424 actions are required. 1426 Moreover, the DOTS Call Home avoids misattribution by appropriately 1427 identifying the network to which a suspect attack source belongs to 1428 (e.g., address sharing issues discussed in Section 5.3.1). 1430 Triggers to send a DOTS mitigation request to a Call Home DOTS server 1431 are deployment-specific. For example, a Call Home DOTS client may 1432 rely on the output of some DDoS detection systems (flow exports or 1433 similar functions) deployed within the DOTS client domain to detect 1434 potential outbound DDoS attacks or on abuse claims received from 1435 remote victim networks. These systems may be misused to track users 1436 and infer their activities. Such misuses are not required to achieve 1437 the functionality defined in this document (that is, protect the 1438 Internet and avoid altering the IP reputation of source networks). 1439 It is out of the scope to identify privacy threats specific to a 1440 given attack detection technology. The reader may refer, for 1441 example, to Section 11.8 of [RFC7011]. 1443 10. Contributors 1445 The following individuals have contributed to this document: 1447 Joshi Harsha 1448 McAfee, Inc. 1449 Embassy Golf Link Business Park 1450 Bangalore, Karnataka 560071 1451 India 1453 Email: harsha_joshi@mcafee.com 1455 Wei Pan 1456 Huawei Technologies 1457 China 1459 Email: william.panwei@huawei.com 1461 11. Acknowledgements 1463 Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Toema 1464 Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments. 1466 Benjamin Kaduk's AD review is valuable. Many thanks to him for the 1467 detailed review. 1469 Thanks to Radia Perlman and David Schinazi for the directorate 1470 reviews. 1472 Thanks to Ebben Aries for the yangdoctors review. 1474 Thanks to Eric Vyncke, Roman Danyliw, Barry Leiba, Robert Wilton, and 1475 Erik Kline for the IESG review. 1477 12. References 1478 12.1. Normative References 1480 [I-D.ietf-dots-rfc8782-bis] 1481 Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed 1482 Denial-of-Service Open Threat Signaling (DOTS) Signal 1483 Channel Specification", draft-ietf-dots-rfc8782-bis-06 1484 (work in progress), March 2021. 1486 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1487 RFC 792, DOI 10.17487/RFC0792, September 1981, 1488 . 1490 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1491 Requirement Levels", BCP 14, RFC 2119, 1492 DOI 10.17487/RFC2119, March 1997, 1493 . 1495 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1496 DOI 10.17487/RFC3688, January 2004, 1497 . 1499 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1500 Control Message Protocol (ICMPv6) for the Internet 1501 Protocol Version 6 (IPv6) Specification", STD 89, 1502 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1503 . 1505 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1506 the Network Configuration Protocol (NETCONF)", RFC 6020, 1507 DOI 10.17487/RFC6020, October 2010, 1508 . 1510 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1511 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1512 DOI 10.17487/RFC6052, October 2010, 1513 . 1515 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1516 NAT64: Network Address and Protocol Translation from IPv6 1517 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1518 April 2011, . 1520 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1521 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1522 January 2012, . 1524 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1525 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1526 . 1528 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1529 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1530 May 2017, . 1532 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1533 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1534 . 1536 [RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data 1537 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 1538 June 2020, . 1540 12.2. Informative References 1542 [Cause] IANA, "DOTS Signal Channel Conflict Cause Codes", 1543 . 1546 [I-D.ietf-dots-multihoming] 1547 Boucadair, M., Reddy, T., and W. Pan, "Multi-homing 1548 Deployment Considerations for Distributed-Denial-of- 1549 Service Open Threat Signaling (DOTS)", draft-ietf-dots- 1550 multihoming-05 (work in progress), November 2020. 1552 [I-D.ietf-dots-use-cases] 1553 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 1554 L., and K. Nishizuka, "Use cases for DDoS Open Threat 1555 Signaling", draft-ietf-dots-use-cases-25 (work in 1556 progress), July 2020. 1558 [I-D.ietf-i2nsf-terminology] 1559 Hares, S., Strassner, J., Lopez, D. R., Xia, L., and H. 1560 Birkholz, "Interface to Network Security Functions (I2NSF) 1561 Terminology", draft-ietf-i2nsf-terminology-08 (work in 1562 progress), July 2019. 1564 [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", 1565 . 1568 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1569 Translator (NAT) Terminology and Considerations", 1570 RFC 2663, DOI 10.17487/RFC2663, August 1999, 1571 . 1573 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1574 Congestion Control Protocol (DCCP)", RFC 4340, 1575 DOI 10.17487/RFC4340, March 2006, 1576 . 1578 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1579 (CIDR): The Internet Address Assignment and Aggregation 1580 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1581 2006, . 1583 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1584 Denial-of-Service Considerations", RFC 4732, 1585 DOI 10.17487/RFC4732, December 2006, 1586 . 1588 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1589 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1590 . 1592 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1593 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1594 . 1596 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 1597 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 1598 2011, . 1600 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1601 Morris, J., Hansen, M., and R. Smith, "Privacy 1602 Considerations for Internet Protocols", RFC 6973, 1603 DOI 10.17487/RFC6973, July 2013, 1604 . 1606 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 1607 "Specification of the IP Flow Information Export (IPFIX) 1608 Protocol for the Exchange of Flow Information", STD 77, 1609 RFC 7011, DOI 10.17487/RFC7011, September 2013, 1610 . 1612 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1613 Farrer, "Lightweight 4over6: An Extension to the Dual- 1614 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 1615 July 2015, . 1617 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 1618 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 1619 Port with Encapsulation (MAP-E)", RFC 7597, 1620 DOI 10.17487/RFC7597, July 2015, 1621 . 1623 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1624 RFC 8071, DOI 10.17487/RFC8071, February 2017, 1625 . 1627 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1628 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1629 . 1631 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1632 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1633 Address Translation (NAT) and Network Prefix Translation 1634 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1635 . 1637 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 1638 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 1639 DOI 10.17487/RFC8513, January 2019, 1640 . 1642 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 1643 Jacquenet, "An Inventory of Transport-Centric Functions 1644 Provided by Middleboxes: An Operator Perspective", 1645 RFC 8517, DOI 10.17487/RFC8517, February 2019, 1646 . 1648 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 1649 Things (IoT) Security: State of the Art and Challenges", 1650 RFC 8576, DOI 10.17487/RFC8576, April 2019, 1651 . 1653 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 1654 Threat Signaling (DOTS) Requirements", RFC 8612, 1655 DOI 10.17487/RFC8612, May 2019, 1656 . 1658 [RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., 1659 Teague, N., and R. Compton, "DDoS Open Threat Signaling 1660 (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, 1661 August 2020, . 1663 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 1664 Bacher, "Dissemination of Flow Specification Rules", 1665 RFC 8955, DOI 10.17487/RFC8955, December 2020, 1666 . 1668 [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., 1669 "Dissemination of Flow Specification Rules for IPv6", 1670 RFC 8956, DOI 10.17487/RFC8956, December 2020, 1671 . 1673 [RFC8973] Boucadair, M. and T. Reddy.K, "DDoS Open Threat Signaling 1674 (DOTS) Agent Discovery", RFC 8973, DOI 10.17487/RFC8973, 1675 January 2021, . 1677 [RS] RSnake, "Slowloris HTTP DoS", 1678 . 1681 [Sec-by-design] 1682 UK Department for Digital Culture, Media & Sport, "Secure 1683 by Design: Improving the cyber security of consumer 1684 Internet of Things Report", March 2018, 1685 . 1688 Appendix A. Some Home Network Issues 1690 Internet of Things (IoT) devices are becoming more and more 1691 prevalent, in particular in home networks. With compute and memory 1692 becoming cheaper and cheaper, various types of IoT devices become 1693 available in the consumer market at affordable prices. But on the 1694 downside, there is a corresponding threat since most of these IoT 1695 devices are bought off-the-shelf and most manufacturers haven't 1696 considered security in the product design (e.g., [Sec-by-design]). 1697 IoT devices deployed in home networks can be easily compromised, they 1698 often do not have an easy mechanism to upgrade, and even when 1699 upgradable, IoT manufacturers may cease manufacture and/or 1700 discontinue patching vulnerabilities on IoT devices (Sections 5.4 and 1701 5.5 of [RFC8576]). These vulnerable and compromised devices will 1702 continue to be used for a long period of time in the home, and the 1703 end-user does not know that IoT devices in his/her home are 1704 compromised. The compromised IoT devices are typically used for 1705 launching DDoS attacks (Section 3 of [RFC8576]) on victims while the 1706 owner/administrator of the home network is not aware about such 1707 misbehaviors. Similar to other DDoS attacks, the victim in this 1708 attack can be an application server, a host, a router, a firewall, or 1709 an entire network. Such misbehaviors can cause collateral damage 1710 that will affect end users, and can also harm the reputation of an 1711 Internet Service Provider (ISP) for being a source of attack traffic. 1713 Nowadays, network devices in a home network can offer network 1714 security functions (e.g., firewall [RFC4949] or Intrusion Protection 1715 System (IPS) service [I-D.ietf-i2nsf-terminology] on a home router) 1716 to protect the devices connected to the home network from both 1717 external and internal attacks. It is natural to seek to provide DDoS 1718 defense in these devices as well, and over the years several 1719 techniques have been identified to detect DDoS attacks; some of these 1720 techniques can be enabled on home network devices but most of them 1721 are used within the ISP's network. 1723 Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris 1724 [RS], and Transport Layer Security (TLS) renegotiation are difficult 1725 to detect on a home network device without adversely affecting its 1726 performance. The reason is that typically home devices such as home 1727 routers have fast path to boost the throughput. For every new TCP/ 1728 UDP flow, only the first few packets are punted through the slow 1729 path. Hence, it is not possible to detect various DDoS attacks in 1730 the slow path, since the attack payload is sent to the target server 1731 after the flow is switched to fast path. The reader may refer to 1732 Section 2 of [RFC6398] for a brief definition of slow and fast paths. 1734 Deep Packet Inspection (DPI) of all the packets of a flow would be 1735 able to detect some of the attacks. However, a full-fledged DPI to 1736 detect these type of DDoS attacks is functionally or operationally 1737 not possible for all the devices attached to the home network because 1738 of the memory and CPU limitations of the home routers. Furthermore, 1739 for certain DDoS attacks the logic needed to distinguish legitimate 1740 traffic from attack traffic on a per-packet basis is complex. This 1741 complexity is because that the packet itself may look "legitimate" 1742 and no attack signature can be identified. The anomaly can be 1743 identified only after detailed statistical analysis. In addition, 1744 network security services in home networks may not be able to detect 1745 all types of DDoS attacks using DPI. ISPs offering DDoS mitigation 1746 services have a DDoS detection capability that relies upon anomaly 1747 detection to identify zero day DDoS attacks and to detect DDoS 1748 attacks that cannot be detected using signatures and rate-limit 1749 techniques. 1751 ISPs can detect some DDoS attacks originating from a home network 1752 (e.g., Section 2.6 of [RFC8517]), but the ISP usually does not have a 1753 mechanism to detect which device in the home network is generating 1754 the DDoS attack traffic. The primary reason for this is that devices 1755 in an IPv4 home network are typically behind a Network Address 1756 Translation (NAT) border [RFC2663]. Even in case of an IPv6 home 1757 network, although the ISP can identify the infected device in the 1758 home network launching the DDoS traffic by tracking its unique IPv6 1759 address, the infected device can easily change its IPv6 address to 1760 evade remediation. A security function on the local home network is 1761 better positioned to track the compromised device across IPv6 address 1762 (and potentially even MAC address) changes and thus ensure that 1763 remediation remains in place across such events. 1765 Appendix B. Disambiguating Base DOTS Signal vs. DOTS Call Home 1767 With the DOTS signal channel Call Home, there is a chance that two 1768 DOTS agents can simultaneously establish two DOTS signal channels 1769 with different directions (base DOTS signal channel and DOTS signal 1770 channel Call Home). Here is one example drawn from the home network. 1771 Nevertheless, the outcome of the discussion is not specific to these 1772 networks, but applies to any DOTS Call Home scenario. 1774 In the Call Home scenario, the Call Home DOTS server in, for example, 1775 the home network can mitigate the DDoS attacks launched by the 1776 compromised device in its domain by receiving the mitigation request 1777 sent by the Call Home DOTS client in the ISP environment. In 1778 addition, the DOTS client in the home network can initiate a 1779 mitigation request to the DOTS server in the ISP environment to ask 1780 for help when the home network is under a DDoS attack. Such Call 1781 Home DOTS server and DOTS client in the home network can co-locate in 1782 the same home network element (e.g., the Customer Premises 1783 Equipment). In this case, with the same peer at the same time the 1784 home network element will have the base DOTS signal channel defined 1785 in [I-D.ietf-dots-rfc8782-bis] and the DOTS signal channel Call Home 1786 defined in this specification. Thus, these two signal channels need 1787 to be distinguished when they are both supported. Two approaches 1788 have been considered for distinguishing the two DOTS signal channels, 1789 but only the one that using the dedicated port number has been chosen 1790 as the best choice. 1792 By using a dedicated port number for each, these two signal channels 1793 can be separated unambiguously and easily. For example, the CPE uses 1794 the port number 4646 allocated in [I-D.ietf-dots-rfc8782-bis] to 1795 initiate the basic signal channel to the ISP when it acts as the DOTS 1796 client, and uses another port number to initiate the signal channel 1797 Call Home. Based on the different port numbers, the ISP can directly 1798 decide which kind of procedures should follow immediately after it 1799 receives the DOTS messages. This approach just requires two (D)TLS 1800 sessions to be established respectively for the basic signal channel 1801 and signal channel Call Home. 1803 The other approach is signaling the role of each DOTS agent (e.g., by 1804 using the DOTS data channel as depicted in Figure 14). For example, 1805 the DOTS agent in the home network first initiates a DOTS data 1806 channel to the peer DOTS agent in the ISP environment, at this time 1807 the DOTS agent in the home network is the DOTS client and the peer 1808 DOTS agent in the ISP environment is the DOTS server. After that, 1809 the DOTS agent in the home network retrieves the DOTS Call Home 1810 capability of the peer DOTS agent. If the peer supports the DOTS 1811 Call Home, the DOTS agent needs to subscribe to the peer to use this 1812 extension. Then, the reversal of DOTS role can be recognized as done 1813 by both DOTS agents. When the DOTS agent in the ISP environment, 1814 which now is the DOTS client, wants to filter the attackers' traffic, 1815 it requests the DOTS agent in the home network, which now is the DOTS 1816 server, for help. 1818 augment /ietf-data:dots-data/ietf-data:capabilities: 1819 +--ro call-home-support? boolean 1820 augment /ietf-data:dots-data/ietf-data:dots-client: 1821 +--rw call-home-enable? boolean 1823 Figure 14: Example of DOTS Data Channel Augmentation 1825 Signaling the role will complicate the DOTS protocols, and this 1826 complexity is not required in context where the DOTS Call Home is not 1827 required or only when the DOTS Call Home is needed. Besides, the 1828 DOTS data channel may not work during attack time. Even if changing 1829 the above example from using the DOTS data channel to the DOTS signal 1830 channel, the more procedures will still reduce the efficiency. Using 1831 the dedicated port number is much easier and more concise compared to 1832 the second approach, and its cost that establishing two (D)TLS 1833 sessions is much less. So, using a dedicated port number for the 1834 DOTS Call Home is recommended in this specification. The dedicated 1835 port number can be configured locally or discovered using means such 1836 as [RFC8973]. 1838 Authors' Addresses 1840 Tirumaleswar Reddy 1841 McAfee, Inc. 1842 Embassy Golf Link Business Park 1843 Bangalore, Karnataka 560071 1844 India 1846 Email: kondtir@gmail.com 1847 Mohamed Boucadair (editor) 1848 Orange 1849 Rennes 35000 1850 France 1852 Email: mohamed.boucadair@orange.com 1854 Jon Shallow 1855 UK 1857 Email: supjps-ietf@jpshallow.com