idnits 2.17.1 draft-ietf-dots-signal-call-home-10.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 1016 has weird spacing: '...er-port ine...' == Line 1019 has weird spacing: '...er-type uin...' -- The document date (October 22, 2020) is 1254 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 1332, 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 25, 2021 Orange 6 J. Shallow 7 October 22, 2020 9 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 10 Channel Call Home 11 draft-ietf-dots-signal-call-home-10 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 25, 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 . . . . . . . . . . . . . . . . . 30 109 7.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 31 110 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 111 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33 112 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 113 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 114 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 115 12.1. Normative References . . . . . . . . . . . . . . . . . . 34 116 12.2. Informative References . . . . . . . . . . . . . . . . . 36 117 Appendix A. Disambiguating Base DOTS Signal vs. DOTS Call Home . 39 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 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). 'target-prefix' 746 attribute MUST be included in the mitigation request signaling the 747 attack information to a Call Home DOTS server. The 'target-uri' or 748 'target-fqdn' parameters can be included in a mitigation request for 749 diagnostic purposes to notify the Call Home DOTS server domain 750 administrator, but SHOULD NOT be used to determine the target IP 751 addresses. 'alias-name' is unlikely to be conveyed in a Call Home 752 mitigation request given that a target may be any IP resource and 753 that there is no incentive for a Call Home DOTS server (embedded, for 754 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 Call Home DOTS server rejects the mitigation request without 831 waiting for a consent from the Call Home DOTS server domain 832 administrator, the 'conflict-cause' set to '4' is returned in 4.09 833 (Conflict) sent back to the Call Home DOTS client. 835 If the attack traffic information is identified by the Call Home DOTS 836 server or the Call Home DOTS server domain administrator as 837 legitimate traffic, the mitigation request is rejected with a 4.09 838 (Conflict) or a notification message with the 'conflict-clause' 839 (Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis]) set to the following 840 new value: 842 4: Mitigation request rejected. This code is returned by the DOTS 843 server to indicate the attack traffic has been classified as 844 legitimate traffic. 846 Once the request is validated by the Call Home DOTS server, 847 appropriate actions are enforced to block the attack traffic within 848 the source network. For example, if the Call Home DOTS server is 849 embedded in a CPE, it can program the packet processor to punt all 850 the traffic from the compromised device to the target to slow path. 851 The CPE inspects the punted slow path traffic to detect and block the 852 outgoing DDoS attack traffic or quarantine the device (e.g., using 853 MAC level filtering) until it is remediated, and notifies the CPE 854 administrator about the compromised device. Note that the Call Home 855 DOTS client is informed about the progress of the attack mitigation 856 following the rules in Section 4.4.2 of [I-D.ietf-dots-rfc8782-bis]. 858 The DOTS agents follow the same procedures specified in 859 [I-D.ietf-dots-rfc8782-bis] for managing a mitigation request. 861 5.3.2. Address Sharing Considerations 863 Figure 10 depictes an example of a network provider that hosts a Call 864 Home DOTS client and deploys a Carrier Grade NAT (CGN) between the 865 DOTS client domain and DOTS server domain. In such case, 866 communicating an external IP address in a mitigation request by a 867 Call Home DOTS client is likely to be discarded by the Call Home DOTS 868 server because the external IP address is not visible locally to the 869 Call Home DOTS server (Figure 10). The Call Home DOTS server is only 870 aware of the internal IP addresses/prefixes bound to its domain 871 (i.e., those used in the Internal Realm shown in Figure 10). Thus, 872 Call Home DOTS clients that are aware of the presence of on-path CGNs 873 MUST NOT include the external IP address and/or port number 874 identifying the suspect attack source (i.e., those used in the 875 External Realm shown in Figure 10), but MUST include the internal IP 876 address and/or port number. To that aim, the Call Home DOTS client 877 SHOULD rely on mechanisms, such as [RFC8512] or [RFC8513], to 878 retrieve the internal IP address and port number which are mapped to 879 an external IP address and port number. For the particular case of 880 NAT64 [RFC6146], if the target address is an IPv4 address, the 881 IPv4-converted IPv6 address of this target address [RFC6052] SHOULD 882 be used. 884 N | .-------------------. 885 E | ( )-. 886 T | .' ' 887 W | ( Call Home ) 888 O | ( DOTS client -' 889 R | '-( ) 890 K | '-------+-----------' 891 | | 892 P | | 893 R | +---+---+ 894 O | | CGN | External Realm 895 V |..............| |...................... 896 I | | | Internal Realm 897 D | +---+---+ 898 E | | 899 R | | 900 --- | 901 .---------+---------. 902 ( )-. 903 .' Source Network ' 904 ( ) 905 ( Call Home -' 906 '-( DOTS server ) 907 '------+------------' 908 | 909 +-----+-------+ 910 |Attack Source| 911 +-------------+ 913 Figure 10: Example of a CGN between DOTS Domains 915 If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the 916 provider's domain to service its customers, the identification of an 917 attack source bound to an IPv4 address/prefix MUST also rely on 918 source port numbers because the same IPv4 address is assigned to 919 multiple customers. The port information is required to 920 unambiguously identify the source of an attack. 922 If a translator is enabled on the boundaries of the domain hosting 923 the Call Home DOTS server (e.g., a CPE with NAT enabled as shown in 924 Figures 11 and 12), the Call Home DOTS server uses the attack traffic 925 information conveyed in a mitigation request to find the internal 926 source IP address of the compromised device and blocks the traffic 927 from the compromised device traffic to the attack target until the 928 mitigation request is withdrawn. The Call Home DOTS server proceeds 929 with a NAT mapping table lookup using the attack information (or a 930 subset thereof) as a key. The lookup can be local (Figure 11) or via 931 a dedicated administration interface that is offered by the CPE 932 (Figure 12). This identification allows the suspicious device to be 933 isolated while avoiding disturbances of other services. 935 .-------------------. 936 ( )-. 937 .' Network Provider (DMS)' 938 ( ) 939 ( Call Home -' 940 '-( DOTS client ) 941 '-------+-----------' 942 | 943 --- +---+---+ 944 S | | CPE | External Realm 945 O |..............| |................ 946 U | | NAT | Internal Realm 947 R | +---+---+ 948 C | | 949 E | .---------+---------. 950 | ( )-. 951 N | .' ' 952 E | ( Call Home ) 953 T | ( DOTS server -' 954 W | '-( ) 955 O | '-------+-----------' 956 R | | 957 K | +------+------+ 958 | |Attack Source| 959 +-------------+ 961 Figure 11: Example of a DOTS Server Domain with a NAT Embedded in a 962 CPE 964 .-------------------. 965 ( )-. 966 .' Network Provider (DMS) ' 967 ( ) 968 ( Call Home -' 969 '-( DOTS client ) 970 '---------+---------' 971 | 972 --- +-----+-----+ 973 S | | CPE/NAT | External Realm 974 O |..............| |................ 975 U | | Call Home | Internal Realm 976 R | |DOTS server| 977 C | +-----+-----+ 978 E | | 979 | .-----------+-------. 980 | ( )-. 981 N | .' ' 982 E | ( Local Area Network ) 983 T | ( -' 984 W | '-( ) 985 O | '--------+----------' 986 R | | 987 K | +------+------+ 988 | |Attack Source| 989 +-------------+ 991 Figure 12: Example of a Call Home DOTS Server and a NAT Embedded in a 992 CPE 994 If for any reason address sharing is deployed in both source and 995 provider networks, both Call Home DOTS agents have to proceed with 996 address mapping lookups following the behavior specified in reference 997 to Figure 10 (network provider) and Figures 11 and 12 (source 998 network). 1000 6. DOTS Signal Call Home YANG Module 1002 6.1. Tree Structure 1004 This document augments the "ietf-dots-signal-channel" (dots-signal) 1005 DOTS signal YANG module defined in [I-D.ietf-dots-rfc8782-bis] for 1006 signaling the attack traffic information. This document defines the 1007 YANG module "ietf-dots-call-home", which has the following tree 1008 structure: 1010 module: ietf-dots-call-home 1012 augment-structure /dots-signal:dots-signal/dots-signal:message-type 1013 /dots-signal:mitigation-scope/dots-signal:scope: 1014 +-- source-prefix* inet:ip-prefix 1015 +-- source-port-range* [lower-port] 1016 | +-- lower-port inet:port-number 1017 | +-- upper-port? inet:port-number 1018 +-- source-icmp-type-range* [lower-type] 1019 +-- lower-type uint8 1020 +-- upper-type? uint8 1021 augment-structure /dots-signal:dots-signal/dots-signal:message-type 1022 /dots-signal:redirected-signal: 1023 +-- (type)? 1024 +--:(call-home-only) 1025 +-- alt-ch-client string 1026 +-- alt-ch-client-record* inet:ip-address 1027 +-- ttl? uint32 1029 6.2. YANG/JSON Mapping Parameters to CBOR 1031 The YANG/JSON mapping parameters to CBOR are listed in Table 1. 1033 o Note: Implementers must check that the mapping output provided by 1034 their YANG-to-CBOR encoding schemes is aligned with the content of 1035 Table 1. 1037 +--------------------+------------+------+---------------+--------+ 1038 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 1039 | | Type | Key | Type & | Type | 1040 | | | | Information | | 1041 +====================+============+======+===============+========+ 1042 |ietf-dots-call-home:| leaf-list | | | | 1043 | source-prefix | inet: | TBA1 | 4 array | Array | 1044 | | ip-prefix | | 3 text string | String | 1045 +--------------------+------------+------+---------------+--------+ 1046 |ietf-dots-call-home:| | | | | 1047 | source-port-range | list | TBA2 | 4 array | Array | 1048 +--------------------+------------+------+---------------+--------+ 1049 |ietf-dots-call-home:| | | | | 1050 | source-icmp-type- | list | TBA3 | 4 array | Array | 1051 | range | | | | | 1052 +--------------------+------------+------+---------------+--------+ 1053 | lower-type | uint8 | TBA4 | 0 unsigned | Number | 1054 +--------------------+------------+------+---------------+--------+ 1055 | upper-type | uint8 | TBA5 | 0 unsigned | Number | 1056 +--------------------+------------+------+---------------+--------+ 1057 |ietf-dots-call-home:| | | | | 1058 | alt-ch-client | string | TBA6 | 3 text string | String | 1059 +--------------------+------------+------+---------------+--------+ 1060 |ietf-dots-call-home:| leaf-list | TBA7 | 4 array | Array | 1061 | alt-ch-client- | inet: | | | | 1062 | record | ip-address| | 3 text string | String | 1063 +--------------------+------------+------+---------------+--------+ 1064 |ietf-dots-call-home:| | | | | 1065 | ttl | uint32 | TBA8 | 0 unsigned | Number | 1066 +--------------------+------------+------+---------------+--------+ 1068 Table 1: YANG/JSON Mapping Parameters to CBOR 1070 The YANG/JSON mappings to CBOR for 'lower-port' and 'upper-port' are 1071 already defined in Table 5 of [I-D.ietf-dots-rfc8782-bis]. 1073 6.3. YANG Module 1075 This module uses the common YANG types defined in [RFC6991] and the 1076 data structure extension defined in [RFC8791]. 1078 file "ietf-dots-call-home@2020-10-15.yang" 1079 module ietf-dots-call-home { 1080 yang-version 1.1; 1081 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home"; 1082 prefix dots-call-home; 1084 import ietf-inet-types { 1085 prefix inet; 1086 reference 1087 "Section 4 of RFC 6991"; 1088 } 1089 import ietf-dots-signal-channel { 1090 prefix dots-signal; 1091 reference 1092 "RFC YYYY: Distributed Denial-of-Service Open Threat 1093 Signaling (DOTS) Signal Channel Specification"; 1094 } 1095 import ietf-yang-structure-ext { 1096 prefix sx; 1097 reference 1098 "RFC 8791: YANG Data Structure Extensions"; 1099 } 1101 organization 1102 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 1103 contact 1104 "WG Web: 1105 WG List: 1107 Author: Konda, Tirumaleswar Reddy 1108 ; 1110 Author: Mohamed Boucadair 1111 ; 1113 Author: Jon Shallow 1114 "; 1115 description 1116 "This module contains YANG definitions for the signaling 1117 messages exchanged between a DOTS client and a DOTS server 1118 for the Call Home deployment scenario. 1120 Copyright (c) 2020 IETF Trust and the persons identified as 1121 authors of the code. All rights reserved. 1123 Redistribution and use in source and binary forms, with or 1124 without modification, is permitted pursuant to, and subject 1125 to the license terms contained in, the Simplified BSD License 1126 set forth in Section 4.c of the IETF Trust's Legal Provisions 1127 Relating to IETF Documents 1128 (http://trustee.ietf.org/license-info). 1130 This version of this YANG module is part of RFC XXXX; see 1131 the RFC itself for full legal notices."; 1133 revision 2020-10-15 { 1134 description 1135 "Initial revision."; 1136 reference 1137 "RFC XXXX: Distributed Denial-of-Service Open Threat 1138 Signaling (DOTS) Signal Channel Call Home"; 1139 } 1140 sx:augment-structure "/dots-signal:dots-signal" 1141 + "/dots-signal:message-type" 1142 + "/dots-signal:mitigation-scope" 1143 + "/dots-signal:scope" { 1144 description 1145 "Attack source details."; 1146 leaf-list source-prefix { 1147 type inet:ip-prefix; 1148 description 1149 "IPv4 or IPv6 prefix identifying the attack source(s)."; 1150 } 1151 list source-port-range { 1152 key "lower-port"; 1153 description 1154 "Port range. When only lower-port is 1155 present, it represents a single port number."; 1156 leaf lower-port { 1157 type inet:port-number; 1158 mandatory true; 1159 description 1160 "Lower port number of the port range."; 1161 } 1162 leaf upper-port { 1163 type inet:port-number; 1164 must '. >= ../lower-port' { 1165 error-message 1166 "The upper port number must be greater than 1167 or equal to lower port number."; 1168 } 1169 description 1170 "Upper port number of the port range."; 1171 } 1172 } 1173 list source-icmp-type-range { 1174 key "lower-type"; 1175 description 1176 "ICMP/ICMPv6 type range. When only lower-type is 1177 present, it represents a single ICMP/ICMPv6 type. 1179 The address family of the target-prefix is used 1180 to determine whether ICMP or ICMPv6 are used."; 1182 leaf lower-type { 1183 type uint8; 1184 mandatory true; 1185 description 1186 "Lower ICMP/ICMPv6 type of the ICMP type range."; 1187 reference 1188 "RFC 792: Internet Control Message Protocol 1189 RFC 4443: Internet Control Message Protocol (ICMPv6) 1190 for Internet Protocol Version 6 (IPv6) 1191 Specification."; 1192 } 1193 leaf upper-type { 1194 type uint8; 1195 must '. >= ../lower-type' { 1196 error-message 1197 "The upper ICMP/ICMPv6 type must be greater than 1198 or equal to lower ICMP type."; 1199 } 1200 description 1201 "Upper type of the ICMP type range."; 1202 reference 1203 "RFC 792: Internet Control Message Protocol 1204 RFC 4443: Internet Control Message Protocol (ICMPv6) 1205 for Internet Protocol Version 6 (IPv6) 1206 Specification."; 1207 } 1208 } 1209 } 1210 sx:augment-structure "/dots-signal:dots-signal" 1211 + "/dots-signal:message-type" 1212 + "/dots-signal:redirected-signal" { 1213 description 1214 "Augments the redirected signal to communicate an 1215 alternate Call Home DOTS client."; 1216 choice type { 1217 description 1218 "Indicates the type of the DOTS session (e.g., base 1219 DOTS signal channel, DOTS Call Home)."; 1220 case call-home-only { 1221 description 1222 "These attributes appear only in a call home signal 1223 channel message from a Call Home DOTS client 1224 to a Call Home DOTS server."; 1225 leaf alt-ch-client { 1226 type string; 1227 mandatory true; 1228 description 1229 "FQDN of an alternate Call Home DOTS client. 1231 This name is also presented as reference 1232 identifier for authentication purposes."; 1233 } 1234 leaf-list alt-ch-client-record { 1235 type inet:ip-address; 1236 description 1237 "List of IP addresses for the alternate Call 1238 Home DOTS client. 1240 If this data node is not present, a Call Home 1241 DOTS server resolves the alt-ch-client into 1242 one or more IP addresses."; 1243 } 1244 leaf ttl { 1245 type uint32; 1246 units "seconds"; 1247 description 1248 "The Time to live (TTL) of the alternate Call Home 1249 DOTS client."; 1250 reference 1251 "Section 4.6 of RFC YYYY"; 1252 } 1253 } 1254 } 1255 } 1256 } 1257 1259 7. IANA Considerations 1261 7.1. DOTS Signal Channel Call Home UDP and TCP Port Number 1263 IANA is requested to assign the port number TBD to the DOTS signal 1264 channel Call Home protocol for both UDP and TCP from the "Service 1265 Name and Transport Protocol Port Number Registry" [ServicePorts]. 1267 Service Name: dots-call-home 1268 Port Number: TBD 1269 Transport Protocol(s): TCP/UDP 1270 Description: DOTS Signal Channel Call Home Protocol. 1271 The service name is used to construct the 1272 SRV service names "_dots-call-home._udp" 1273 and "_dots-call-home._tcp" for discovering 1274 Call Home DOTS clients used to establish 1275 DOTS signal channel call home. 1276 Assignee: IESG 1277 Contact: IETF Chair 1278 Reference: RFC XXXX 1280 The assignment of port number 4647 is strongly suggested (DOTS signal 1281 channel uses port number 4646). 1283 7.2. DOTS Signal Channel CBOR Mappings Registry 1285 This specification registers the following comprehension-optional 1286 parameters (Table 2) in the IANA "DOTS Signal Channel CBOR Key 1287 Values" registry [Key-Map]. 1289 o Note to the RFC Editor: Please delete TBA1-TBA8 once CBOR keys are 1290 assigned from the 32768-49151 range. 1292 +--------------------+-------+-------+------------+---------------+ 1293 | Parameter Name | CBOR | CBOR | Change | Specification | 1294 | | Key | Major | Controller | Document(s) | 1295 | | Value | Type | | | 1296 +====================+=======+=======+============+===============+ 1297 |ietf-dots-call-home:| | | | | 1298 | source-prefix | TBA1 | 4 | IESG | [RFCXXXX] | 1299 +--------------------+-------+-------+------------+---------------+ 1300 |ietf-dots-call-home:| | | | | 1301 | source-port-range | TBA2 | 4 | IESG | [RFCXXXX] | 1302 +--------------------+-------+-------+------------+---------------+ 1303 |ietf-dots-call-home:| | | | | 1304 | source-icmp-type- | TBA3 | 4 | IESG | [RFCXXXX] | 1305 | range | | | | | 1306 +--------------------+-------+-------+------------+---------------+ 1307 | lower-type | TBA4 | 0 | IESG | [RFCXXXX] | 1308 +--------------------+-------+-------+------------+---------------+ 1309 | upper-type | TBA5 | 0 | IESG | [RFCXXXX] | 1310 +--------------------+-------+-------+------------+---------------+ 1311 |ietf-dots-call-home:| | | | | 1312 | alt-ch-client | TBA6 | 3 | IESG | [RFCXXXX] | 1313 +--------------------+-------+-------+------------+---------------+ 1314 |ietf-dots-call-home:| | | | | 1315 |alt-ch-client-record| TBA7 | 4 | IESG | [RFCXXXX] | 1316 +--------------------+-------+-------+------------+---------------+ 1317 |ietf-dots-call-home:| | | | | 1318 | ttl | TBA8 | 0 | IESG | [RFCXXXX] | 1319 +--------------------+-------+-------+------------+---------------+ 1321 Table 2: Assigned DOTS Signal Channel CBOR Key Values 1323 7.3. New DOTS Conflict Cause 1325 This document requests IANA to assign a new code from the "DOTS 1326 Signal Channel Conflict Cause Codes" registry [Cause]. 1328 +-------+----------------------------------+------------+-----------+ 1329 | Code | Label | Descriptio | Reference | 1330 | | | n | | 1331 +-------+----------------------------------+------------+-----------+ 1332 | 4 (TB | request-rejected-legitimate- | Mitigation | [RFCXXXX] | 1333 | A9) | traffic | request | | 1334 | | | rejected. | | 1335 | | | This code | | 1336 | | | is | | 1337 | | | returned | | 1338 | | | by the | | 1339 | | | DOTS | | 1340 | | | server to | | 1341 | | | indicate | | 1342 | | | the attack | | 1343 | | | traffic | | 1344 | | | has been | | 1345 | | | classified | | 1346 | | | as | | 1347 | | | legitimate | | 1348 | | | traffic. | | 1349 +-------+----------------------------------+------------+-----------+ 1351 7.4. DOTS Signal Call Home YANG Module 1353 This document requests IANA to register the following URI in the "ns" 1354 subregistry within the "IETF XML Registry" [RFC3688]: 1356 URI: urn:ietf:params:xml:ns:yang:ietf-dots-call-home 1357 Registrant Contact: The IESG. 1358 XML: N/A; the requested URI is an XML namespace. 1360 This document requests IANA to register the following YANG module in 1361 the "YANG Module Names" subregistry [RFC6020] within the "YANG 1362 Parameters" registry: 1364 name: ietf-dots-call-home 1365 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home 1366 maintained by IANA: N 1367 prefix: dots-call-home 1368 reference: RFC XXXX 1370 8. Security Considerations 1372 This document deviates from classic DOTS signal channel usage by 1373 having the DOTS server initiate the (D)TLS connection. DOTS signal 1374 channel related security considerations discussed in Section 11 of 1375 [I-D.ietf-dots-rfc8782-bis] MUST be considered. DOTS agents MUST 1376 authenticate each other using (D)TLS before a DOTS signal channel 1377 session is considered valid. 1379 The Call Home function enables a Call Home DOTS server to be 1380 reachable by only the intended Call Home DOTS client. Appropriate 1381 filters (e.g., access control lists) can be installed on the Call 1382 Home DOTS server and network between the Call Home DOTS agents so 1383 that only communications from a trusted Call Home DOTS client to the 1384 Call Home DOTS server are allowed. 1386 An attacker may launch a DoS attack on the DOTS client by having it 1387 perform computationally expensive operations, before deducing that 1388 the attacker doesn't possess a valid key. For instance, in TLS 1.3 1389 [RFC8446], the ServerHello message contains a Key Share value based 1390 on an expensive asymmetric key operation for key establishment. 1391 Common precautions mitigating DoS attacks are recommended, such as 1392 temporarily adding to a drop-list the source address after a set 1393 number of unsuccessful authentication attempts. 1395 The DOTS Call Home can be misused by a misbehaving Call Home DOTS 1396 client by arbitrarily signalling legitimate traffic as being attack 1397 traffic or falsifying mitigation signals so that some sources are 1398 disconnected or some traffic is rate-limited. Such misbehaving Call 1399 Home DOTS clients may include sources identified by IP addresses that 1400 are used for internal use only (that is, these addresses are not 1401 visible outside a Call Home DOTS server domain). Absent explicit 1402 policy (e.g., the Call Home DOTS client and server are managed by the 1403 same administrative entity), such requests should be discarded by the 1404 Call Home DOTS server. More generally, Call Home DOTS servers should 1405 not blindly trust mitigation requests from Call Home DOTS clients. 1406 For example, Call Home DOTS servers could use the attack flow 1407 information contained in a mitigation request to enable a full- 1408 fledged packet inspection function to inspect all the traffic from 1409 the compromised device to the target, or could re-direct the traffic 1410 from the potentially compromised device to the target towards a DDoS 1411 mitigation system that can scrub the suspicious traffic, without 1412 blindly blocking all traffic from the indicated attack source to the 1413 target. Call Home DOTS servers can also seek the consent of DOTS 1414 server domain administrator to block the traffic from the potentially 1415 compromised device to the target (see Section 5.3.1). 1417 Call Home DOTS agents may interact with on-path address sharing 1418 functions to retrieve an internal IP addresss/external IP address 1419 mapping (Section 5.3.2) identifying an attack source. Blocking 1420 access or manipulating the mapping information will complicate DDoS 1421 attack mitigation close to an attack source. Additional security 1422 considerations are specific to the actual mechanism used to access 1423 that mapping (refer, e.g., to Section 4 of [RFC8512] or Section 4 of 1424 [RFC8513]). 1426 9. Privacy Considerations 1428 The considerations discussed in [RFC6973] were taken into account to 1429 assess whether the DOTS Call Home introduces privacy threats. 1431 Concretely, the protocol does not leak any new information that can 1432 be used to ease surveillance. In particular, the Call Home DOTS 1433 server is not required to share information that is local to its 1434 network (e.g., internal identifiers of an attack source) with the 1435 Call Home DOTS client. Also, the recommended data to be included in 1436 Call Home DOTS messages is a subset of the Layer 3/Layer 4 1437 information that can be learnt from the overall traffic flows that 1438 exit the Call Home DOTS server domain. Furthermore, Call Home DOTS 1439 clients do not publicly reveal attack identification information; 1440 that information is encrypted and only shared with an authorized 1441 entity in the domain to which the IP address/prefix is assigned, from 1442 which an attack was issued. 1444 The DOTS Call Home does not preclude the validation of mitigation 1445 requests received from a Call Home DOTS client. For example, a 1446 security service running on the CPE may require an administrator's 1447 consent before the CPE acts upon the mitigation request indicated by 1448 the Call Home DOTS client. How the consent is obtained is out of 1449 scope of this document. 1451 Note that a Call Home DOTS server can seek an administrator's 1452 consent, validate the request by inspecting the relevant traffic for 1453 attack signatures, or proceed with both courses of action. 1455 The DOTS Call Home is only advisory in nature. Concretely, the DOTS 1456 Call Home does not impose any action to be enforced within the 1457 network hosting an attack source; it is up to the Call Home DOTS 1458 server (and/or network administrator) to decide whether and which 1459 actions are required. 1461 Moreover, the DOTS Call Home avoids misattribution by appropriately 1462 identifying the network to which a suspect attack source belongs to 1463 (e.g., address sharing issues discussed in Section 5.3.1). 1465 Triggers to send a DOTS mitigation request to a Call Home DOTS server 1466 are deployment-specific. For example, a Call Home DOTS client may 1467 rely on the output of some DDoS detection systems (flow exports or 1468 similar functions) deployed within the DOTS client domain to detect 1469 potential outbound DDoS attacks or on abuse claims received from 1470 remote victim networks. These systems may be misused to track users 1471 and infer their activities. Such misuses are not required to achieve 1472 the functionality defined in this document (that is, protect the 1473 Internet and avoid altering the IP reputation of source networks). 1474 It is out of the scope to identify privacy threats specific to a 1475 given attack detection technology. The reader may refer, for 1476 example, to Section 11.8 of [RFC7011]. 1478 10. Contributors 1480 The following individuals have contributed to this document: 1482 Joshi Harsha 1483 McAfee, Inc. 1484 Embassy Golf Link Business Park 1485 Bangalore, Karnataka 560071 1486 India 1488 Email: harsha_joshi@mcafee.com 1490 Wei Pan 1491 Huawei Technologies 1492 China 1494 Email: william.panwei@huawei.com 1496 11. Acknowledgements 1498 Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Toema 1499 Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments. 1501 Benjamin Kaduk's AD review is valuable. Many thanks to him for the 1502 detailed review. 1504 12. References 1506 12.1. Normative References 1508 [I-D.ietf-dots-rfc8782-bis] 1509 Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed 1510 Denial-of-Service Open Threat Signaling (DOTS) Signal 1511 Channel Specification", draft-ietf-dots-rfc8782-bis-01 1512 (work in progress), September 2020. 1514 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1515 RFC 792, DOI 10.17487/RFC0792, September 1981, 1516 . 1518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1519 Requirement Levels", BCP 14, RFC 2119, 1520 DOI 10.17487/RFC2119, March 1997, 1521 . 1523 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1524 DOI 10.17487/RFC3688, January 2004, 1525 . 1527 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1528 Control Message Protocol (ICMPv6) for the Internet 1529 Protocol Version 6 (IPv6) Specification", STD 89, 1530 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1531 . 1533 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1534 the Network Configuration Protocol (NETCONF)", RFC 6020, 1535 DOI 10.17487/RFC6020, October 2010, 1536 . 1538 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1539 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1540 DOI 10.17487/RFC6052, October 2010, 1541 . 1543 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1544 NAT64: Network Address and Protocol Translation from IPv6 1545 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1546 April 2011, . 1548 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1549 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1550 January 2012, . 1552 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1553 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1554 . 1556 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1557 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1558 May 2017, . 1560 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1561 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1562 . 1564 [RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data 1565 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 1566 June 2020, . 1568 12.2. Informative References 1570 [Cause] IANA, "DOTS Signal Channel Conflict Cause Codes", 1571 . 1574 [I-D.ietf-dots-multihoming] 1575 Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing 1576 Deployment Considerations for Distributed-Denial-of- 1577 Service Open Threat Signaling (DOTS)", draft-ietf-dots- 1578 multihoming-04 (work in progress), May 2020. 1580 [I-D.ietf-dots-server-discovery] 1581 Boucadair, M. and T. Reddy.K, "Distributed-Denial-of- 1582 Service Open Threat Signaling (DOTS) Agent Discovery", 1583 draft-ietf-dots-server-discovery-12 (work in progress), 1584 October 2020. 1586 [I-D.ietf-dots-use-cases] 1587 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 1588 L., and K. Nishizuka, "Use cases for DDoS Open Threat 1589 Signaling", draft-ietf-dots-use-cases-25 (work in 1590 progress), July 2020. 1592 [I-D.ietf-i2nsf-terminology] 1593 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1594 Birkholz, "Interface to Network Security Functions (I2NSF) 1595 Terminology", draft-ietf-i2nsf-terminology-08 (work in 1596 progress), July 2019. 1598 [I-D.ietf-idr-flow-spec-v6] 1599 Loibl, C., Raszuk, R., and S. Hares, "Dissemination of 1600 Flow Specification Rules for IPv6", draft-ietf-idr-flow- 1601 spec-v6-16 (work in progress), October 2020. 1603 [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", 1604 . 1607 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1608 Translator (NAT) Terminology and Considerations", 1609 RFC 2663, DOI 10.17487/RFC2663, August 1999, 1610 . 1612 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1613 Congestion Control Protocol (DCCP)", RFC 4340, 1614 DOI 10.17487/RFC4340, March 2006, 1615 . 1617 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1618 (CIDR): The Internet Address Assignment and Aggregation 1619 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1620 2006, . 1622 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1623 Denial-of-Service Considerations", RFC 4732, 1624 DOI 10.17487/RFC4732, December 2006, 1625 . 1627 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1628 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1629 . 1631 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1632 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1633 . 1635 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1636 and D. McPherson, "Dissemination of Flow Specification 1637 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1638 . 1640 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 1641 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 1642 2011, . 1644 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1645 Morris, J., Hansen, M., and R. Smith, "Privacy 1646 Considerations for Internet Protocols", RFC 6973, 1647 DOI 10.17487/RFC6973, July 2013, 1648 . 1650 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 1651 "Specification of the IP Flow Information Export (IPFIX) 1652 Protocol for the Exchange of Flow Information", STD 77, 1653 RFC 7011, DOI 10.17487/RFC7011, September 2013, 1654 . 1656 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1657 Farrer, "Lightweight 4over6: An Extension to the Dual- 1658 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 1659 July 2015, . 1661 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 1662 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 1663 Port with Encapsulation (MAP-E)", RFC 7597, 1664 DOI 10.17487/RFC7597, July 2015, 1665 . 1667 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1668 RFC 8071, DOI 10.17487/RFC8071, February 2017, 1669 . 1671 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1672 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1673 . 1675 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1676 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1677 Address Translation (NAT) and Network Prefix Translation 1678 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1679 . 1681 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 1682 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 1683 DOI 10.17487/RFC8513, January 2019, 1684 . 1686 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 1687 Jacquenet, "An Inventory of Transport-Centric Functions 1688 Provided by Middleboxes: An Operator Perspective", 1689 RFC 8517, DOI 10.17487/RFC8517, February 2019, 1690 . 1692 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 1693 Things (IoT) Security: State of the Art and Challenges", 1694 RFC 8576, DOI 10.17487/RFC8576, April 2019, 1695 . 1697 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 1698 Threat Signaling (DOTS) Requirements", RFC 8612, 1699 DOI 10.17487/RFC8612, May 2019, 1700 . 1702 [Sec-by-design] 1703 UK Department for Digital Culture, Media & Sport, "Secure 1704 by Design: Improving the cyber security of consumer 1705 Internet of Things Report", March 2018, 1706 . 1709 [ServicePorts] 1710 IANA, "Service Name and Transport Protocol Port Number 1711 Registry", . 1714 Appendix A. Disambiguating Base DOTS Signal vs. DOTS Call Home 1716 With the DOTS signal channel Call Home, there is a chance that two 1717 DOTS agents can simultaneously establish two DOTS signal channels 1718 with different directions (base DOTS signal channel and DOTS signal 1719 channel Call Home). Here is one example drawn from the home network. 1720 Nevertheless, the outcome of the discussion is not specific to these 1721 networks, but applies to any DOTS Call Home scenario. 1723 In the Call Home scenario, the Call Home DOTS server in, for example, 1724 the home network can mitigate the DDoS attacks launched by the 1725 compromised device in its domain by receiving the mitigation request 1726 sent by the Call Home DOTS client in the ISP environment. In 1727 addition, the DOTS client in the home network can initiate a 1728 mitigation request to the DOTS server in the ISP environment to ask 1729 for help when the home network is under a DDoS attack. Such Call 1730 Home DOTS server and DOTS client in the home network can co-locate in 1731 the same home network element (e.g., the Customer Premises 1732 Equipment). In this case, with the same peer at the same time the 1733 home network element will have the base DOTS signal channel defined 1734 in [I-D.ietf-dots-rfc8782-bis] and the DOTS signal channel Call Home 1735 defined in this specification. Thus, these two signal channels need 1736 to be distinguished when they are both supported. Two approaches 1737 have been considered for distinguishing the two DOTS signal channels, 1738 but only the one that using the dedicated port number has been chosen 1739 as the best choice. 1741 By using a dedicated port number for each, these two signal channels 1742 can be separated unambiguously and easily. For example, the CPE uses 1743 the port number 4646 allocated in [I-D.ietf-dots-rfc8782-bis] to 1744 initiate the basic signal channel to the ISP when it acts as the DOTS 1745 client, and uses the port number TBD to initiate the signal channel 1746 Call Home. Based on the different port numbers, the ISP can directly 1747 decide which kind of procedures should follow immediately after it 1748 receives the DOTS messages. This approach just requires two (D)TLS 1749 sessions to be established respectively for the basic signal channel 1750 and signal channel Call Home. 1752 The other approach is signaling the role of each DOTS agent (e.g., by 1753 using the DOTS data channel as depicted in Figure 13). For example, 1754 the DOTS agent in the home network first initiates a DOTS data 1755 channel to the peer DOTS agent in the ISP environment, at this time 1756 the DOTS agent in the home network is the DOTS client and the peer 1757 DOTS agent in the ISP environment is the DOTS server. After that, 1758 the DOTS agent in the home network retrieves the DOTS Call Home 1759 capability of the peer DOTS agent. If the peer supports the DOTS 1760 Call Home, the DOTS agent needs to subscribe to the peer to use this 1761 extension. Then, the reversal of DOTS role can be recognized as done 1762 by both DOTS agents. When the DOTS agent in the ISP environment, 1763 which now is the DOTS client, wants to filter the attackers' traffic, 1764 it requests the DOTS agent in the home network, which now is the DOTS 1765 server, for help. 1767 augment /ietf-data:dots-data/ietf-data:capabilities: 1768 +--ro call-home-support? boolean 1769 augment /ietf-data:dots-data/ietf-data:dots-client: 1770 +--rw call-home-enable? boolean 1772 Figure 13: Example of DOTS Data Channel Augmentation 1774 Signaling the role will complicate the DOTS protocols, and this 1775 complexity is not required in context where the DOTS Call Home is not 1776 required or only when the DOTS Call Home is needed. Besides, the 1777 DOTS data channel may not work during attack time. Even if changing 1778 the above example from using the DOTS data channel to the DOTS signal 1779 channel, the more procedures will still reduce the efficiency. Using 1780 the dedicated port number is much easier and more concise compared to 1781 the second approach, and its cost that establishing two (D)TLS 1782 sessions is much less. So, using a dedicated port number for the 1783 DOTS Call Home is chosen in this specification. 1785 Authors' Addresses 1787 Tirumaleswar Reddy 1788 McAfee, Inc. 1789 Embassy Golf Link Business Park 1790 Bangalore, Karnataka 560071 1791 India 1793 Email: kondtir@gmail.com 1795 Mohamed Boucadair 1796 Orange 1797 Rennes 35000 1798 France 1800 Email: mohamed.boucadair@orange.com 1801 Jon Shallow 1802 UK 1804 Email: supjps-ietf@jpshallow.com