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