idnits 2.17.1 draft-ietf-dots-signal-call-home-11.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 1011 has weird spacing: '...er-port ine...' == Line 1014 has weird spacing: '...er-type uin...' -- The document date (October 27, 2020) is 1276 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-01 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-13) exists of draft-ietf-dots-multihoming-04 == Outdated reference: A later version (-15) exists of draft-ietf-dots-server-discovery-12 == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-16 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 2 errors (**), 0 flaws (~~), 8 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: April 30, 2021 Orange 6 J. Shallow 7 October 27, 2020 9 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 10 Channel Call Home 11 draft-ietf-dots-signal-call-home-11 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 April 30, 2021. 70 Copyright Notice 72 Copyright (c) 2020 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 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 89 1.2. The Call Home Solution . . . . . . . . . . . . . . . . . 5 90 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 91 3. Applicability Scope . . . . . . . . . . . . . . . . . . . . . 7 92 4. Co-existence of Base DOTS Signal Channel & DOTS Call Home . . 8 93 5. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 12 94 5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 12 95 5.2. DOTS Signal Channel Variations . . . . . . . . . . . . . 14 96 5.2.1. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 14 97 5.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 15 98 5.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 16 99 5.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 16 100 5.3.2. Address Sharing Considerations . . . . . . . . . . . 20 101 6. DOTS Signal Call Home YANG Module . . . . . . . . . . . . . . 23 102 6.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 23 103 6.2. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . 24 104 6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25 105 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 106 7.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 29 107 7.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 30 108 7.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 31 109 7.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 32 110 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 111 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 34 112 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35 113 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 114 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 115 12.1. Normative References . . . . . . . . . . . . . . . . . . 35 116 12.2. Informative References . . . . . . . . . . . . . . . . . 37 117 Appendix A. Disambiguating Base DOTS Signal vs. DOTS Call Home . 40 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 120 1. Introduction 122 1.1. The Problem 124 The DOTS signal channel protocol [I-D.ietf-dots-rfc8782-bis] is used 125 to carry information about a network resource or a network (or a part 126 thereof) that is under a Distributed Denial of Service (DDoS) attack 127 [RFC4732]. Such information is sent by a DOTS client to one or 128 multiple DOTS servers so that appropriate mitigation actions are 129 undertaken on traffic deemed suspicious. Various use cases are 130 discussed in [I-D.ietf-dots-use-cases]. 132 Internet of Things (IoT) devices are becoming more and more 133 prevalent, in particular in home networks. With compute and memory 134 becoming cheaper and cheaper, various types of IoT devices become 135 available in the consumer market at affordable prices. But on the 136 downside, there is a corresponding threat since most of these IoT 137 devices are bought off-the-shelf and most manufacturers haven't 138 considered security in the product design (e.g., [Sec-by-design]). 139 IoT devices deployed in home networks can be easily compromised, they 140 often do not have an easy mechanism to upgrade, and even when 141 upgradable, IoT manufacturers may cease manufacture and/or 142 discontinue patching vulnerabilities on IoT devices (Sections 5.4 and 143 5.5 of [RFC8576]). These vulnerable and compromised devices will 144 continue to be used for a long period of time in the home, and the 145 end-user does not know that IoT devices in his/her home are 146 compromised. The compromised IoT devices are typically used for 147 launching DDoS attacks (Section 3 of [RFC8576]) on victims while the 148 owner/administrator of the home network is not aware about such 149 misbehaviors. Similar to other DDoS attacks, the victim in this 150 attack can be an application server, a host, a router, a firewall, or 151 an entire network. Such misbehaviors will have both a collateral 152 damage that affects end users, and can harm the reputation of an 153 Internet Service Provider (ISP) for being a source of attack traffic. 155 Nowadays, network devices in a home network can offer network 156 security functions (e.g., firewall [RFC4949] or Intrusion Protection 157 System (IPS) service [I-D.ietf-i2nsf-terminology] on a home router) 158 to protect the devices connected to the home network from both 159 external and internal attacks. It is natural to seek to provide DDoS 160 defense in these devices as well, and over the years several 161 techniques have been identified to detect DDoS attacks; some of these 162 techniques can be enabled on home network devices but most of them 163 are used within the ISP's network. The ISP offering a DDoS 164 mitigation service can detect outgoing DDoS attack traffic 165 originating from its subscribers or the ISP may receive filtering 166 rules (e.g., using BGP Flowspec [RFC5575][I-D.ietf-idr-flow-spec-v6]) 167 from a downstream service provider to filter, block, or rate-limit 168 DDoS attack traffic originating from the ISP's subscribers to a 169 downstream target. 171 Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris, 172 and Transport Layer Security (TLS) renegotiation are difficult to 173 detect on a home network device without adversely affecting its 174 performance. The reason is that typically home devices such as home 175 routers have fast path to boost the throughput. For every new TCP/ 176 UDP flow, only the first few packets are punted through the slow 177 path. Hence, it is not possible to detect various DDoS attacks in 178 the slow path, since the attack payload is sent to the target server 179 after the flow is switched to fast path. The reader may refer to 180 Section 2 of [RFC6398] for a brief definition of slow and fast paths. 182 Deep Packet Inspection (DPI) of all the packets of a flow would be 183 able to detect some of the attacks. However, a full-fledged DPI to 184 detect these type of DDoS attacks is functionally or operationally 185 not possible for all the devices attached to the home network owing 186 to the memory and CPU limitations of the home routers. Furthermore, 187 for certain DDoS attacks the logic needed to distinguish legitimate 188 traffic from attack traffic on a per-packet basis is complex. This 189 complexity is due to the fact that the packet itself may look 190 "legitimate" and no attack signature can be identified. The anomaly 191 can be identified only after detailed statistical analysis. 193 ISPs can detect some DDoS attacks originating from a home network 194 (e.g., Section 2.6 of [RFC8517]), but the ISP usually does not have a 195 mechanism to detect which device in the home network is generating 196 the DDoS attack traffic. The primary reason for this is that devices 197 in an IPv4 home network are typically behind a Network Address 198 Translation (NAT) border [RFC2663]. Even in case of an IPv6 home 199 network, although the ISP can identify the infected device in the 200 home network launching the DDoS traffic by tracking its unique IPv6 201 address, the infected device can easily change its IPv6 address to 202 evade remediation. A security function on the local home network is 203 better positioned to track the compromised device across IPv6 address 204 (and potentially even MAC address) changes and thus ensure that 205 remediation remains in place across such events. 207 Existing approaches are still suffering from misused access network 208 resources by abusive devices; the support of means for blocking such 209 attacks close to the sources are missing. In particular, the DOTS 210 signal protocol does not discuss cooperative DDoS mitigation between 211 the network hosting an attack source and the ISP to the suppress the 212 outbound DDoS attack traffic originating from that network. 214 1.2. The Call Home Solution 216 This specification addresses the problems discussed in Section 1.1 217 and presents an extension to the DOTS signal channel: DOTS signal 218 channel Call Home. 220 'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers 221 to a DOTS signal channel established at the initiative of a DOTS 222 server thanks to a role reversal at the (D)TLS layer (Section 5.1). 223 That is, the DOTS server initiates a secure connection to a DOTS 224 client, and uses that connection to receive the attack traffic 225 information (e.g., attack sources) from the DOTS client. 227 DOTS agents involved in the DOTS Call Home otherwise adhere to the 228 DOTS roles as defined in [RFC8612]. For clarity, this document uses 229 "Call Home DOTS client" (or "Call Home DOTS server") to refer to a 230 DOTS client (or DOTS server) deployed in a Call Home scenario 231 (Figure 1). DOTS Call Home agents may (or not) be co-located with 232 DOTS agents that are compliant with [I-D.ietf-dots-rfc8782-bis] (see 233 Section 4 for more details). 235 A high-level DOTS Call Home functional architecture is shown in 236 Figure 1. Attack source(s) are within the DOTS server domain. 238 Scope 239 +.-.-.-.-.-.-.-.-.-.-.-.+ 240 +---------------+ : +-------------+ : 241 | Alert | ~~~:~~~ | Call Home | : 242 | | : | DOTS client | : 243 +---------------+ : +------+------+ : 244 : | : 245 : | : 246 : | : 247 +---------------+ : +------+------+ : 248 | Attack | ~~~:~~~ | Call Home | : 249 | Source(s) | : | DOTS server | : 250 +---------------+ : +-------------+ : 251 +.-.-.-.-.-.-.-.-.-.-.-.+ 253 Figure 1: Basic DOTS Signal Channel Call Home Functional Architecture 255 A Call Home DOTS client relies upon a variety of triggers to make use 256 of the Call Home function (e.g., scrubbing the traffic from the 257 attack source, receiving an alert from an attack target, a peer DDoS 258 Mitigation System (DMS), or a transit provider). The definition of 259 these triggers is deployment-specific. It is therefore out of the 260 scope of this document to elaborate on how these triggers are made 261 available to a Call Home DOTS client. 263 In a typical deployment scenario, the Call Home DOTS server is 264 enabled on a Customer Premises Equipment (CPE), which is aligned with 265 recent trends to enrich the CPE with advanced security features. 266 Unlike classic DOTS deployments [I-D.ietf-dots-use-cases], such DOTS 267 server maintains a single DOTS signal channel session for each DOTS- 268 capable upstream provisioning domain [I-D.ietf-dots-multihoming]. 270 For instance, the Call Home DOTS server in the home network initiates 271 the signal channel Call Home in 'idle' time and then subsequently the 272 Call Home DOTS client in the ISP environment can initiate a 273 mitigation request whenever the ISP detects there is an attack from a 274 compromised device in the DOTS server domain (i.e., from within the 275 home network). 277 The Call Home DOTS server uses the DDoS attack traffic information to 278 identify the compromised device in its domain that is responsible for 279 launching the DDoS attack, optionally notifies a network 280 administrator, and takes appropriate mitigation action(s). For 281 example, a mitigation action can be to quarantine the compromised 282 device or block its traffic to the attack target(s) until the 283 mitigation request is withdrawn. 285 Other motivations for introducing the Call Home function are 286 discussed in Section 1.1 of [RFC8071]. 288 This document assumes that Call Home DOTS servers are provisioned 289 with a way to know how to reach the upstream Call Home DOTS 290 client(s), which could occur by a variety of means (e.g., 291 [I-D.ietf-dots-server-discovery]). The specification of such means 292 are out of scope of this document. 294 More information about the applicability scope of the DOTS signal 295 channel Call Home is provided in Section 3. 297 2. Terminology 299 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 300 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 301 "OPTIONAL" in this document are to be interpreted as described in BCP 302 14 [RFC2119][RFC8174] when, and only when, they appear in all 303 capitals, as shown here. 305 The reader should be familiar with the terms defined in Section 1.2 306 of [RFC8612]. 308 DDoS Mitigation System (DMS) refers to a system that performs DDoS 309 mitigation. 311 'Base DOTS signal channel' refers to [I-D.ietf-dots-rfc8782-bis]. 313 The meaning of the symbols in YANG tree diagrams are defined in 314 [RFC8340] and [RFC8791]. 316 (D)TLS is used for statements that apply to both Transport Layer 317 Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS) 318 [RFC6347]. Specific terms are used for any statement that applies to 319 either protocol alone. 321 3. Applicability Scope 323 The aforementioned problems may be encountered in other deployments 324 than those discussed in Section 1.1 (e.g., data centers, enterprise 325 networks). The solution specified in this document can be used for 326 those deployments to block DDoS attack traffic closer to the 327 source(s) of the attack. 329 An instantiation of the Call Home functional architecture is depicted 330 in Figure 2. 332 +-------------+ 333 |Attack Target| 334 +-----+-------+ 335 | /\ Target Network 336 ......................|.||.................... 337 .--------+-||-------. 338 ( || )-. 339 .' || ' 340 ( Internet || ) 341 ( || -' 342 '-( || ) 343 '------+-||---------' 344 ......................|.||..................... 345 .--------+-||-------. Network 346 ( || )-. Provider 347 .' Call Home || ' (DMS) 348 ( DOTS client || ) 349 ( || -' 350 '-( || ) 351 '------+-||---------' 352 ......................|.||....................... 353 .--------+-||-------. Source Network 354 ( || )-. 355 .' Call Home || ' 356 ( DOTS server || Outbound ) 357 ( || DDoS -' 358 '-( || Attack ) 359 '------+-||---------' 360 | || 361 +-----+-++----+ 362 |Attack Source| 363 +-------------+ 365 Figure 2: DOTS Signal Channel Call Home Reference Architecture 367 It is out of the scope of this document to identify an exhaustive 368 list of such deployments. 370 4. Co-existence of Base DOTS Signal Channel & 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 3 (Same DMS provider) or Figure 4 (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 3: 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 4). 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 4: Activation of Base DOTS Signal Channel and Call Home 434 (Distinct DMS Providers) 436 Figures 5 and 6 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 5) 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 6) . 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 5: 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 6: Another Example where the Same Node Embeds both a DOTS 499 Client and a Call Home DOTS Server 501 Appendix A 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 are encouraged. It is out of the scope 530 of this document to elaborate on these means. 532 Figure 7 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 7: 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 A. 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. 636 This is a mandatory attribute for DOTS signal Call Home. It MUST 637 NOT be used for base DOTS signal channel operations. 639 alt-ch-client-record: List of IP addresses for the alternate Call 640 Home DOTS client. If no 'alt-ch-client-record' is provided, the 641 Call Home DOTS server passes the 'alt-ch-client' name to a name 642 resolution library to retrieve one or more IP addresses of the 643 alternate Call Home DOTS client. 645 This is an optional attribute for DOTS signal Call Home. It MUST 646 NOT be used for base DOTS signal channel operations. 648 ttl: The Time to live (TTL) of the alternate Call Home DOTS client. 649 That is, the time interval that the alternate Call Home DOTS 650 client may be cached for use by a Call Home DOTS server. 652 This is an optional attribute for DOTS signal Call Home. It MUST 653 NOT be used for base DOTS signal channel operations. 655 On receipt of this PUT request, the Call Home DOTS server responds 656 with a 2.01 (Created), closes this connection and establishes a 657 connection with the new Call Home DOTS client. The processing of the 658 TTL is defined in Section 4.6 of [I-D.ietf-dots-rfc8782-bis]. If the 659 Call Home DOTS server cannot service the PUT request, the response is 660 rejected with a 4.00 (Bad Request). 662 Figure 8 shows a PUT request example to convey the alternate Call 663 Home DOTS client 'alt-call-home-client.example' together with its IP 664 addresses 2001:db8:6401::1 and 2001:db8:6401::2. The validity of 665 this alternate Call Home DOTS client is 10 minutes. 667 Header: PUT (Code=0.03) 668 Uri-Path: ".well-known" 669 Uri-Path: "dots" 670 Uri-Path: "redirect" 671 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 672 Uri-Path: "mid=123" 673 Content-Format: "application/dots+cbor" 675 { 676 "ietf-dots-signal-channel:redirected-signal": { 677 "ietf-dots-call-home:alt-ch-client": 678 "alt-call-home-client.example", 679 "ietf-dots-call-home:alt-ch-client-record": [ 680 "2001:db8:6401::1", 681 "2001:db8:6401::2" 682 ], 683 "ietf-dots-call-home:ttl": 600 684 } 686 Figure 8: Example of a PUT Request for Redirected Signaling 688 5.3. DOTS Signal Channel Extension 690 5.3.1. Mitigation Request 692 This specification extends the mitigation request defined in 693 Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis] to convey the attack 694 source information (e.g., source prefixes, source port numbers). The 695 DOTS client conveys the following new parameters in the CBOR body of 696 the mitigation request: 698 source-prefix: A list of attacker IP prefixes used to attack the 699 target. Prefixes are represented using Classless Inter-Domain 700 Routing (CIDR) notation BCP 122 [RFC4632]. 702 As a reminder, the prefix length MUST be less than or equal to 32 703 (or 128) for IPv4 (or IPv6). 705 The prefix list MUST NOT include broadcast, loopback, or multicast 706 addresses. These addresses are considered as invalid values. In 707 addition, the Call Home DOTS client MUST validate that attacker 708 prefixes are within the scope of the Call Home DOTS server domain 709 (e.g., prefixes assigned to the Call Home DOTS server domain or 710 networks it services). This check is meant to avoid contacting 711 Call Home DOTS servers that are not entitled to enforce actions on 712 specific prefixes. 714 This is an optional attribute for the base DOTS signal channel 715 operations. 717 source-port-range: A list of port numbers used by the attack traffic 718 flows. 720 A port range is defined by two bounds, a lower port number (lower- 721 port) and an upper port number (upper-port). When only 'lower- 722 port' is present, it represents a single port number. 724 For TCP, UDP, Stream Control Transmission Protocol (SCTP) 725 [RFC4960], or Datagram Congestion Control Protocol (DCCP) 726 [RFC4340], a range of ports can be any subrange of 0-65535, for 727 example, 0-1023, 1024-65535, or 1024-49151. 729 This is an optional attribute for the base DOTS signal channel 730 operations. 732 source-icmp-type-range: A list of ICMP types used by the attack 733 traffic flows. An ICMP type range is defined by two bounds, a 734 lower ICMP type (lower-type) and an upper ICMP type (upper-type). 735 When only 'lower-type' is present, it represents a single ICMP 736 type. Both ICMP [RFC0792] and ICMPv6 [RFC4443] types are 737 supported. Whether ICMP or ICMPv6 types are to be used is 738 determined by the address family of the 'target-prefix'. 740 This is an optional attribute for the base DOTS signal channel 741 operations. 743 The 'source-prefix' parameter is a mandatory attribute when the 744 attack traffic information is signaled by a Call Home DOTS client 745 (i.e., the Call Home scenario depicted in Figure 7). The 'target- 746 prefix' attribute MUST be included in the mitigation request 747 signaling the attack information to a Call Home DOTS server. The 748 'target-uri' or 'target-fqdn' parameters can be included in a 749 mitigation request for diagnostic purposes to notify the Call Home 750 DOTS server domain administrator, but SHOULD NOT be used to determine 751 the target IP addresses. 'alias-name' is unlikely to be conveyed in 752 a Call Home mitigation request given that a target may be any IP 753 resource and that there is no incentive for a Call Home DOTS server 754 (embedded, for example, in a CPE) to maintain aliases. 756 In order to help attack source identification by a Call Home DOTS 757 server, the Call Home DOTS client SHOULD include in its mitigation 758 request additional information such as 'source-port-range' or 759 'source-icmp-type-range' to disambiguate nodes sharing the same 760 'source-prefix'. IPv6 addresses/prefixes are sufficient to uniquely 761 identify a network endpoint, without need for port numbers or ICMP 762 type information. While this is also possible for IPv4, it is much 763 less often the case than for IPv6. More address sharing implications 764 on the setting of source information ('source-prefix', 'source-port- 765 range') are discussed in Section 5.3.2. 767 Only immediate mitigation requests (i.e., 'trigger-mitigation' set to 768 'true') are allowed; Call Home DOTS clients MUST NOT send requests 769 with 'trigger-mitigation' set to 'false'. Such requests MUST be 770 discarded by the Call Home DOTS server with a 4.00 (Bad Request). 772 An example of a mitigation request sent by a Call Home DOTS client is 773 shown in Figure 9. 775 Header: PUT (Code=0.03) 776 Uri-Path: ".well-known" 777 Uri-Path: "dots" 778 Uri-Path: "mitigate" 779 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 780 Uri-Path: "mid=56" 781 Content-Format: "application/dots+cbor" 783 { 784 "ietf-dots-signal-channel:mitigation-scope": { 785 "scope": [ 786 { 787 "target-prefix": [ 788 "2001:db8:c000::/128" 789 ], 790 "ietf-dots-call-home:source-prefix": [ 791 "2001:db8:123::/128" 792 ], 793 "lifetime": 3600 794 } 795 ] 796 } 797 } 799 Figure 9: An Example of Mitigation Request Issued by a Call Home DOTS 800 Client 802 The Call Home DOTS server MUST check that the 'source-prefix' is 803 within the scope of the Call Home DOTS server domain. Note that in a 804 DOTS Call Home scenario, the Call Home DOTS server considers, by 805 default, that any routeable IP prefix enclosed in 'target-prefix' is 806 within the scope of the Call Home DOTS client. Invalid mitigation 807 requests are handled as per Section 4.4.1 of 808 [I-D.ietf-dots-rfc8782-bis]. 810 Note: These validation checks do not apply when the source 811 information is included as a hint in the context of the base DOTS 812 signal channel. 814 The Call Home DOTS server domain administrator consent MAY be 815 required to block the traffic from the compromised device to the 816 attack target. An implementation MAY have a configuration knob to 817 block the traffic from the compromised device to the attack target 818 with or without DOTS server domain administrator consent. 820 If a consent from the Call Home DOTS server domain administrator is 821 required, the Call Home DOTS server replies with 2.01 (Created) and 822 'status' code set to 1 (attack-mitigation-in-progress). Then, the 823 mechanisms defined in Section 4.4.2 of [I-D.ietf-dots-rfc8782-bis] 824 are followed by the DOTS agents to update the mitigation status. 825 Particularly, if the attack traffic is blocked, the Call Home DOTS 826 server informs the Call Home DOTS client that the attack is being 827 mitigated (i.e., by setting the 'status' code to 2 (attack- 828 successfully-mitigated)). 830 If the attack traffic information is identified by the Call Home DOTS 831 server or the Call Home DOTS server domain administrator as 832 legitimate traffic, the mitigation request is rejected with a 4.09 833 (Conflict) (e.g., when no consent is required from an administrator) 834 or a notification message with the 'conflict-clause' (Section 4.4.1 835 of [I-D.ietf-dots-rfc8782-bis]) set to the following new value: 837 4: Mitigation request rejected. This code is returned by the DOTS 838 server to indicate the attack traffic has been classified as 839 legitimate traffic. 841 Once the request is validated by the Call Home DOTS server, 842 appropriate actions are enforced to block the attack traffic within 843 the source network. For example, if the Call Home DOTS server is 844 embedded in a CPE, it can program the packet processor to punt all 845 the traffic from the compromised device to the target to slow path. 846 The CPE inspects the punted slow path traffic to detect and block the 847 outgoing DDoS attack traffic or quarantine the device (e.g., using 848 MAC level filtering) until it is remediated, and notifies the CPE 849 administrator about the compromised device. Note that the Call Home 850 DOTS client is informed about the progress of the attack mitigation 851 following the rules in Section 4.4.2 of [I-D.ietf-dots-rfc8782-bis]. 853 The DOTS agents follow the same procedures specified in 854 [I-D.ietf-dots-rfc8782-bis] for managing a mitigation request. 856 5.3.2. Address Sharing Considerations 858 Figure 10 depictes an example of a network provider that hosts a Call 859 Home DOTS client and deploys a Carrier Grade NAT (CGN) between the 860 DOTS client domain and DOTS server domain. In such cases, 861 communicating an external IP address in a mitigation request by a 862 Call Home DOTS client is likely to be discarded by the Call Home DOTS 863 server because the external IP address is not visible locally to the 864 Call Home DOTS server (Figure 10). The Call Home DOTS server is only 865 aware of the internal IP addresses/prefixes bound to its domain 866 (i.e., those used in the Internal Realm shown in Figure 10). Thus, 867 Call Home DOTS clients that are aware of the presence of on-path CGNs 868 MUST NOT include the external IP address and/or port number 869 identifying the suspect attack source (i.e., those used in the 870 External Realm shown in Figure 10), but MUST include the internal IP 871 address and/or port number. To that aim, the Call Home DOTS client 872 SHOULD rely on mechanisms, such as [RFC8512] or [RFC8513], to 873 retrieve the internal IP address and port number which are mapped to 874 an external IP address and port number. For the particular case of 875 NAT64 [RFC6146], if the target address is an IPv4 address, the 876 IPv4-converted IPv6 address of this target address [RFC6052] SHOULD 877 be used. 879 N | .-------------------. 880 E | ( )-. 881 T | .' ' 882 W | ( Call Home ) 883 O | ( DOTS client -' 884 R | '-( ) 885 K | '-------+-----------' 886 | | 887 P | | 888 R | +---+---+ 889 O | | CGN | External Realm 890 V |..............| |...................... 891 I | | | Internal Realm 892 D | +---+---+ 893 E | | 894 R | | 895 --- | 896 .---------+---------. 897 ( )-. 898 .' Source Network ' 899 ( ) 900 ( Call Home -' 901 '-( DOTS server ) 902 '------+------------' 903 | 904 +-----+-------+ 905 |Attack Source| 906 +-------------+ 908 Figure 10: Example of a CGN between DOTS Domains 910 If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the 911 provider's domain to service its customers, the identification of an 912 attack source bound to an IPv4 address/prefix MUST also rely on 913 source port numbers because the same IPv4 address is assigned to 914 multiple customers. The port information is required to 915 unambiguously identify the source of an attack. 917 If a translator is enabled on the boundaries of the domain hosting 918 the Call Home DOTS server (e.g., a CPE with NAT enabled as shown in 919 Figures 11 and 12), the Call Home DOTS server uses the attack traffic 920 information conveyed in a mitigation request to find the internal 921 source IP address of the compromised device and blocks the traffic 922 from the compromised device traffic to the attack target until the 923 mitigation request is withdrawn. The Call Home DOTS server proceeds 924 with a NAT mapping table lookup using the attack information (or a 925 subset thereof) as a key. The lookup can be local (Figure 11) or via 926 a dedicated administration interface that is offered by the CPE 927 (Figure 12). This identification allows the suspicious device to be 928 isolated while avoiding disturbances of other services. 930 .-------------------. 931 ( )-. 932 .' Network Provider (DMS)' 933 ( ) 934 ( Call Home -' 935 '-( DOTS client ) 936 '-------+-----------' 937 | 938 --- +---+---+ 939 S | | CPE | External Realm 940 O |..............| |................ 941 U | | NAT | Internal Realm 942 R | +---+---+ 943 C | | 944 E | .---------+---------. 945 | ( )-. 946 N | .' ' 947 E | ( Call Home ) 948 T | ( DOTS server -' 949 W | '-( ) 950 O | '-------+-----------' 951 R | | 952 K | +------+------+ 953 | |Attack Source| 954 +-------------+ 956 Figure 11: Example of a DOTS Server Domain with a NAT Embedded in a 957 CPE 959 .-------------------. 960 ( )-. 961 .' Network Provider (DMS) ' 962 ( ) 963 ( Call Home -' 964 '-( DOTS client ) 965 '---------+---------' 966 | 967 --- +-----+-----+ 968 S | | CPE/NAT | External Realm 969 O |..............| |................ 970 U | | Call Home | Internal Realm 971 R | |DOTS server| 972 C | +-----+-----+ 973 E | | 974 | .-----------+-------. 975 | ( )-. 976 N | .' ' 977 E | ( Local Area Network ) 978 T | ( -' 979 W | '-( ) 980 O | '--------+----------' 981 R | | 982 K | +------+------+ 983 | |Attack Source| 984 +-------------+ 986 Figure 12: Example of a Call Home DOTS Server and a NAT Embedded in a 987 CPE 989 If for any reason address sharing is deployed in both source and 990 provider networks, both Call Home DOTS agents have to proceed with 991 address mapping lookups following the behavior specified in reference 992 to Figure 10 (network provider) and Figures 11 and 12 (source 993 network). 995 6. DOTS Signal Call Home YANG Module 997 6.1. Tree Structure 999 This document augments the "ietf-dots-signal-channel" (dots-signal) 1000 DOTS signal YANG module defined in [I-D.ietf-dots-rfc8782-bis] for 1001 signaling the attack traffic information. This document defines the 1002 YANG module "ietf-dots-call-home", which has the following tree 1003 structure: 1005 module: ietf-dots-call-home 1007 augment-structure /dots-signal:dots-signal/dots-signal:message-type 1008 /dots-signal:mitigation-scope/dots-signal:scope: 1009 +-- source-prefix* inet:ip-prefix 1010 +-- source-port-range* [lower-port] 1011 | +-- lower-port inet:port-number 1012 | +-- upper-port? inet:port-number 1013 +-- source-icmp-type-range* [lower-type] 1014 +-- lower-type uint8 1015 +-- upper-type? uint8 1016 augment-structure /dots-signal:dots-signal/dots-signal:message-type 1017 /dots-signal:redirected-signal: 1018 +-- (type)? 1019 +--:(call-home-only) 1020 +-- alt-ch-client string 1021 +-- alt-ch-client-record* inet:ip-address 1022 +-- ttl? uint32 1024 6.2. YANG/JSON Mapping Parameters to CBOR 1026 The YANG/JSON mapping parameters to CBOR are listed in Table 1. 1028 o Note: Implementers must check that the mapping output provided by 1029 their YANG-to-CBOR encoding schemes is aligned with the content of 1030 Table 1. 1032 +--------------------+------------+------+---------------+--------+ 1033 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 1034 | | Type | Key | Type & | Type | 1035 | | | | Information | | 1036 +====================+============+======+===============+========+ 1037 |ietf-dots-call-home:| leaf-list | | | | 1038 | source-prefix | inet: | TBA1 | 4 array | Array | 1039 | | ip-prefix | | 3 text string | String | 1040 +--------------------+------------+------+---------------+--------+ 1041 |ietf-dots-call-home:| | | | | 1042 | source-port-range | list | TBA2 | 4 array | Array | 1043 +--------------------+------------+------+---------------+--------+ 1044 |ietf-dots-call-home:| | | | | 1045 | source-icmp-type- | list | TBA3 | 4 array | Array | 1046 | range | | | | | 1047 +--------------------+------------+------+---------------+--------+ 1048 | lower-type | uint8 | TBA4 | 0 unsigned | Number | 1049 +--------------------+------------+------+---------------+--------+ 1050 | upper-type | uint8 | TBA5 | 0 unsigned | Number | 1051 +--------------------+------------+------+---------------+--------+ 1052 |ietf-dots-call-home:| | | | | 1053 | alt-ch-client | string | TBA6 | 3 text string | String | 1054 +--------------------+------------+------+---------------+--------+ 1055 |ietf-dots-call-home:| leaf-list | TBA7 | 4 array | Array | 1056 | alt-ch-client- | inet: | | | | 1057 | record | ip-address| | 3 text string | String | 1058 +--------------------+------------+------+---------------+--------+ 1059 |ietf-dots-call-home:| | | | | 1060 | ttl | uint32 | TBA8 | 0 unsigned | Number | 1061 +--------------------+------------+------+---------------+--------+ 1063 Table 1: YANG/JSON Mapping Parameters to CBOR 1065 The YANG/JSON mappings to CBOR for 'lower-port' and 'upper-port' are 1066 already defined in Table 5 of [I-D.ietf-dots-rfc8782-bis]. 1068 6.3. YANG Module 1070 This module uses the common YANG types defined in [RFC6991] and the 1071 data structure extension defined in [RFC8791]. 1073 file "ietf-dots-call-home@2020-10-15.yang" 1074 module ietf-dots-call-home { 1075 yang-version 1.1; 1076 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home"; 1077 prefix dots-call-home; 1079 import ietf-inet-types { 1080 prefix inet; 1081 reference 1082 "Section 4 of RFC 6991"; 1083 } 1084 import ietf-dots-signal-channel { 1085 prefix dots-signal; 1086 reference 1087 "RFC YYYY: Distributed Denial-of-Service Open Threat 1088 Signaling (DOTS) Signal Channel Specification"; 1089 } 1090 import ietf-yang-structure-ext { 1091 prefix sx; 1092 reference 1093 "RFC 8791: YANG Data Structure Extensions"; 1094 } 1096 organization 1097 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 1098 contact 1099 "WG Web: 1100 WG List: 1102 Author: Konda, Tirumaleswar Reddy 1103 ; 1105 Author: Mohamed Boucadair 1106 ; 1108 Author: Jon Shallow 1109 "; 1110 description 1111 "This module contains YANG definitions for the signaling 1112 messages exchanged between a DOTS client and a DOTS server 1113 for the Call Home deployment scenario. 1115 Copyright (c) 2020 IETF Trust and the persons identified as 1116 authors of the code. All rights reserved. 1118 Redistribution and use in source and binary forms, with or 1119 without modification, is permitted pursuant to, and subject 1120 to the license terms contained in, the Simplified BSD License 1121 set forth in Section 4.c of the IETF Trust's Legal Provisions 1122 Relating to IETF Documents 1123 (http://trustee.ietf.org/license-info). 1125 This version of this YANG module is part of RFC XXXX; see 1126 the RFC itself for full legal notices."; 1128 revision 2020-10-15 { 1129 description 1130 "Initial revision."; 1131 reference 1132 "RFC XXXX: Distributed Denial-of-Service Open Threat 1133 Signaling (DOTS) Signal Channel Call Home"; 1134 } 1135 sx:augment-structure "/dots-signal:dots-signal" 1136 + "/dots-signal:message-type" 1137 + "/dots-signal:mitigation-scope" 1138 + "/dots-signal:scope" { 1139 description 1140 "Attack source details."; 1141 leaf-list source-prefix { 1142 type inet:ip-prefix; 1143 description 1144 "IPv4 or IPv6 prefix identifying the attack source(s)."; 1145 } 1146 list source-port-range { 1147 key "lower-port"; 1148 description 1149 "Port range. When only lower-port is 1150 present, it represents a single port number."; 1151 leaf lower-port { 1152 type inet:port-number; 1153 mandatory true; 1154 description 1155 "Lower port number of the port range."; 1156 } 1157 leaf upper-port { 1158 type inet:port-number; 1159 must '. >= ../lower-port' { 1160 error-message 1161 "The upper port number must be greater than 1162 or equal to lower port number."; 1163 } 1164 description 1165 "Upper port number of the port range."; 1166 } 1167 } 1168 list source-icmp-type-range { 1169 key "lower-type"; 1170 description 1171 "ICMP/ICMPv6 type range. When only lower-type is 1172 present, it represents a single ICMP/ICMPv6 type. 1174 The address family of the target-prefix is used 1175 to determine whether ICMP or ICMPv6 are used."; 1177 leaf lower-type { 1178 type uint8; 1179 mandatory true; 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 string; 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: IESG 1273 Contact: IETF Chair 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 IESG. 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. 1382 An attacker may launch a DoS attack on the DOTS client by having it 1383 perform computationally expensive operations, before deducing that 1384 the attacker doesn't possess a valid key. For instance, in TLS 1.3 1385 [RFC8446], the ServerHello message contains a Key Share value based 1386 on an expensive asymmetric key operation for key establishment. 1387 Common precautions mitigating DoS attacks are recommended, such as 1388 temporarily adding to a drop-list the source address after a set 1389 number of unsuccessful authentication attempts. 1391 The DOTS Call Home can be misused by a misbehaving Call Home DOTS 1392 client by arbitrarily signalling legitimate traffic as being attack 1393 traffic or falsifying mitigation signals so that some sources are 1394 disconnected or some traffic is rate-limited. Such misbehaving Call 1395 Home DOTS clients may include sources identified by IP addresses that 1396 are used for internal use only (that is, these addresses are not 1397 visible outside a Call Home DOTS server domain). Absent explicit 1398 policy (e.g., the Call Home DOTS client and server are managed by the 1399 same administrative entity), such requests should be discarded by the 1400 Call Home DOTS server. More generally, Call Home DOTS servers should 1401 not blindly trust mitigation requests from Call Home DOTS clients. 1402 For example, Call Home DOTS servers could use the attack flow 1403 information contained in a mitigation request to enable a full- 1404 fledged packet inspection function to inspect all the traffic from 1405 the compromised device to the target, or could re-direct the traffic 1406 from the potentially compromised device to the target towards a DDoS 1407 mitigation system that can scrub the suspicious traffic, without 1408 blindly blocking all traffic from the indicated attack source to the 1409 target. Call Home DOTS servers can also seek the consent of DOTS 1410 server domain administrator to block the traffic from the potentially 1411 compromised device to the target (see Section 5.3.1). 1413 Call Home DOTS agents may interact with on-path address sharing 1414 functions to retrieve an internal IP addresss/external IP address 1415 mapping (Section 5.3.2) identifying an attack source. Blocking 1416 access or manipulating the mapping information will complicate DDoS 1417 attack mitigation close to an attack source. Additional security 1418 considerations are specific to the actual mechanism used to access 1419 that mapping (refer, e.g., to Section 4 of [RFC8512] or Section 4 of 1420 [RFC8513]). 1422 9. Privacy Considerations 1424 The considerations discussed in [RFC6973] were taken into account to 1425 assess whether the DOTS Call Home introduces privacy threats. 1427 Concretely, the protocol does not leak any new information that can 1428 be used to ease surveillance. In particular, the Call Home DOTS 1429 server is not required to share information that is local to its 1430 network (e.g., internal identifiers of an attack source) with the 1431 Call Home DOTS client. Also, the recommended data to be included in 1432 Call Home DOTS messages is a subset of the Layer 3/Layer 4 1433 information that can be learnt from the overall traffic flows that 1434 exit the Call Home DOTS server domain. Furthermore, Call Home DOTS 1435 clients do not publicly reveal attack identification information; 1436 that information is encrypted and only shared with an authorized 1437 entity in the domain to which the IP address/prefix is assigned, from 1438 which an attack was issued. 1440 The DOTS Call Home does not preclude the validation of mitigation 1441 requests received from a Call Home DOTS client. For example, a 1442 security service running on the CPE may require an administrator's 1443 consent before the CPE acts upon the mitigation request indicated by 1444 the Call Home DOTS client. How the consent is obtained is out of 1445 scope of this document. 1447 Note that a Call Home DOTS server can seek an administrator's 1448 consent, validate the request by inspecting the relevant traffic for 1449 attack signatures, or proceed with both courses of action. 1451 The DOTS Call Home is only advisory in nature. Concretely, the DOTS 1452 Call Home does not impose any action to be enforced within the 1453 network hosting an attack source; it is up to the Call Home DOTS 1454 server (and/or network administrator) to decide whether and which 1455 actions are required. 1457 Moreover, the DOTS Call Home avoids misattribution by appropriately 1458 identifying the network to which a suspect attack source belongs to 1459 (e.g., address sharing issues discussed in Section 5.3.1). 1461 Triggers to send a DOTS mitigation request to a Call Home DOTS server 1462 are deployment-specific. For example, a Call Home DOTS client may 1463 rely on the output of some DDoS detection systems (flow exports or 1464 similar functions) deployed within the DOTS client domain to detect 1465 potential outbound DDoS attacks or on abuse claims received from 1466 remote victim networks. These systems may be misused to track users 1467 and infer their activities. Such misuses are not required to achieve 1468 the functionality defined in this document (that is, protect the 1469 Internet and avoid altering the IP reputation of source networks). 1470 It is out of the scope to identify privacy threats specific to a 1471 given attack detection technology. The reader may refer, for 1472 example, to Section 11.8 of [RFC7011]. 1474 10. Contributors 1476 The following individuals have contributed to this document: 1478 Joshi Harsha 1479 McAfee, Inc. 1480 Embassy Golf Link Business Park 1481 Bangalore, Karnataka 560071 1482 India 1484 Email: harsha_joshi@mcafee.com 1486 Wei Pan 1487 Huawei Technologies 1488 China 1490 Email: william.panwei@huawei.com 1492 11. Acknowledgements 1494 Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Toema 1495 Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments. 1497 Benjamin Kaduk's AD review is valuable. Many thanks to him for the 1498 detailed review. 1500 12. References 1502 12.1. Normative References 1504 [I-D.ietf-dots-rfc8782-bis] 1505 Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed 1506 Denial-of-Service Open Threat Signaling (DOTS) Signal 1507 Channel Specification", draft-ietf-dots-rfc8782-bis-01 1508 (work in progress), September 2020. 1510 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1511 RFC 792, DOI 10.17487/RFC0792, September 1981, 1512 . 1514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1515 Requirement Levels", BCP 14, RFC 2119, 1516 DOI 10.17487/RFC2119, March 1997, 1517 . 1519 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1520 DOI 10.17487/RFC3688, January 2004, 1521 . 1523 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1524 Control Message Protocol (ICMPv6) for the Internet 1525 Protocol Version 6 (IPv6) Specification", STD 89, 1526 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1527 . 1529 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1530 the Network Configuration Protocol (NETCONF)", RFC 6020, 1531 DOI 10.17487/RFC6020, October 2010, 1532 . 1534 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1535 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1536 DOI 10.17487/RFC6052, October 2010, 1537 . 1539 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1540 NAT64: Network Address and Protocol Translation from IPv6 1541 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1542 April 2011, . 1544 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1545 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1546 January 2012, . 1548 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1549 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1550 . 1552 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1553 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1554 May 2017, . 1556 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1557 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1558 . 1560 [RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data 1561 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 1562 June 2020, . 1564 12.2. Informative References 1566 [Cause] IANA, "DOTS Signal Channel Conflict Cause Codes", 1567 . 1570 [I-D.ietf-dots-multihoming] 1571 Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing 1572 Deployment Considerations for Distributed-Denial-of- 1573 Service Open Threat Signaling (DOTS)", draft-ietf-dots- 1574 multihoming-04 (work in progress), May 2020. 1576 [I-D.ietf-dots-server-discovery] 1577 Boucadair, M. and T. Reddy.K, "Distributed-Denial-of- 1578 Service Open Threat Signaling (DOTS) Agent Discovery", 1579 draft-ietf-dots-server-discovery-12 (work in progress), 1580 October 2020. 1582 [I-D.ietf-dots-use-cases] 1583 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 1584 L., and K. Nishizuka, "Use cases for DDoS Open Threat 1585 Signaling", draft-ietf-dots-use-cases-25 (work in 1586 progress), July 2020. 1588 [I-D.ietf-i2nsf-terminology] 1589 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1590 Birkholz, "Interface to Network Security Functions (I2NSF) 1591 Terminology", draft-ietf-i2nsf-terminology-08 (work in 1592 progress), July 2019. 1594 [I-D.ietf-idr-flow-spec-v6] 1595 Loibl, C., Raszuk, R., and S. Hares, "Dissemination of 1596 Flow Specification Rules for IPv6", draft-ietf-idr-flow- 1597 spec-v6-16 (work in progress), October 2020. 1599 [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", 1600 . 1603 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1604 Translator (NAT) Terminology and Considerations", 1605 RFC 2663, DOI 10.17487/RFC2663, August 1999, 1606 . 1608 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1609 Congestion Control Protocol (DCCP)", RFC 4340, 1610 DOI 10.17487/RFC4340, March 2006, 1611 . 1613 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1614 (CIDR): The Internet Address Assignment and Aggregation 1615 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1616 2006, . 1618 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1619 Denial-of-Service Considerations", RFC 4732, 1620 DOI 10.17487/RFC4732, December 2006, 1621 . 1623 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1624 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1625 . 1627 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1628 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1629 . 1631 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1632 and D. McPherson, "Dissemination of Flow Specification 1633 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1634 . 1636 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 1637 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 1638 2011, . 1640 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1641 Morris, J., Hansen, M., and R. Smith, "Privacy 1642 Considerations for Internet Protocols", RFC 6973, 1643 DOI 10.17487/RFC6973, July 2013, 1644 . 1646 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 1647 "Specification of the IP Flow Information Export (IPFIX) 1648 Protocol for the Exchange of Flow Information", STD 77, 1649 RFC 7011, DOI 10.17487/RFC7011, September 2013, 1650 . 1652 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1653 Farrer, "Lightweight 4over6: An Extension to the Dual- 1654 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 1655 July 2015, . 1657 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 1658 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 1659 Port with Encapsulation (MAP-E)", RFC 7597, 1660 DOI 10.17487/RFC7597, July 2015, 1661 . 1663 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1664 RFC 8071, DOI 10.17487/RFC8071, February 2017, 1665 . 1667 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1668 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1669 . 1671 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1672 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1673 Address Translation (NAT) and Network Prefix Translation 1674 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1675 . 1677 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 1678 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 1679 DOI 10.17487/RFC8513, January 2019, 1680 . 1682 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 1683 Jacquenet, "An Inventory of Transport-Centric Functions 1684 Provided by Middleboxes: An Operator Perspective", 1685 RFC 8517, DOI 10.17487/RFC8517, February 2019, 1686 . 1688 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 1689 Things (IoT) Security: State of the Art and Challenges", 1690 RFC 8576, DOI 10.17487/RFC8576, April 2019, 1691 . 1693 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 1694 Threat Signaling (DOTS) Requirements", RFC 8612, 1695 DOI 10.17487/RFC8612, May 2019, 1696 . 1698 [Sec-by-design] 1699 UK Department for Digital Culture, Media & Sport, "Secure 1700 by Design: Improving the cyber security of consumer 1701 Internet of Things Report", March 2018, 1702 . 1705 [ServicePorts] 1706 IANA, "Service Name and Transport Protocol Port Number 1707 Registry", . 1710 Appendix A. Disambiguating Base DOTS Signal vs. DOTS Call Home 1712 With the DOTS signal channel Call Home, there is a chance that two 1713 DOTS agents can simultaneously establish two DOTS signal channels 1714 with different directions (base DOTS signal channel and DOTS signal 1715 channel Call Home). Here is one example drawn from the home network. 1716 Nevertheless, the outcome of the discussion is not specific to these 1717 networks, but applies to any DOTS Call Home scenario. 1719 In the Call Home scenario, the Call Home DOTS server in, for example, 1720 the home network can mitigate the DDoS attacks launched by the 1721 compromised device in its domain by receiving the mitigation request 1722 sent by the Call Home DOTS client in the ISP environment. In 1723 addition, the DOTS client in the home network can initiate a 1724 mitigation request to the DOTS server in the ISP environment to ask 1725 for help when the home network is under a DDoS attack. Such Call 1726 Home DOTS server and DOTS client in the home network can co-locate in 1727 the same home network element (e.g., the Customer Premises 1728 Equipment). In this case, with the same peer at the same time the 1729 home network element will have the base DOTS signal channel defined 1730 in [I-D.ietf-dots-rfc8782-bis] and the DOTS signal channel Call Home 1731 defined in this specification. Thus, these two signal channels need 1732 to be distinguished when they are both supported. Two approaches 1733 have been considered for distinguishing the two DOTS signal channels, 1734 but only the one that using the dedicated port number has been chosen 1735 as the best choice. 1737 By using a dedicated port number for each, these two signal channels 1738 can be separated unambiguously and easily. For example, the CPE uses 1739 the port number 4646 allocated in [I-D.ietf-dots-rfc8782-bis] to 1740 initiate the basic signal channel to the ISP when it acts as the DOTS 1741 client, and uses the port number TBD to initiate the signal channel 1742 Call Home. Based on the different port numbers, the ISP can directly 1743 decide which kind of procedures should follow immediately after it 1744 receives the DOTS messages. This approach just requires two (D)TLS 1745 sessions to be established respectively for the basic signal channel 1746 and signal channel Call Home. 1748 The other approach is signaling the role of each DOTS agent (e.g., by 1749 using the DOTS data channel as depicted in Figure 13). For example, 1750 the DOTS agent in the home network first initiates a DOTS data 1751 channel to the peer DOTS agent in the ISP environment, at this time 1752 the DOTS agent in the home network is the DOTS client and the peer 1753 DOTS agent in the ISP environment is the DOTS server. After that, 1754 the DOTS agent in the home network retrieves the DOTS Call Home 1755 capability of the peer DOTS agent. If the peer supports the DOTS 1756 Call Home, the DOTS agent needs to subscribe to the peer to use this 1757 extension. Then, the reversal of DOTS role can be recognized as done 1758 by both DOTS agents. When the DOTS agent in the ISP environment, 1759 which now is the DOTS client, wants to filter the attackers' traffic, 1760 it requests the DOTS agent in the home network, which now is the DOTS 1761 server, for help. 1763 augment /ietf-data:dots-data/ietf-data:capabilities: 1764 +--ro call-home-support? boolean 1765 augment /ietf-data:dots-data/ietf-data:dots-client: 1766 +--rw call-home-enable? boolean 1768 Figure 13: Example of DOTS Data Channel Augmentation 1770 Signaling the role will complicate the DOTS protocols, and this 1771 complexity is not required in context where the DOTS Call Home is not 1772 required or only when the DOTS Call Home is needed. Besides, the 1773 DOTS data channel may not work during attack time. Even if changing 1774 the above example from using the DOTS data channel to the DOTS signal 1775 channel, the more procedures will still reduce the efficiency. Using 1776 the dedicated port number is much easier and more concise compared to 1777 the second approach, and its cost that establishing two (D)TLS 1778 sessions is much less. So, using a dedicated port number for the 1779 DOTS Call Home is chosen in this specification. 1781 Authors' Addresses 1783 Tirumaleswar Reddy 1784 McAfee, Inc. 1785 Embassy Golf Link Business Park 1786 Bangalore, Karnataka 560071 1787 India 1789 Email: kondtir@gmail.com 1791 Mohamed Boucadair 1792 Orange 1793 Rennes 35000 1794 France 1796 Email: mohamed.boucadair@orange.com 1797 Jon Shallow 1798 UK 1800 Email: supjps-ietf@jpshallow.com