idnits 2.17.1 draft-ietf-dots-signal-call-home-09.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 938 has weird spacing: '...er-port ine...' == Line 941 has weird spacing: '...er-type uin...' -- The document date (September 14, 2020) is 1313 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 1215, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-dots-rfc8782-bis-00 ** 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-10 == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-14 -- 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: March 18, 2021 Orange 6 J. Shallow 7 September 14, 2020 9 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 10 Channel Call Home 11 draft-ietf-dots-signal-call-home-09 13 Abstract 15 This document specifies the DOTS signal channel Call Home, which 16 enables a DOTS server to initiate a secure connection to a DOTS 17 client, and to receive the attack traffic information from the DOTS 18 client. The DOTS server in turn uses the attack traffic information 19 to identify the compromised devices launching the outgoing DDoS 20 attack and takes appropriate mitigation action(s). 22 The DOTS signal channel Call Home is not specific to the home 23 networks; the solution targets any deployment which requires to block 24 DDoS attack traffic closer to the source(s) of a DDoS attack. 26 Editorial Note (To be removed by RFC Editor) 28 Please update these statements within the document with the RFC 29 number to be assigned to this document: 31 o "This version of this YANG module is part of RFC XXXX;" 33 o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling 34 (DOTS) Signal Channel Call Home"; 36 o "| [RFCXXXX] |" 38 o reference: RFC XXXX 40 Please update this statement with the RFC number to be assigned to 41 the following documents: 43 o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling 44 (DOTS) Signal Channel Specification" (used to be I-D.ietf-dots- 45 rfc8782-bis) 47 Please update TBD statements with the assignment made by IANA to DOTS 48 Signal Channel Call Home. 50 Also, please update the "revision" date of the YANG module. 52 Status of This Memo 54 This Internet-Draft is submitted in full conformance with the 55 provisions of BCP 78 and BCP 79. 57 Internet-Drafts are working documents of the Internet Engineering 58 Task Force (IETF). Note that other groups may also distribute 59 working documents as Internet-Drafts. The list of current Internet- 60 Drafts is at https://datatracker.ietf.org/drafts/current/. 62 Internet-Drafts are draft documents valid for a maximum of six months 63 and may be updated, replaced, or obsoleted by other documents at any 64 time. It is inappropriate to use Internet-Drafts as reference 65 material or to cite them other than as "work in progress." 67 This Internet-Draft will expire on March 18, 2021. 69 Copyright Notice 71 Copyright (c) 2020 IETF Trust and the persons identified as the 72 document authors. All rights reserved. 74 This document is subject to BCP 78 and the IETF Trust's Legal 75 Provisions Relating to IETF Documents 76 (https://trustee.ietf.org/license-info) in effect on the date of 77 publication of this document. Please review these documents 78 carefully, as they describe your rights and restrictions with respect 79 to this document. Code Components extracted from this document must 80 include Simplified BSD License text as described in Section 4.e of 81 the Trust Legal Provisions and are provided without warranty as 82 described in the Simplified BSD License. 84 Table of Contents 86 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 87 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 88 1.2. The Call Home Solution . . . . . . . . . . . . . . . . . 5 89 1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 6 90 1.4. Co-existence of Base DOTS Signal Channel & DOTS Call Home 8 91 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 12 93 3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 12 94 3.2. DOTS Signal Channel Variations . . . . . . . . . . . . . 13 95 3.2.1. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 13 96 3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 14 97 3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 15 98 3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 15 99 3.3.2. Address Sharing Considerations . . . . . . . . . . . 18 100 3.3.3. DOTS Signal Call Home YANG Module . . . . . . . . . . 21 101 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 102 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 27 103 4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 27 104 4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 28 105 4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 29 106 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 107 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 108 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 109 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 110 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 111 9.1. Normative References . . . . . . . . . . . . . . . . . . 31 112 9.2. Informative References . . . . . . . . . . . . . . . . . 32 113 Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home . . 35 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 116 1. Introduction 118 1.1. The Problem 120 The DOTS signal channel protocol [I-D.ietf-dots-rfc8782-bis] is used 121 to carry information about a network resource or a network (or a part 122 thereof) that is under a Distributed Denial of Service (DDoS) attack 123 [RFC4732]. Such information is sent by a DOTS client to one or 124 multiple DOTS servers so that appropriate mitigation actions are 125 undertaken on traffic deemed suspicious. Various use cases are 126 discussed in [I-D.ietf-dots-use-cases]. 128 Internet of Things (IoT) devices are becoming more and more prevalent 129 in home networks, in particular. With compute and memory becoming 130 cheaper and cheaper, various types of IoT devices become available in 131 the consumer market at affordable prices. But on the downside, the 132 main threat being most of these IoT devices are bought off-the-shelf 133 and most manufacturers haven't considered security in the product 134 design (e.g., [Sec]). IoT devices deployed in home networks can be 135 easily compromised, they do not have an easy mechanism to upgrade, 136 and IoT manufactures may cease manufacture and/or discontinue 137 patching vulnerabilities on IoT devices (Sections 5.4 and 5.5 of 138 [RFC8576]). These vulnerable and compromised devices will continue 139 to be used for a long period of time in the home, and the end-user 140 does not know that IoT devices in his/her home are compromised. The 141 compromised IoT devices are typically used for launching DDoS attacks 142 (Section 3 of [RFC8576]) on victims while the owner/administrator of 143 the home network is not aware about such misbehaviors. Similar to 144 other DDoS attacks, the victim in this attack can be an application 145 server, a host, a router, a firewall, or an entire network. Such 146 misbehaviors will have a collateral damage that affects end users and 147 the reputation of an Internet Service Provider (ISP). 149 Nowadays, network devices in a home network offer network security 150 (e.g., firewall [RFC4949] or Intrusion Protection System (IPS) 151 service [I-D.ietf-i2nsf-terminology] on a home router) to protect the 152 devices connected to the home network from both external and internal 153 attacks. Over the years several techniques have been identified to 154 detect DDoS attacks, some of these techniques can be enabled on home 155 network devices but most of them are used within the ISP's network. 156 The ISP offering a DDoS mitigation service can detect outgoing DDoS 157 attack traffic originating from its subscribers or the ISP may 158 receive filtering rules (e.g., using BGP Flowspec 159 [RFC5575][I-D.ietf-idr-flow-spec-v6]) from a downstream service 160 provider to filter, block, or rate-limit DDoS attack traffic 161 originating from the ISP's subscribers to a downstream target. 163 Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris, 164 and Transport Layer Security (TLS) re-negotiation are difficult to 165 detect on a home network device without adversely affecting its 166 performance. The reason is typically home devices such as home 167 routers have fast path to boost the throughput. For every new TCP/ 168 UDP flow, only the first few packets are punted through the slow 169 path. Hence, it is not possible to detect various DDoS attacks in 170 the slow path, since the attack payload is sent to the target server 171 after the flow is switched to fast path. The reader may refer to 172 Section 2 of [RFC6398] for a brief definition of slow and fast paths. 174 Deep Packet Inspection (DPI) of all the packets of a flow would be 175 able to detect some of the attacks. However, a full-fledged DPI to 176 detect these type of DDoS attacks is functionally or operationally 177 not possible for all the devices attached to the home network owing 178 to the memory and CPU limitations of the home routers. Furthermore, 179 for certain DDoS attacks the ability to distinguish legitimate 180 traffic from attack traffic on a per packet basis is complex. This 181 complexity is due to that the packet itself may look "legitimate" and 182 no attack signature can be identified. The anomaly can be identified 183 only after detailed statistical analysis. 185 ISPs can detect some DDoS attacks originating from a home network 186 (e.g., Section 2.6 of [RFC8517]), but the ISP does not have a 187 mechanism to detect which device in the home network is generating 188 the DDoS attack traffic. The primary reason being that devices in an 189 IPv4 home network are typically behind a Network Address Translation 190 (NAT) border [RFC2663]. Even in case of an IPv6 home network, 191 although the ISP can identify the infected device in the home network 192 launching the DDoS traffic by tracking its unique IPv6 address, the 193 infected device can easily change its IPv6 address to evade 194 remediation. 196 Existing approaches are still suffering from misused access network 197 resources by abusing devices; the support of means for blocking such 198 attacks close to the sources are missing. In particular, the DOTS 199 signal protocol does not discuss cooperative DDoS mitigation between 200 the network hosting an attack source and the ISP to the suppress the 201 outbound DDoS attack traffic originating from that network. 203 1.2. The Call Home Solution 205 This specification addresses the problems discussed in Section 1.1 206 and presents an extension to the DOTS signal channel: DOTS signal 207 channel Call Home. 209 'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers 210 to a DOTS signal channel established at the initiative of a DOTS 211 server. That is, the DOTS server initiates a secure connection to a 212 DOTS client, and uses that connection to receive the attack traffic 213 information (e.g., attack sources) from the DOTS client. More 214 details are provided in Section 3. 216 DOTS agents involved in the DOTS Call Home adhere to the DOTS roles 217 as defined in [RFC8612]. For clarity, this document uses "Call Home 218 DOTS client" (or "Call Home DOTS server") to refer to a DOTS client 219 (or DOTS server) deployed in a Call Home scenario (Figure 1). 221 A high-level DOTS Call Home functional architecture is shown in 222 Figure 1. Attack source(s) are within the DOTS server domain. 224 Scope 225 +.-.-.-.-.-.-.-.-.-.-.-.+ 226 +---------------+ : +-------------+ : 227 | Alert/DMS/ | ~~~:~~~ | Call Home | : 228 | Peer DMS/... | : | DOTS client | : 229 +---------------+ : +------+------+ : 230 : | : 231 : | : 232 : | : 233 +---------------+ : +------+------+ : 234 | Attack | ~~~:~~~ | Call Home | : 235 | Source(s) | : | DOTS server | : 236 +---------------+ : +-------------+ : 237 +.-.-.-.-.-.-.-.-.-.-.-.+ 239 Figure 1: Basic DOTS Signal Channel Call Home Functional Architecture 240 A DOTS client relies upon a variety of triggers to make use of the 241 Call Home function (e.g., scrubbing the traffic from the attack 242 source, receiving an alert from an attack target, a peer DDoS 243 Mitigation System (DMS), or a transit provider). The definition of 244 these triggers is deployment-specific. It is therefore out of the 245 scope of this document to elaborate on how these triggers are made 246 available to a Call Home DOTS client. 248 In a typical deployment scenario, the Call Home DOTS server is 249 enabled on a Customer Premises Equipment (CPE), which is aligned with 250 recent trends to enrich the CPE with advanced security features. 251 Unlike classic DOTS deployments [I-D.ietf-dots-use-cases], such DOTS 252 server maintains a single DOTS signal channel session for each DOTS- 253 capable upstream provisioning domain [I-D.ietf-dots-multihoming]. 255 For instance, the Call Home DOTS server in the home network initiates 256 the signal channel Call Home in 'idle' time and then subsequently the 257 Call Home DOTS client in the ISP environment can initiate a 258 mitigation request whenever the ISP detects there is an attack from a 259 compromised device in the DOTS server domain (i.e., from within the 260 home network). 262 The Call Home DOTS server uses the DDoS attack traffic information to 263 identify the compromised device in its domain that is responsible for 264 launching the DDoS attack, optionally notifies a network 265 administrator, and takes appropriate mitigation action(s). For 266 example, a mitigation action can be to quarantine the compromised 267 device or block its traffic to the attack target(s) until the 268 mitigation request is withdrawn. 270 Other motivations for introducing the Call Home function are 271 discussed in Section 1.1 of [RFC8071]. 273 This document assumes that Call Home DOTS servers are provisioned 274 with a way to know how to reach the upstream Call Home DOTS 275 client(s), which could occur by a variety of means (e.g., 276 [I-D.ietf-dots-server-discovery]). The specification of such means 277 are out of scope of this document. 279 More information about the applicability scope of the DOTS signal 280 channel Call Home is provided in Section 1.3. 282 1.3. Applicability Scope 284 The aforementioned problems may be encountered in other deployments 285 than those discussed in Section 1.1 (e.g., data centers, enterprise 286 networks). The solution specified in this document can be used for 287 those deployments to block DDoS attack traffic closer to the 288 source(s) of the attack. 290 An instantiation of the Call Home functional architecture is depicted 291 in Figure 2. 293 +-------------+ 294 |Attack Target| 295 +-----+-------+ 296 | /\ Target Network 297 ......................|.||.................... 298 .--------+-||-------. 299 ( || )-. 300 .' || ' 301 ( Internet || ) 302 ( || -' 303 '-( || ) 304 '------+-||---------' 305 ......................|.||..................... 306 .--------+-||-------. Network 307 ( || )-. Provider 308 .' Call Home || ' (DMS) 309 ( DOTS client || ) 310 ( || -' 311 '-( || ) 312 '------+-||---------' 313 ......................|.||....................... 314 .--------+-||-------. Source Network 315 ( || )-. 316 .' Call Home || ' 317 ( DOTS server || Outbound ) 318 ( || DDoS -' 319 '-( || Attack ) 320 '------+-||---------' 321 | || 322 +-----+-++----+ 323 |Attack Source| 324 +-------------+ 326 Figure 2: DOTS Signal Channel Call Home Reference Architecture 328 It is out of the scope of this document to identify an exhaustive 329 list of such deployments. 331 1.4. Co-existence of Base DOTS Signal Channel & DOTS Call Home 333 The DOTS signal channel Call Home does not require nor preclude the 334 activation of the base DOTS signal channel 335 [I-D.ietf-dots-rfc8782-bis]. Some sample deployment schemes are 336 discussed in this section for illustration purposes. 338 The network that hosts an attack source may also be subject to 339 inbound DDoS attacks. In that case, both the base DOTS signal 340 channel and DOTS signal channel Call Home may be enabled as shown in 341 Figure 3 (Same DMS provider) or Figure 4 (Distinct DMS providers). 343 DOTS Signal Channel Base DOTS 344 Call Home Signal Channel 345 +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ 346 : +------+ :: +------+ : 347 : | DOTS | :: | DOTS | : 348 : |client| :: |server| : 349 : +--+---+ :: +---+--+ : 350 : /\ | :: | : Network 351 : || | :: | :Provider 352 : || | :: | : (DMS) 353 ...:.....||......|.....::.....|.............:........ 354 Outbound || | :: | || Inbound 355 DDoS || | :: | || DDoS 356 Attack || | :: | \/ Attack 357 : +--+---+ :: +---+--+ : 358 : | DOTS | :: | DOTS | : 359 : |server| :: |client| : 360 : +------+ :: +------+ : 361 +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ 362 Network #A 364 Figure 3: Activation of Base DOTS Signal Channel and Call Home (Same 365 DMS Provider) 367 Note that a DMS provider may not be on the default forwarding path of 368 an inbound DDoS attack traffic targeting a network (e.g., Network #B 369 in Figure 4). Nevertheless, the DOTS signal channel Call Home 370 requires the DMS provider to be on the default forwarding path of the 371 outbound traffic from a given network. 373 DOTS Signal Channel Base DOTS 374 Call Home Signal Channel 375 +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ 376 : Network +------+ :: +------+ Third : 377 : Provider | DOTS | :: | DOTS | Party : 378 : (DMS) |client| :: |server| DMS : 379 : +--+---+ :: +---+--+ Provider : 380 : /\ | :: | : 381 : || | :: | : 382 : || | :: | : 383 ...:.....||......|.....::.....|.............:........ 384 Outbound || | :: | || Inbound 385 DDoS || | :: | || DDoS 386 Attack || | :: | \/ Attack 387 : +--+---+ :: +---+--+ : 388 : | DOTS | :: | DOTS | : 389 : |server| :: |client| : 390 : +------+ :: +------+ : 391 +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ 392 Network #B 394 Figure 4: Activation of Base DOTS Signal Channel and Call Home 395 (Distinct DMS Providers) 397 Figures 5 and 6 depict examples where the same node embeds both base 398 DOTS and DOTS Call Home agents. For example, a DOTS server and a 399 Call Home DOTS client may be enabled on the same device within the 400 infrastructure of a DMS provider (e.g., Node #i in Figure 5) or a 401 DOTS client and a Call Home DOTS server may be enabled on the same 402 device within a source network (e.g., Node #j with Network #D shown 403 in Figure 6) . 405 Whether the same or distinct nodes are used to host base DOTS and 406 DOTS Call Home agents is specific to each domain. 408 DOTS Signal Channel Base DOTS 409 Call Home Signal Channel 410 +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ 411 : +----------------------+ : 412 : | Node #i | : 413 : | +------+ +------+ | : 414 : | | DOTS | | DOTS | | : 415 : | |client| |server| | : 416 : | +--+---+ +---+--+ | : 417 : +----|-----::-----|----+ : Network 418 : /\ | :: | :Provider 419 : || | :: | : (DMS) 420 ...:.....||......|.....::.....|.............:........ 421 Outbound || | :: | || Inbound 422 DDoS || | :: | || DDoS 423 Attack || | :: | \/ Attack 424 : +--+---+ :: +---+--+ : 425 : | DOTS | :: | DOTS | : 426 : |server| :: |client| : 427 : +------+ :: +------+ : 428 +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ 429 Network #C 431 Figure 5: An Example of the Same Node Embedding both a Call Home DOTS 432 Client and a DOTS Server at the Network Provider's Side 433 DOTS Signal Channel Base DOTS 434 Call Home Signal Channel 435 +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ 436 : +----------------------+ : 437 : | Node #k | : 438 : | +------+ +------+ | : 439 : | | DOTS | | DOTS | | : 440 : | |client| |server| | : 441 : | +--+---+ +---+--+ | : 442 : +----|-----::-----|----+ : Network 443 : /\ | :: | :Provider 444 : || | :: | : (DMS) 445 ...:.....||......|.....::.....|.............:........ 446 Outbound || | :: | || Inbound 447 DDoS || | :: | || DDoS 448 Attack || | :: | \/ Attack 449 : +----|-----::-----|----+ : 450 : | +--+---+ +---+--+ | : 451 : | | DOTS | | DOTS | | : 452 : | |server| |client| | : 453 : | +------+ +------+ | : 454 : | Node #j | : 455 : +----------------------+ : 456 +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ 457 Network #D 459 Figure 6: Another Example where the Same Node Embeds both a DOTS 460 Client and a Call Home DOTS Server 462 Appendix A elaborates on the considerations to unambiguously 463 distinguish DOTS messages which belong to each of these channels. 465 2. Terminology 467 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 468 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 469 "OPTIONAL" in this document are to be interpreted as described in BCP 470 14 [RFC2119][RFC8174] when, and only when, they appear in all 471 capitals, as shown here. 473 The reader should be familiar with the terms defined in [RFC8612]. 475 'Base DOTS signal channel' refers to [I-D.ietf-dots-rfc8782-bis]. 477 The meaning of the symbols in YANG tree diagrams are defined in 478 [RFC8340] and [RFC8791]. 480 (D)TLS is used for statements that apply to both Transport Layer 481 Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS) 482 [RFC6347]. Specific terms are used for any statement that applies to 483 either protocol alone. 485 3. DOTS Signal Channel Call Home 487 3.1. Procedure 489 The DOTS signal channel Call Home preserves all but one of the DOTS 490 client/server roles in the DOTS protocol stack, as compared to DOTS 491 client-initiated DOTS signal channel protocol 492 [I-D.ietf-dots-rfc8782-bis]. The role reversal that occurs is at the 493 (D)TLS layer; that is, (1) the Call Home DOTS server acts as a DTLS 494 client and the Call Home DOTS client acts as a DTLS server or (2) the 495 Call Home DOTS server acts as a TLS client initiating the underlying 496 TCP connection and the Call Home DOTS client acts as a TLS server. 497 The Call Home DOTS server initiates (D)TLS handshake to the Call Home 498 DOTS client. 500 For example, a home network element (e.g., home router) co-located 501 with a Call Home DOTS server is the (D)TLS server. However, when 502 calling home, the DOTS server initially assumes the role of the 503 (D)TLS client, but the network element's role as a DOTS server 504 remains the same. Furthermore, existing certificate chains and 505 mutual authentication mechanisms between the DOTS agents are 506 unaffected by the Call Home function. This Call Home function 507 enables the DOTS server co-located with a network element (possibly 508 behind NATs and firewalls) reachable by only the intended Call Home 509 DOTS client and hence the Call Home DOTS server cannot be subjected 510 to these DDoS attacks. 512 Figure 7 illustrates a sample DOTS Call Home flow exchange: 514 +-----------+ +-----------+ 515 | Call Home | | Call Home | 516 | DOTS | | DOTS | 517 | server | | client | 518 +-----+-----+ +-----+-----+ 519 (D)TLS client (D)TLS server 520 | | 521 | 1. (D)TLS connection | 522 |----------------------------------->| 523 | 2. Mitigation request | 524 |<-----------------------------------| 525 | ... | 527 Figure 7: DOTS Signal Channel Call Home Sequence Diagram 529 The DOTS signal channel Call Home procedure is as follows: 531 1. If UDP transport is used, the Call Home DOTS server begins by 532 initiating a DTLS connection to the Call Home DOTS client. 534 If TCP is used, the Call Home DOTS server begins by initiating a 535 TCP connection to the Call Home DOTS client. Once connected, the 536 Call Home DOTS server continues to initiate a TLS connection to 537 the Call Home DOTS client. 539 In some cases, peer DOTS agents may have mutual agreement to use 540 a specific port number, such as by explicit configuration or 541 dynamic discovery [I-D.ietf-dots-server-discovery]. Absent such 542 mutual agreement, the DOTS signal channel Call Home MUST run over 543 port number TBD (that is, Call Home DOTS clients must support 544 accepting DTLS (or TCP) connections on TBD) as defined in 545 Section 4.1, for both UDP and TCP. The interaction between the 546 base DOTS signal channel and the Call Home is discussed in 547 Appendix A. 549 The Happy Eyeballs mechanism explained in Section 4.3 of 550 [I-D.ietf-dots-rfc8782-bis] is used for initiating (D)TLS 551 connections. 553 2. Using this (D)TLS connection, the Call Home DOTS client may 554 request, withdraw, or retrieve the status of mitigation requests. 555 The Call Home DOTS client supplies the source information by 556 means of new attributes defined in Section 3.3.1. 558 The Heartbeat mechanism used for the DOTS Call Home deviates from 559 the one defined in Section 4.7 of [I-D.ietf-dots-rfc8782-bis]. 560 Section 3.2.1 specifies the behavior to be followed by Call Home 561 DOTS agents. 563 3.2. DOTS Signal Channel Variations 565 3.2.1. Heartbeat Mechanism 567 Once the (D)TLS section is established between the DOTS agents, the 568 Call Home DOTS client contacts the Call Home DOTS server to retrieve 569 the session configuration parameters (Section 4.5 of 570 [I-D.ietf-dots-rfc8782-bis]). The Call Home DOTS server adjusts the 571 'heartbeat-interval' to accommodate binding timers used by on-path 572 NATs and firewalls. Heartbeats will be then exchanged by the DOTS 573 agents following the instructions retrieved using the signal channel 574 session configuration exchange. 576 It is the responsibility of Call Home DOTS servers to ensure that on- 577 path translators/firewalls are maintaining a binding so that the same 578 external IP address and/or port number is retained for the DOTS 579 signal channel session. A Call Home DOTS client MAY trigger their 580 heartbeat requests immediately after receiving heartbeat probes from 581 its peer Call Home DOTS server. 583 When an outgoing attack that saturates the outgoing link from the 584 Call Home DOTS server is detected and reported by a Call Home DOTS 585 client, the latter MUST continue to use the DOTS signal channel even 586 if no traffic is received from the Call Home DOTS server. 588 If the Call Home DOTS server receives traffic from the Call Home DOTS 589 client, the Call Home DOTS server MUST continue to use the DOTS 590 signal channel even if the missing heartbeats allowed threshold 591 ('missing-hb-allowed') is reached. 593 If the Call Home DOTS server does not receive any traffic from the 594 peer Call Home DOTS client during the time span required to exhaust 595 the maximum 'missing-hb-allowed' threshold, the Call Home DOTS server 596 concludes the session is disconnected. Then, the Call Home DOTS 597 server MUST try to resume the (D)TLS session. 599 3.2.2. Redirected Signaling 601 A Call Home DOTS server MUST NOT support the Redirected Signaling 602 mechanism as specified in Section 4.6 of [I-D.ietf-dots-rfc8782-bis] 603 (i.e., a 5.03 response that conveys an alternate DOTS server's FQDN 604 or alternate DOTS server's IP address(es)). A Call Home DOTS client 605 MUST silently discard such message as only a Call Home DOTS server 606 can initiate a new (D)TLS connection. 608 If a Call Home DOTS client wants to redirect a Call Home DOTS server 609 to another Call Home DOTS client, it MUST send a Non-confirmable PUT 610 request to the predefined resource ".well-known/dots/redirect" with 611 the new Call Home DOTS client FQDN or IP address in the body of the 612 PUT similar to what is described in Section 4.6 of 613 [I-D.ietf-dots-rfc8782-bis]. Furthermore, a new clause called 'ttl" 614 is defined to return the Time to live (TTL) of the alternate Call 615 Home DOTS client. 617 On receipt of this PUT request, the Call Home DOTS server responds 618 with a 2.01 (Created), closes this connection and establishes a 619 connection with the new Call Home DOTS client. The processing of the 620 TTL is defined in Section 4.6 of [I-D.ietf-dots-rfc8782-bis]. If the 621 Call Home DOTS server cannot service the PUT request, the response is 622 rejected with a 4.00 (bad Request). 624 Figure 8 shows a PUT request example to convey the alternate Call 625 Home DOTS client 'alt-call-home-client.example' together with its IP 626 addresses 2001:db8:6401::1 and 2001:db8:6401::2. The validity of 627 this alternate Call Home DOTS client is 10 minutes. 629 Header: PUT (Code=0.03) 630 Uri-Path: ".well-known" 631 Uri-Path: "dots" 632 Uri-Path: "redirect" 633 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 634 Uri-Path: "mid=123" 635 Content-Format: "application/dots+cbor" 637 { 638 "ietf-dots-signal-channel:redirected-signal": { 639 "ietf-dots-call-home:alt-ch-client": 640 "alt-call-home-client.example", 641 "ietf-dots-call-home:alt-ch-client-record": [ 642 "2001:db8:6401::1", 643 "2001:db8:6401::2" 644 ], 645 "ietf-dots-call-home:ttl": 600 646 } 648 Figure 8: Example of a PUT Request for Redirected Signaling 650 3.3. DOTS Signal Channel Extension 652 3.3.1. Mitigation Request 654 This specification extends the mitigation request defined in 655 Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis] to convey the attack 656 source information (e.g., source prefixes, source port numbers). The 657 DOTS client conveys the following new parameters in the CBOR body of 658 the mitigation request: 660 source-prefix: A list of attacker prefixes used to attack the 661 target. Prefixes are represented using Classless Inter-Domain 662 Routing (CIDR) notation [RFC4632]. 664 As a reminder, the prefix length MUST be less than or equal to 32 665 (or 128) for IPv4 (or IPv6). 667 The prefix list MUST NOT include broadcast, loopback, or multicast 668 addresses. These addresses are considered as invalid values. In 669 addition, the DOTS client MUST validate that attacker prefixes are 670 within the scope of the DOTS server domain. 672 This is an optional attribute for the base DOTS signal channel 673 operations. 675 source-port-range: A list of port numbers used by the attack traffic 676 flows. 678 A port range is defined by two bounds, a lower port number (lower- 679 port) and an upper port number (upper-port). When only 'lower- 680 port' is present, it represents a single port number. 682 For TCP, UDP, Stream Control Transmission Protocol (SCTP) 683 [RFC4960], or Datagram Congestion Control Protocol (DCCP) 684 [RFC4340], a range of ports can be any subrange of 0-65535, for 685 example, 0-1023, 1024-65535, or 1024-49151. 687 This is an optional attribute for the base DOTS signal channel 688 operations. 690 source-icmp-type-range: A list of ICMP types used by the attack 691 traffic flows. An ICMP type range is defined by two bounds, a 692 lower ICMP type (lower-type) and an upper ICMP type (upper-type). 693 When only 'lower-type' is present, it represents a single ICMP 694 type. 696 This is an optional attribute for the base DOTS signal channel 697 operations. 699 The 'source-prefix' parameter is a mandatory attribute when the 700 attack traffic information is signaled by a Call Home DOTS client 701 (i.e., the Call Home scenario depicted in Figure 7). The 'target- 702 uri' or 'target-fqdn' parameters can be included in a mitigation 703 request for diagnostic purposes to notify the Call Home DOTS server 704 domain administrator, but SHOULD NOT be used to determine the target 705 IP addresses. Note that 'target-prefix' becomes a mandatory 706 attribute in the mitigation request signaling the attack information 707 because 'target-uri' and 'target-fqdn' are optional attributes and 708 'alias-name' will not be conveyed in a mitigation request. 710 In order to help attack source identification by a Call Home DOTS 711 server, the Call Home DOTS client SHOULD include in its mitigation 712 request additional information such as 'source-port-range' or 713 'source-icmp-type-range'. The Call Home DOTS client may not include 714 such information if 'source-prefix' conveys an IPv6 address/prefix. 715 Address sharing implications on the setting of source information 716 ('source-prefix', 'source-port-range') are discussed in 717 Section 3.3.2. 719 Only immediate mitigation requests (i.e., 'trigger-mitigation' set to 720 'true') are allowed; Call Home DOTS clients MUST NOT send requests 721 with 'trigger-mitigation' set to 'false'. Such requests MUST be 722 discarded by the Call Home DOTS server with a 4.00 (Bad Request). 724 An example of a mitigation request sent by a Call Home DOTS client is 725 shown in Figure 9. 727 Header: PUT (Code=0.03) 728 Uri-Path: ".well-known" 729 Uri-Path: "dots" 730 Uri-Path: "mitigate" 731 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 732 Uri-Path: "mid=56" 733 Content-Format: "application/dots+cbor" 735 { 736 "ietf-dots-signal-channel:mitigation-scope": { 737 "scope": [ 738 { 739 "target-prefix": [ 740 "2001:db8:c000::/128" 741 ], 742 "ietf-dots-call-home:source-prefix": [ 743 "2001:db8:123::/128" 744 ], 745 "lifetime": 3600 746 } 747 ] 748 } 749 } 751 Figure 9: An Example of Mitigation Request Issued by a Call Home DOTS 752 Client 754 The Call Home DOTS server MUST check that the 'source-prefix' is 755 within the scope of the Call Home DOTS server domain. Note that in a 756 DOTS Call Home scenario, the Call Home DOTS server considers, by 757 default, that any routeable IP prefix enclosed in 'target-prefix' is 758 within the scope of the Call Home DOTS client. Invalid mitigation 759 requests are handled as per Section 4.4.1 of 760 [I-D.ietf-dots-rfc8782-bis]. 762 Note: These validation checks do not apply when the source 763 information is included as a hint in the context of the base DOTS 764 signal channel. 766 The Call Home DOTS server domain administrator consent MAY be 767 required to block the traffic from the compromised device to the 768 attack target. An implementation MAY have a configuration knob to 769 block the traffic from the compromised device to the attack target 770 with or without DOTS server domain administrator consent. If the 771 attack traffic is blocked, the Call Home DOTS server informs the Call 772 Home DOTS client that the attack is being mitigated. 774 If the attack traffic information is identified by the Call Home DOTS 775 server or the Call Home DOTS server domain administrator as 776 legitimate traffic, the mitigation request is rejected, and 4.09 777 (Conflict) is returned to the Call Home DOTS client. The conflict- 778 clause (defined in Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis]) 779 indicates the cause of the conflict. The following new value is 780 defined: 782 4: Mitigation request rejected. This code is returned by the DOTS 783 server to indicate the attack traffic has been classified as 784 legitimate traffic. 786 Once the request is validated by the Call Home DOTS server, 787 appropriate actions are enforced to block the attack traffic within 788 the source network. The Call Home DOTS client is informed about the 789 progress of the attack mitigation following the rules in 790 [I-D.ietf-dots-rfc8782-bis]. For example, if the Call Home DOTS 791 server is embedded in a CPE, it can program the packet processor to 792 punt all the traffic from the compromised device to the target to 793 slow path. The CPE inspects the punted slow path traffic to detect 794 and block the outgoing DDoS attack traffic or quarantine the device 795 (e.g., using MAC level filtering) until it is remediated, and 796 notifies the CPE administrator about the compromised device. 798 The DOTS agents follow the same procedures specified in 799 [I-D.ietf-dots-rfc8782-bis] for managing a mitigation request. 801 3.3.2. Address Sharing Considerations 803 If a Carrier Grade NAT (CGN, including NAT64) is located between the 804 DOTS client domain and DOTS server domain, communicating an external 805 IP address in a mitigation request is likely to be discarded by the 806 Call Home DOTS server because the external IP address is not visible 807 locally to the Call Home DOTS server (see Figure 10). The Call Home 808 DOTS server is only aware of the internal IP addresses/prefixes bound 809 to its domain. Thus, the Call Home DOTS client MUST NOT include the 810 external IP address and/or port number identifying the suspect attack 811 source, but MUST include the internal IP address and/or port number. 812 To that aim, the Call Home DOTS client SHOULD rely on mechanisms, 813 such as [RFC8512] or [RFC8513], to retrieve the internal IP address 814 and port number which are mapped to an external IP address and port 815 number. 817 N | .-------------------. 818 E | ( )-. 819 T | .' ' 820 W | ( Call Home ) 821 O | ( DOTS client -' 822 R | '-( ) 823 K | '-------+-----------' 824 | | 825 P | | 826 R | +---+---+ 827 O | | CGN | External Realm 828 V |..............| |...................... 829 I | | | Internal Realm 830 D | +---+---+ 831 E | | 832 R | | 833 --- | 834 .---------+---------. 835 ( )-. 836 .' Source Network ' 837 ( ) 838 ( Call Home -' 839 '-( DOTS server ) 840 '------+------------' 841 | 842 +-----+-------+ 843 |Attack Source| 844 +-------------+ 846 Figure 10: Example of a CGN between DOTS Domains 848 If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the 849 provider's domain to service its customers, the identification of an 850 attack source bound to an IPv4 address/prefix MUST also rely on 851 source port numbers because the same IPv4 address is assigned to 852 multiple customers. The port information is required to 853 unambiguously identify the source of an attack. 855 If a translator is enabled on the boundaries of the domain hosting 856 the Call Home DOTS server (e.g., a CPE with NAT enabled as shown in 857 Figures 11 and 12), the Call Home DOTS server uses the attack traffic 858 information conveyed in a mitigation request to find the internal 859 source IP address of the compromised device and blocks the traffic 860 from the compromised device traffic to the attack target until the 861 mitigation request is withdrawn. Doing so allows to isolate the 862 suspicious device while avoiding to disturb other services. 864 .-------------------. 865 ( )-. 866 .' Network Provider (DMS)' 867 ( ) 868 ( Call Home -' 869 '-( DOTS client ) 870 '-------+-----------' 871 | 872 --- +---+---+ 873 S | | CPE | External Realm 874 O |..............| |................ 875 U | | NAT | Internal Realm 876 R | +---+---+ 877 C | | 878 E | .---------+---------. 879 | ( )-. 880 N | .' ' 881 E | ( Call Home ) 882 T | ( DOTS server -' 883 W | '-( ) 884 O | '-------+-----------' 885 R | | 886 K | +------+------+ 887 | |Attack Source| 888 +-------------+ 890 Figure 11: Example of a DOTS Server Domain with a NAT Embedded in a 891 CPE 893 .-------------------. 894 ( )-. 895 .' Network Provider (DMS) ' 896 ( ) 897 ( Call Home -' 898 '-( DOTS client ) 899 '---------+---------' 900 | 901 --- +-----+-----+ 902 S | | CPE/NAT | External Realm 903 O |..............| |................ 904 U | | Call Home | Internal Realm 905 R | |DOTS server| 906 C | +-----+-----+ 907 E | | 908 | .-----------+-------. 909 | ( )-. 910 N | .' ' 911 E | ( Local Area Network ) 912 T | ( -' 913 W | '-( ) 914 O | '--------+----------' 915 R | | 916 K | +------+------+ 917 | |Attack Source| 918 +-------------+ 920 Figure 12: Example of a Call Home DOTS Server and a NAT Embedded in a 921 CPE 923 3.3.3. DOTS Signal Call Home YANG Module 925 3.3.3.1. Tree Structure 927 This document augments the "ietf-dots-signal-channel" DOTS signal 928 YANG module defined in [I-D.ietf-dots-rfc8782-bis] for signaling the 929 attack traffic information. This document defines the YANG module 930 "ietf-dots-call-home", which has the following tree structure: 932 module: ietf-dots-call-home 934 augment-structure /signal:dots-signal/signal:message-type 935 /signal:mitigation-scope/signal:scope: 936 +-- source-prefix* inet:ip-prefix 937 +-- source-port-range* [lower-port] 938 | +-- lower-port inet:port-number 939 | +-- upper-port? inet:port-number 940 +-- source-icmp-type-range* [lower-type] 941 +-- lower-type uint8 942 +-- upper-type? uint8 943 augment-structure /signal:dots-signal/signal:message-type 944 /signal:redirected-signal: 945 +-- (type)? 946 +--:(call-home-only) 947 +-- alt-ch-client? string 948 +-- alt-ch-client-record* inet:ip-address 949 +-- ttl? uint32 951 3.3.3.2. YANG/JSON Mapping Parameters to CBOR 953 The YANG/JSON mapping parameters to CBOR are listed in Table 1. 955 +--------------------+------------+------+---------------+--------+ 956 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 957 | | Type | Key | Type & | Type | 958 | | | | Information | | 959 +====================+============+======+===============+========+ 960 |ietf-dots-call-home:| leaf-list | | | | 961 | source-prefix | inet: | TBA1 | 4 array | Array | 962 | | ip-prefix | | 3 text string | String | 963 +--------------------+------------+------+---------------+--------+ 964 |ietf-dots-call-home:| | | | | 965 | source-port-range | list | TBA2 | 4 array | Array | 966 +--------------------+------------+------+---------------+--------+ 967 |ietf-dots-call-home:| | | | | 968 | source-icmp-type- | list | TBA3 | 4 array | Array | 969 | range | | | | | 970 +--------------------+------------+------+---------------+--------+ 971 | lower-type | uint8 | TBA4 | 0 unsigned | Number | 972 +--------------------+------------+------+---------------+--------+ 973 | upper-type | uint8 | TBA5 | 0 unsigned | Number | 974 +--------------------+------------+------+---------------+--------+ 975 |ietf-dots-call-home:| | | | | 976 | alt-ch-client | string | TBA6 | 3 text string | String | 977 +--------------------+------------+------+---------------+--------+ 978 |ietf-dots-call-home:| leaf-list | TBA7 | 4 array | Array | 979 | alt-ch-client- | inet: | | | | 980 | record | ip-address| | 3 text string | String | 981 +--------------------+------------+------+---------------+--------+ 982 |ietf-dots-call-home:| | | | | 983 | ttl | uint32 | TBA8 | 0 unsigned | Number | 984 +--------------------+------------+------+---------------+--------+ 986 Table 1: YANG/JSON Mapping Parameters to CBOR 988 3.3.3.3. YANG Module 990 This module uses the common YANG types defined in [RFC6991] and the 991 data structure defined in [RFC8791]. 993 file "ietf-dots-call-home@2020-07-07.yang" 994 module ietf-dots-call-home { 995 yang-version 1.1; 996 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home"; 997 prefix dots-call-home; 999 import ietf-inet-types { 1000 prefix inet; 1001 reference 1002 "Section 4 of RFC 6991"; 1004 } 1005 import ietf-dots-signal-channel { 1006 prefix signal; 1007 reference 1008 "RFC YYYY: Distributed Denial-of-Service Open Threat 1009 Signaling (DOTS) Signal Channel Specification"; 1010 } 1011 import ietf-yang-structure-ext { 1012 prefix sx; 1013 reference 1014 "RFC 8791: YANG Data Structure Extensions"; 1015 } 1017 organization 1018 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 1019 contact 1020 "WG Web: 1021 WG List: 1023 Author: Konda, Tirumaleswar Reddy 1024 ; 1026 Author: Mohamed Boucadair 1027 ; 1029 Author: Jon Shallow 1030 "; 1031 description 1032 "This module contains YANG definitions for the signaling 1033 messages exchanged between a DOTS client and a DOTS server 1034 for the Call Home deployment scenario. 1036 Copyright (c) 2020 IETF Trust and the persons identified as 1037 authors of the code. All rights reserved. 1039 Redistribution and use in source and binary forms, with or 1040 without modification, is permitted pursuant to, and subject 1041 to the license terms contained in, the Simplified BSD License 1042 set forth in Section 4.c of the IETF Trust's Legal Provisions 1043 Relating to IETF Documents 1044 (http://trustee.ietf.org/license-info). 1046 This version of this YANG module is part of RFC XXXX; see 1047 the RFC itself for full legal notices."; 1049 revision 2020-07-07 { 1050 description 1051 "Initial revision."; 1053 reference 1054 "RFC XXXX: Distributed Denial-of-Service Open Threat 1055 Signaling (DOTS) Signal Channel Call Home"; 1056 } 1057 sx:augment-structure "/signal:dots-signal/signal:message-type/" 1058 + "signal:mitigation-scope/signal:scope" { 1059 description 1060 "Attacker source details."; 1061 leaf-list source-prefix { 1062 type inet:ip-prefix; 1063 description 1064 "IPv4 or IPv6 prefix identifying the attacker(s)."; 1065 } 1066 list source-port-range { 1067 key "lower-port"; 1068 description 1069 "Port range. When only lower-port is 1070 present, it represents a single port number."; 1071 leaf lower-port { 1072 type inet:port-number; 1073 mandatory true; 1074 description 1075 "Lower port number of the port range."; 1076 } 1077 leaf upper-port { 1078 type inet:port-number; 1079 must '. >= ../lower-port' { 1080 error-message 1081 "The upper port number must be greater than 1082 or equal to lower port number."; 1083 } 1084 description 1085 "Upper port number of the port range."; 1086 } 1087 } 1088 list source-icmp-type-range { 1089 key "lower-type"; 1090 description 1091 "ICMP type range. When only lower-type is 1092 present, it represents a single ICMP type."; 1093 leaf lower-type { 1094 type uint8; 1095 mandatory true; 1096 description 1097 "Lower ICMP type of the ICMP type range."; 1098 } 1099 leaf upper-type { 1100 type uint8; 1101 must '. >= ../lower-type' { 1102 error-message 1103 "The upper ICMP type must be greater than 1104 or equal to lower ICMP type."; 1105 } 1106 description 1107 "Upper type of the ICMP type range."; 1108 } 1109 } 1110 } 1111 sx:augment-structure "/signal:dots-signal/signal:message-type/" 1112 + "signal:redirected-signal" { 1113 description 1114 "The alternate Call Home DOTS client."; 1115 choice type { 1116 description 1117 "Indicates the type of the DOTS session."; 1118 case call-home-only { 1119 description 1120 "These attributes appear only in a call home signal 1121 channel message from the Call Home DOTS client 1122 to the Call Home DOTS server."; 1123 leaf alt-ch-client { 1124 type string; 1125 description 1126 "FQDN of an alternate Call Home DOTS client."; 1127 } 1128 leaf-list alt-ch-client-record { 1129 type inet:ip-address; 1130 description 1131 "List of records for the alternate Call Home 1132 DOTS client."; 1133 } 1134 leaf ttl { 1135 type uint32; 1136 units "seconds"; 1137 description 1138 "The Time to live (TTL) of the alternate Call Home 1139 DOTS client."; 1140 } 1141 } 1142 } 1143 } 1144 } 1145 1147 4. IANA Considerations 1149 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number 1151 IANA is requested to assign the port number TBD to the DOTS signal 1152 channel Call Home protocol for both UDP and TCP from the "Service 1153 Name and Transport Protocol Port Number Registry" [ServicePorts]. 1155 Service Name: dots-call-home 1156 Port Number: TBD 1157 Transport Protocol(s): TCP/UDP 1158 Description: DOTS Signal Channel Call Home 1159 Assignee: IESG 1160 Contact: IETF Chair 1161 Reference: RFC XXXX 1163 The assignment of port number 4647 is strongly suggested (DOTS signal 1164 channel uses port number 4646). 1166 4.2. DOTS Signal Channel CBOR Mappings Registry 1168 This specification registers the following comprehension-optional 1169 parameters (Table 2) in the IANA "DOTS Signal Channel CBOR Key 1170 Values" registry [Key-Map]. 1172 o Note to the RFC Editor: Please delete TBA1-TBA8 once CBOR keys are 1173 assigned from the 32768-49151 range. 1175 +--------------------+-------+-------+------------+---------------+ 1176 | Parameter Name | CBOR | CBOR | Change | Specification | 1177 | | Key | Major | Controller | Document(s) | 1178 | | Value | Type | | | 1179 +====================+=======+=======+============+===============+ 1180 |ietf-dots-call-home:| | | | | 1181 | source-prefix | TBA1 | 4 | IESG | [RFCXXXX] | 1182 +--------------------+-------+-------+------------+---------------+ 1183 |ietf-dots-call-home:| | | | | 1184 | source-port-range | TBA2 | 4 | IESG | [RFCXXXX] | 1185 +--------------------+-------+-------+------------+---------------+ 1186 |ietf-dots-call-home:| | | | | 1187 | source-icmp-type- | TBA3 | 4 | IESG | [RFCXXXX] | 1188 | range | | | | | 1189 +--------------------+-------+-------+------------+---------------+ 1190 | lower-type | TBA4 | 0 | IESG | [RFCXXXX] | 1191 +--------------------+-------+-------+------------+---------------+ 1192 | upper-type | TBA5 | 0 | IESG | [RFCXXXX] | 1193 +--------------------+-------+-------+------------+---------------+ 1194 |ietf-dots-call-home:| | | | | 1195 | alt-ch-client | TBA6 | 3 | IESG | [RFCXXXX] | 1196 +--------------------+-------+-------+------------+---------------+ 1197 |ietf-dots-call-home:| | | | | 1198 |alt-ch-client-record| TBA7 | 4 | IESG | [RFCXXXX] | 1199 +--------------------+-------+-------+------------+---------------+ 1200 |ietf-dots-call-home:| | | | | 1201 | ttl | TBA8 | 0 | IESG | [RFCXXXX] | 1202 +--------------------+-------+-------+------------+---------------+ 1204 Table 2: Assigned DOTS Signal Channel CBOR Key Values 1206 4.3. New DOTS Conflict Cause 1208 This document requests IANA to assign a new code from the "DOTS 1209 Signal Channel Conflict Cause Codes" registry [Cause]. 1211 +-------+----------------------------------+------------+-----------+ 1212 | Code | Label | Descriptio | Reference | 1213 | | | n | | 1214 +-------+----------------------------------+------------+-----------+ 1215 | 4 (TB | request-rejected-legitimate- | Mitigation | [RFCXXXX] | 1216 | A9) | traffic | request | | 1217 | | | rejected. | | 1218 | | | This code | | 1219 | | | is | | 1220 | | | returned | | 1221 | | | by the | | 1222 | | | DOTS | | 1223 | | | server to | | 1224 | | | indicate | | 1225 | | | the attack | | 1226 | | | traffic | | 1227 | | | has been | | 1228 | | | classified | | 1229 | | | as | | 1230 | | | legitimate | | 1231 | | | traffic. | | 1232 +-------+----------------------------------+------------+-----------+ 1234 4.4. DOTS Signal Call Home YANG Module 1236 This document requests IANA to register the following URI in the "ns" 1237 subregistry within the "IETF XML Registry" [RFC3688]: 1239 URI: urn:ietf:params:xml:ns:yang:ietf-dots-call-home 1240 Registrant Contact: The IESG. 1241 XML: N/A; the requested URI is an XML namespace. 1243 This document requests IANA to register the following YANG module in 1244 the "YANG Module Names" subregistry [RFC6020] within the "YANG 1245 Parameters" registry: 1247 name: ietf-dots-call-home 1248 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home 1249 maintained by IANA: N 1250 prefix: dots-call-home 1251 reference: RFC XXXX 1253 5. Security Considerations 1255 This document deviates from classic DOTS signal channel usage by 1256 having the DOTS server initiate the (D)TLS connection. DOTS signal 1257 channel related security considerations discussed in Section 11 of 1258 [I-D.ietf-dots-rfc8782-bis] MUST be considered. DOTS agents MUST 1259 authenticate each other using (D)TLS before a DOTS signal channel 1260 session is considered valid. 1262 An attacker may launch a DoS attack on the DOTS client by having it 1263 perform computationally expensive operations, before deducing that 1264 the attacker doesn't possess a valid key. For instance, in TLS 1.3 1265 [RFC8446], the ServerHello message contains a Key Share value based 1266 on an expensive asymmetric key operation for key establishment. 1267 Common precautions mitigating DoS attacks are recommended, such as 1268 temporarily blacklisting the source address after a set number of 1269 unsuccessful authentication attempts. 1271 Call Home DOTS servers may not blindly trust mitigation requests from 1272 Call Home DOTS clients. For example, DOTS servers can use the attack 1273 flow information in a mitigation request to enable full-fledged 1274 packet inspection function to inspect all the traffic from the 1275 compromised device to the target or to re-direct the traffic from the 1276 compromised device to the target to a DDoS mitigation system to scrub 1277 the suspicious traffic. Call Home DOTS servers can also seek the 1278 consent of DOTS server domain administrator to block the traffic from 1279 the compromised device to the target (see Section 3.3.1). 1281 6. Privacy Considerations 1283 The considerations discussed in [RFC6973] were taken into account to 1284 assess whether the DOTS Call Home introduces privacy threats. 1286 Concretely, the protocol does not leak any new information that can 1287 be used to ease surveillance. In particular, the Call Home DOTS 1288 server is not required to share information that is local to its 1289 network (e.g., internal identifiers of an attack source) with the 1290 Call Home DOTS client. 1292 The DOTS Call Home does not preclude the validation of mitigation 1293 requests received from a Call Home DOTS client. For example, a 1294 security service running on the CPE may require administrator's 1295 consent before the CPE acts upon the mitigation request indicated by 1296 the Call Home DOTS client. How the consent is obtained is out of 1297 scope of this document. 1299 Note that a Call Home DOTS server can seek for an administrator's 1300 consent, validate the request by inspecting the traffic, or proceed 1301 with both. 1303 The DOTS Call Home is only advisory in nature. Concretely, the DOTS 1304 Call Home does not impose any action to be enforced within the 1305 network hosting an attack source; it is up to the Call Home DOTS 1306 server (and/or network administrator) to decide whether and which 1307 actions are required. 1309 Moreover, the DOTS Call Home avoids misattribution by appropriately 1310 identifying the network to which a suspect attack source belongs to 1311 (e.g., address sharing issues discussed in Section 3.3.1). 1313 Triggers to send a DOTS mitigation request to a Call Home DOTS server 1314 are deployment-specific. For example, a Call Home DOTS client may 1315 rely on the output of some DDoS detection systems deployed within the 1316 DOTS client domain to detect potential outbound DDoS attacks or on 1317 abuse claims received from remote victim networks. Such DDoS 1318 detection and mitigation techniques are not meant to track the 1319 activity of users, but to protect the Internet and avoid altering the 1320 IP reputation of the DOTS client domain. 1322 7. Contributors 1324 The following individuals have contributed to this document: 1326 Joshi Harsha 1327 McAfee, Inc. 1328 Embassy Golf Link Business Park 1329 Bangalore, Karnataka 560071 1330 India 1332 Email: harsha_joshi@mcafee.com 1334 Wei Pan 1335 Huawei Technologies 1336 China 1338 Email: william.panwei@huawei.com 1340 8. Acknowledgements 1342 Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Toema 1343 Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments. 1345 9. References 1347 9.1. Normative References 1349 [I-D.ietf-dots-rfc8782-bis] 1350 Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed 1351 Denial-of-Service Open Threat Signaling (DOTS) Signal 1352 Channel Specification", draft-ietf-dots-rfc8782-bis-00 1353 (work in progress), August 2020. 1355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1356 Requirement Levels", BCP 14, RFC 2119, 1357 DOI 10.17487/RFC2119, March 1997, 1358 . 1360 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1361 DOI 10.17487/RFC3688, January 2004, 1362 . 1364 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1365 the Network Configuration Protocol (NETCONF)", RFC 6020, 1366 DOI 10.17487/RFC6020, October 2010, 1367 . 1369 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1370 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1371 January 2012, . 1373 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1374 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1375 . 1377 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1378 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1379 May 2017, . 1381 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1382 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1383 . 1385 [RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data 1386 Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, 1387 June 2020, . 1389 9.2. Informative References 1391 [Cause] IANA, "DOTS Signal Channel Conflict Cause Codes", 1392 . 1395 [I-D.ietf-dots-multihoming] 1396 Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing 1397 Deployment Considerations for Distributed-Denial-of- 1398 Service Open Threat Signaling (DOTS)", draft-ietf-dots- 1399 multihoming-04 (work in progress), May 2020. 1401 [I-D.ietf-dots-server-discovery] 1402 Boucadair, M. and T. Reddy.K, "Distributed-Denial-of- 1403 Service Open Threat Signaling (DOTS) Agent Discovery", 1404 draft-ietf-dots-server-discovery-10 (work in progress), 1405 February 2020. 1407 [I-D.ietf-dots-use-cases] 1408 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 1409 L., and K. Nishizuka, "Use cases for DDoS Open Threat 1410 Signaling", draft-ietf-dots-use-cases-25 (work in 1411 progress), July 2020. 1413 [I-D.ietf-i2nsf-terminology] 1414 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1415 Birkholz, "Interface to Network Security Functions (I2NSF) 1416 Terminology", draft-ietf-i2nsf-terminology-08 (work in 1417 progress), July 2019. 1419 [I-D.ietf-idr-flow-spec-v6] 1420 Loibl, C., Raszuk, R., and S. Hares, "Dissemination of 1421 Flow Specification Rules for IPv6", draft-ietf-idr-flow- 1422 spec-v6-14 (work in progress), August 2020. 1424 [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", 1425 . 1428 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1429 Translator (NAT) Terminology and Considerations", 1430 RFC 2663, DOI 10.17487/RFC2663, August 1999, 1431 . 1433 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1434 Congestion Control Protocol (DCCP)", RFC 4340, 1435 DOI 10.17487/RFC4340, March 2006, 1436 . 1438 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1439 (CIDR): The Internet Address Assignment and Aggregation 1440 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1441 2006, . 1443 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1444 Denial-of-Service Considerations", RFC 4732, 1445 DOI 10.17487/RFC4732, December 2006, 1446 . 1448 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1449 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1450 . 1452 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1453 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1454 . 1456 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1457 and D. McPherson, "Dissemination of Flow Specification 1458 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1459 . 1461 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 1462 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 1463 2011, . 1465 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1466 Morris, J., Hansen, M., and R. Smith, "Privacy 1467 Considerations for Internet Protocols", RFC 6973, 1468 DOI 10.17487/RFC6973, July 2013, 1469 . 1471 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1472 Farrer, "Lightweight 4over6: An Extension to the Dual- 1473 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 1474 July 2015, . 1476 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 1477 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 1478 Port with Encapsulation (MAP-E)", RFC 7597, 1479 DOI 10.17487/RFC7597, July 2015, 1480 . 1482 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1483 RFC 8071, DOI 10.17487/RFC8071, February 2017, 1484 . 1486 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1487 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1488 . 1490 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1491 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1492 Address Translation (NAT) and Network Prefix Translation 1493 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1494 . 1496 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 1497 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 1498 DOI 10.17487/RFC8513, January 2019, 1499 . 1501 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 1502 Jacquenet, "An Inventory of Transport-Centric Functions 1503 Provided by Middleboxes: An Operator Perspective", 1504 RFC 8517, DOI 10.17487/RFC8517, February 2019, 1505 . 1507 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 1508 Things (IoT) Security: State of the Art and Challenges", 1509 RFC 8576, DOI 10.17487/RFC8576, April 2019, 1510 . 1512 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 1513 Threat Signaling (DOTS) Requirements", RFC 8612, 1514 DOI 10.17487/RFC8612, May 2019, 1515 . 1517 [Sec] UK Department for Digital Culture, Media & Sport, "Secure 1518 by Design: Improving the cyber security of consumer 1519 Internet of Things Report", March 2018, 1520 . 1523 [ServicePorts] 1524 IANA, "Service Name and Transport Protocol Port Number 1525 Registry", . 1528 Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home 1530 With the DOTS signal channel Call Home, there is a chance that two 1531 DOTS agents can simultaneously establish two DOTS signal channels 1532 with different directions (base DOTS signal channel and DOTS signal 1533 channel Call Home). Here is one example drawn from the home network. 1534 Nevertheless, the outcome of the discussion is not specific to these 1535 networks, but applies to any DOTS Call Home scenario. 1537 In the Call Home scenario, the DOTS server in, for example, the home 1538 network can mitigate the DDoS attacks launched by the compromised 1539 device in its domain by receiving the mitigation request sent by the 1540 Call Home DOTS client in the ISP environment. In addition, the DOTS 1541 client in the home network can initiate a mitigation request to the 1542 DOTS server in the ISP environment to ask for help when the home 1543 network is under a DDoS attack. Such DOTS server and DOTS client in 1544 the home network can co-locate in the same home network element 1545 (e.g., the Customer Premises Equipment). In this case, with the same 1546 peer at the same time the home network element will have the base 1547 DOTS signal channel and the DOTS signal channel Call Home defined in 1548 this specification. Thus, these two signal channels need to be 1549 distinguished when they are both supported. Two approaches have been 1550 considered for distinguishing the two DOTS signal channels, but only 1551 the one that using the dedicated port number has been chosen as the 1552 best choice. 1554 By using a dedicated port number for each, these two signal channels 1555 can be separated unambiguously and easily. For example, the CPE uses 1556 the port number 4646 allocated in [I-D.ietf-dots-rfc8782-bis] to 1557 initiate the basic signal channel to the ISP when it acts as the DOTS 1558 client, and uses the port number TBD to initiate the signal channel 1559 Call Home. Based on the different port numbers, the ISP can directly 1560 decide which kind of procedures should follow immediately after it 1561 receives the DOTS messages. This approach just requires two (D)TLS 1562 sessions to be established respectively for the basic signal channel 1563 and signal channel Call Home. 1565 The other approach is signaling the role of each DOTS agent (e.g., by 1566 using the DOTS data channel). For example, the DOTS agent in the 1567 home network first initiates a DOTS data channel to the peer DOTS 1568 agent in the ISP environment, at this time the DOTS agent in the home 1569 network is the DOTS client and the peer DOTS agent in the ISP 1570 environment is the DOTS server. After that, the DOTS agent in the 1571 home network retrieves the DOTS Call Home capability of the peer DOTS 1572 agent. If the peer supports the DOTS Call Home, the DOTS agent needs 1573 to subscribe to the peer to use this extension. Then, the reversal 1574 of DOTS role can be recognized as done by both DOTS agents. When the 1575 DOTS agent in the ISP environment, which now is the DOTS client, 1576 wants to filter the attackers' traffic, it requests the DOTS agent in 1577 the home network, which now is the DOTS server, for help. 1579 Signaling the role will complicate the DOTS protocol, and this 1580 complexity is not required in context where the DOTS Call Home is not 1581 required or only when the DOTS Call Home is needed. Besides, the 1582 DOTS data channel may not work during attack time. Even if changing 1583 the above example from using the DOTS data channel to the DOTS signal 1584 channel, the more procedures will still reduce the efficiency. Using 1585 the dedicated port number is much easier and more concise compared to 1586 the second approach, and its cost that establishing two (D)TLS 1587 sessions is much less. So, using a dedicated port number for the 1588 DOTS Call Home is chosen in this specification. 1590 Authors' Addresses 1592 Tirumaleswar Reddy 1593 McAfee, Inc. 1594 Embassy Golf Link Business Park 1595 Bangalore, Karnataka 560071 1596 India 1598 Email: kondtir@gmail.com 1600 Mohamed Boucadair 1601 Orange 1602 Rennes 35000 1603 France 1605 Email: mohamed.boucadair@orange.com 1607 Jon Shallow 1608 UK 1610 Email: supjps-ietf@jpshallow.com