idnits 2.17.1 draft-ietf-dots-signal-call-home-06.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 942 has weird spacing: '...er-type uin...' -- The document date (September 10, 2019) is 1690 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 1181, but not defined == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-37 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-13) exists of draft-ietf-dots-multihoming-02 == Outdated reference: A later version (-15) exists of draft-ietf-dots-server-discovery-05 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-20 == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-09 -- 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 (~~), 9 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 13, 2020 Orange 6 J. Shallow 7 September 10, 2019 9 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 10 Channel Call Home 11 draft-ietf-dots-signal-call-home-06 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 signal-channel) 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 13, 2020. 69 Copyright Notice 71 Copyright (c) 2019 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 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 . . . . . . . . . . . . . . . . . . . . . 25 102 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 25 103 4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 26 104 4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 27 105 4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 28 106 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 107 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29 108 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 109 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 110 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 111 9.1. Normative References . . . . . . . . . . . . . . . . . . 30 112 9.2. Informative References . . . . . . . . . . . . . . . . . 31 113 Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home . . 34 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 116 1. Introduction 118 1.1. The Problem 120 The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is 121 used to carry information about a network resource or a network (or a 122 part thereof) that is under a Distributed Denial of Service (DDoS) 123 attack [RFC4732]. Such information is sent by a DOTS client to one 124 or 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 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-signal-channel]. 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-signal-channel]. 477 The meaning of the symbols in YANG tree diagrams is defined in 478 [RFC8340]. 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-signal-channel]. The role reversal that occurs is at 493 the (D)TLS layer; that is, (1) the Call Home DOTS server acts as a 494 DTLS client and the Call Home DOTS client acts as a DTLS server or 495 (2) the Call Home DOTS server acts as a TLS client initiating the 496 underlying TCP connection and the Call Home DOTS client acts as a TLS 497 server. The Call Home DOTS server initiates (D)TLS handshake to the 498 Call Home 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. Using this TCP 536 connection, the Call Home DOTS server initiates a TLS connection 537 to 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-signal-channel] 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-signal-channel]. 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-signal-channel]). The Call Home DOTS server adjusts 571 the 'heartbeat-interval' to accommodate binding timers used by on- 572 path NATs and firewalls. Heartbeats will be then exchanged by the 573 DOTS agents following the instructions retrieved using the signal 574 channel 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 603 [I-D.ietf-dots-signal-channel] (i.e., a 5.03 response that conveys an 604 alternate DOTS server's FQDN or alternate DOTS server's IP 605 address(es)). A Call Home DOTS client MUST silently discard such 606 message as only a Call Home DOTS server can initiate a new (D)TLS 607 connection. 609 If a Call Home DOTS client wants to redirect a Call Home DOTS server 610 to another Call Home DOTS client, it MUST send a Non-confirmable PUT 611 request to the predefined resource ".well-known/dots/redirect" with 612 the new Call Home DOTS client FQDN or IP address in the body of the 613 PUT similar to what is described in Section 4.6 of 614 [I-D.ietf-dots-signal-channel]. Furthermore, a new clause called 615 'ttl" is defined to return the Time to live (TTL) of the alternate 616 Call Home DOTS client. 618 On receipt of this PUT request, the Call Home DOTS server responds 619 with a 2.01 (Created), closes this connection and establishes a 620 connection with the new Call Home DOTS client. The processing of the 621 TTL is defined in Section 4.6 of [I-D.ietf-dots-signal-channel]. If 622 the Call Home DOTS server cannot service the PUT request, the 623 response is rejected with a 4.00 (bad Request). 625 Figure 8 shows a PUT request example to convey the alternate Call 626 Home DOTS client 'alt-call-home-client.example' together with its IP 627 addresses 2001:db8:6401::1 and 2001:db8:6401::2. The validity of 628 this alternate Call Home DOTS client is 10 minutes. 630 Header: PUT (Code=0.03) 631 Uri-Path: ".well-known" 632 Uri-Path: "dots" 633 Uri-Path: "redirect" 634 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 635 Uri-Path: "mid=123" 636 Content-Format: "application/dots+cbor" 638 { 639 "ietf-dots-signal-channel:redirected-signal": { 640 "ietf-dots-call-home:alt-ch-client": 641 "alt-call-home-client.example", 642 "ietf-dots-call-home:alt-ch-client-record": [ 643 "2001:db8:6401::1", 644 "2001:db8:6401::2" 645 ], 646 "ietf-dots-call-home:ttl": 600 647 } 649 Figure 8: Example of a PUT Request for Redirected Signaling 651 3.3. DOTS Signal Channel Extension 653 3.3.1. Mitigation Request 655 This specification extends the mitigation request defined in 656 Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the attack 657 source information (e.g., source prefixes, source port numbers). The 658 DOTS client conveys the following new parameters in the CBOR body of 659 the mitigation request: 661 source-prefix: A list of attacker prefixes used to attack the 662 target. Prefixes are represented using Classless Inter-Domain 663 Routing (CIDR) notation [RFC4632]. 665 As a reminder, the prefix length MUST be less than or equal to 32 666 (or 128) for IPv4 (or IPv6). 668 The prefix list MUST NOT include broadcast, loopback, or multicast 669 addresses. These addresses are considered as invalid values. In 670 addition, the DOTS client MUST validate that attacker prefixes are 671 within the scope of the DOTS server domain. 673 This is an optional attribute for the base DOTS signal channel 674 operations. 676 source-port-range: A list of port numbers used by the attack traffic 677 flows. 679 A port range is defined by two bounds, a lower port number (lower- 680 port) and an upper port number (upper-port). When only 'lower- 681 port' is present, it represents a single port number. 683 For TCP, UDP, Stream Control Transmission Protocol (SCTP) 684 [RFC4960], or Datagram Congestion Control Protocol (DCCP) 685 [RFC4340], a range of ports can be any subrange of 0-65535, for 686 example, 0-1023, 1024-65535, or 1024-49151. 688 This is an optional attribute for the base DOTS signal channel 689 operations. 691 source-icmp-type-range: A list of ICMP types used by the attack 692 traffic flows. An ICMP type range is defined by two bounds, a 693 lower ICMP type (lower-type) and an upper ICMP type (upper-type). 694 When only 'lower-type' is present, it represents a single ICMP 695 type. 697 This is an optional attribute for the base DOTS signal channel 698 operations. 700 The 'source-prefix' parameter is a mandatory attribute when the 701 attack traffic information is signaled by a Call Home DOTS client 702 (i.e., the Call Home scenario depicted in Figure 7). The 'target- 703 uri' or 'target-fqdn' parameters can be included in a mitigation 704 request for diagnostic purposes to notify the Call Home DOTS server 705 domain administrator, but SHOULD NOT be used to determine the target 706 IP addresses. Note that 'target-prefix' becomes a mandatory 707 attribute in the mitigation request signaling the attack information 708 because 'target-uri' and 'target-fqdn' are optional attributes and 709 'alias-name' will not be conveyed in a mitigation request. 711 In order to help attack source identification by a Call Home DOTS 712 server, the Call Home DOTS client SHOULD include in its mitigation 713 request additional information such as 'source-port-range' or 714 'source-icmp-type-range'. The Call Home DOTS client may not include 715 such information if 'source-prefix' conveys an IPv6 address/prefix. 716 Address sharing implications on the setting of source information 717 ('source-prefix', 'source-port-range') are discussed in 718 Section 3.3.2. 720 Only immediate mitigation requests (i.e., 'trigger-mitigation' set to 721 'true') are allowed; Call Home DOTS clients MUST NOT send requests 722 with 'trigger-mitigation' set to 'false'. Such requests MUST be 723 discarded by the Call Home DOTS server with a 4.00 (Bad Request). 725 An example of a mitigation request sent by a Call Home DOTS client is 726 shown in Figure 9. 728 Header: PUT (Code=0.03) 729 Uri-Path: ".well-known" 730 Uri-Path: "dots" 731 Uri-Path: "mitigate" 732 Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" 733 Uri-Path: "mid=56" 734 Content-Format: "application/dots+cbor" 736 { 737 "ietf-dots-signal-channel:mitigation-scope": { 738 "scope": [ 739 { 740 "target-prefix": [ 741 "2001:db8:c000::/128" 742 ], 743 "ietf-dots-call-home:source-prefix": [ 744 "2001:db8:123::/128" 745 ], 746 "lifetime": 3600 747 } 748 ] 749 } 750 } 752 Figure 9: An Example of Mitigation Request Issued by a Call Home DOTS 753 Client 755 The Call Home DOTS server MUST check that the 'source-prefix' is 756 within the scope of the Call Home DOTS server domain. Note that in a 757 DOTS Call Home scenario, the Call Home DOTS server considers, by 758 default, that any routeable IP prefix enclosed in 'target-prefix' is 759 within the scope of the Call Home DOTS client. Invalid mitigation 760 requests are handled as per Section 4.4.1 of 761 [I-D.ietf-dots-signal-channel]. 763 Note: These validation checks do not apply when the source 764 information is included as a hint in the context of the base DOTS 765 signal channel. 767 The Call Home DOTS server domain administrator consent MAY be 768 required to block the traffic from the compromised device to the 769 attack target. An implementation MAY have a configuration knob to 770 block the traffic from the compromised device to the attack target 771 with or without DOTS server domain administrator consent. If the 772 attack traffic is blocked, the Call Home DOTS server informs the Call 773 Home DOTS client that the attack is being mitigated. 775 If the attack traffic information is identified by the Call Home DOTS 776 server or the Call Home DOTS server domain administrator as 777 legitimate traffic, the mitigation request is rejected, and 4.09 778 (Conflict) is returned to the Call Home DOTS client. The conflict- 779 clause (defined in Section 4.4.1 of [I-D.ietf-dots-signal-channel]) 780 indicates the cause of the conflict. The following new value is 781 defined: 783 4: Mitigation request rejected. This code is returned by the DOTS 784 server to indicate the attack traffic has been classified as 785 legitimate traffic. 787 Once the request is validated by the Call Home DOTS server, 788 appropriate actions are enforced to block the attack traffic within 789 the source network. The Call Home DOTS client is informed about the 790 progress of the attack mitigation following the rules in 791 [I-D.ietf-dots-signal-channel]. For example, if the Call Home DOTS 792 server is embedded in a CPE, it can program the packet processor to 793 punt all the traffic from the compromised device to the target to 794 slow path. The CPE inspects the punted slow path traffic to detect 795 and block the outgoing DDoS attack traffic or quarantine the device 796 (e.g., using MAC level filtering) until it is remediated, and 797 notifies the CPE administrator about the compromised device. 799 The DOTS agents follow the same procedures specified in 800 [I-D.ietf-dots-signal-channel] for managing a mitigation request. 802 3.3.2. Address Sharing Considerations 804 If a Carrier Grade NAT (CGN, including NAT64) is located between the 805 DOTS client domain and DOTS server domain, communicating an external 806 IP address in a mitigation request is likely to be discarded by the 807 Call Home DOTS server because the external IP address is not visible 808 locally to the Call Home DOTS server (see Figure 10). The Call Home 809 DOTS server is only aware of the internal IP addresses/prefixes bound 810 to its domain. Thus, the Call Home DOTS client MUST NOT include the 811 external IP address and/or port number identifying the suspect attack 812 source, but MUST include the internal IP address and/or port number. 813 To that aim, the Call Home DOTS client SHOULD rely on mechanisms, 814 such as [RFC8512] or [RFC8513], to retrieve the internal IP address 815 and port number which are mapped to an external IP address and port 816 number. 818 N | .-------------------. 819 E | ( )-. 820 T | .' ' 821 W | ( Call Home ) 822 O | ( DOTS client -' 823 R | '-( ) 824 K | '-------+-----------' 825 | | 826 P | | 827 R | +---+---+ 828 O | | CGN | External Realm 829 V |..............| |...................... 830 I | | | Internal Realm 831 D | +---+---+ 832 E | | 833 R | | 834 --- | 835 .---------+---------. 836 ( )-. 837 .' Source Network ' 838 ( ) 839 ( Call Home -' 840 '-( DOTS server ) 841 '------+------------' 842 | 843 +-----+-------+ 844 |Attack Source| 845 +-------------+ 847 Figure 10: Example of a CGN between DOTS Domains 849 If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the 850 provider's domain to service its customers, the identification of an 851 attack source bound to an IPv4 address/prefix MUST also rely on 852 source port numbers because the same IPv4 address is assigned to 853 multiple customers. The port information is required to 854 unambiguously identify the source of an attack. 856 If a translator is enabled on the boundaries of the domain hosting 857 the Call Home DOTS server (e.g., a CPE with NAT enabled as shown in 858 Figures 11 and 12), the Call Home DOTS server uses the attack traffic 859 information conveyed in a mitigation request to find the internal 860 source IP address of the compromised device and blocks the traffic 861 from the compromised device traffic to the attack target until the 862 mitigation request is withdrawn. Doing so allows to isolate the 863 suspicious device while avoiding to disturb other services. 865 .-------------------. 866 ( )-. 867 .' Network Provider (DMS)' 868 ( ) 869 ( Call Home -' 870 '-( DOTS client ) 871 '-------+-----------' 872 | 873 --- +---+---+ 874 S | | CPE | External Realm 875 O |..............| |................ 876 U | | NAT | Internal Realm 877 R | +---+---+ 878 C | | 879 E | .---------+---------. 880 | ( )-. 881 N | .' ' 882 E | ( Call Home ) 883 T | ( DOTS server -' 884 W | '-( ) 885 O | '-------+-----------' 886 R | | 887 K | +------+------+ 888 | |Attack Source| 889 +-------------+ 891 Figure 11: Example of a DOTS Server Domain with a NAT Embedded in a 892 CPE 894 .-------------------. 895 ( )-. 896 .' Network Provider (DMS) ' 897 ( ) 898 ( Call Home -' 899 '-( DOTS client ) 900 '---------+---------' 901 | 902 --- +-----+-----+ 903 S | | CPE/NAT | External Realm 904 O |..............| |................ 905 U | | Call Home | Internal Realm 906 R | |DOTS server| 907 C | +-----+-----+ 908 E | | 909 | .-----------+-------. 910 | ( )-. 911 N | .' ' 912 E | ( Local Area Network ) 913 T | ( -' 914 W | '-( ) 915 O | '--------+----------' 916 R | | 917 K | +------+------+ 918 | |Attack Source| 919 +-------------+ 921 Figure 12: Example of a Call Home DOTS Server and a NAT Embedded in a 922 CPE 924 3.3.3. DOTS Signal Call Home YANG Module 926 3.3.3.1. Tree Structure 928 This document augments the "ietf-dots-signal-channel" DOTS signal 929 YANG module defined in [I-D.ietf-dots-signal-channel] for signaling 930 the attack traffic information. This document defines the YANG 931 module "ietf-dots-call-home", which has the following tree structure: 933 module: ietf-dots-call-home 934 augment /ietf-signal:dots-signal/ietf-signal:message-type 935 /ietf-signal:mitigation-scope/ietf-signal:scope: 936 +--rw source-prefix* inet:ip-prefix {source-signaling}? 937 +--rw source-port-range* [lower-port] {source-signaling}? 938 | +--rw lower-port inet:port-number 939 | +--rw upper-port? inet:port-number 940 +--rw source-icmp-type-range* 941 | [lower-type] {source-signaling}? 942 +--rw lower-type uint8 943 +--rw upper-type? uint8 944 augment /ietf-signal:dots-signal/ietf-signal:message-type 945 /ietf-signal:redirected-signal: 946 +--rw alt-ch-client string {call-home}? 947 +--rw alt-ch-client-record* inet:ip-address {call-home}? 948 +--rw ttl uint32 {call-home}? 950 3.3.3.2. YANG Module 952 This module uses the common YANG types defined in [RFC6991]. 954 file "ietf-dots-call-home@2019-09-06.yang" 956 module ietf-dots-call-home { 957 yang-version 1.1; 958 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home"; 959 prefix call-home; 961 import ietf-inet-types { 962 prefix inet; 963 reference 964 "Section 4 of RFC 6991"; 965 } 966 import ietf-dots-signal-channel { 967 prefix ietf-signal; 968 reference 969 "RFC YYYY: Distributed Denial-of-Service Open Threat 970 Signaling (DOTS) Signal Channel Specification"; 971 } 973 organization 974 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 975 contact 976 "WG Web: 977 WG List: 979 Author: Konda, Tirumaleswar Reddy 980 ; 982 Author: Mohamed Boucadair 983 ; 985 Author: Jon Shallow 986 "; 988 description 989 "This module contains YANG definitions for the signaling 990 messages exchanged between a DOTS client and a DOTS server 991 for the Call Home deployment scenario. 993 Copyright (c) 2019 IETF Trust and the persons identified as 994 authors of the code. All rights reserved. 996 Redistribution and use in source and binary forms, with or 997 without modification, is permitted pursuant to, and subject 998 to the license terms contained in, the Simplified BSD License 999 set forth in Section 4.c of the IETF Trust's Legal Provisions 1000 Relating to IETF Documents 1001 (http://trustee.ietf.org/license-info). 1003 This version of this YANG module is part of RFC XXXX; see 1004 the RFC itself for full legal notices."; 1006 revision 2019-09-06 { 1007 description 1008 "Initial revision."; 1009 reference 1010 "RFC XXXX: Distributed Denial-of-Service Open Threat 1011 Signaling (DOTS) Signal Channel Call Home"; 1012 } 1014 feature source-signaling { 1015 description 1016 "This feature means that source-related information 1017 can be supplied in mitigation requests. This is 1018 typically applicable for DOTS Call Home."; 1019 } 1020 feature call-home { 1021 description 1022 "This feature means that Call Home functionality 1023 is supported."; 1024 } 1026 augment "/ietf-signal:dots-signal/ietf-signal:message-type/" 1027 + "ietf-signal:mitigation-scope/ietf-signal:scope" { 1029 if-feature source-signaling; 1030 description "Attacker source details."; 1032 leaf-list source-prefix { 1033 type inet:ip-prefix; 1034 description 1035 "IPv4 or IPv6 prefix identifying the attacker(s)."; 1036 } 1037 list source-port-range { 1038 key "lower-port"; 1039 description 1040 "Port range. When only lower-port is 1041 present, it represents a single port number."; 1042 leaf lower-port { 1043 type inet:port-number; 1044 mandatory true; 1045 description 1046 "Lower port number of the port range."; 1047 } 1048 leaf upper-port { 1049 type inet:port-number; 1050 must ". >= ../lower-port" { 1051 error-message 1052 "The upper port number must be greater than 1053 or equal to lower port number."; 1054 } 1055 description 1056 "Upper port number of the port range."; 1057 } 1058 } 1059 list source-icmp-type-range { 1060 key "lower-type"; 1061 description 1062 "ICMP type range. When only lower-type is 1063 present, it represents a single ICMP type."; 1064 leaf lower-type { 1065 type uint8; 1066 mandatory true; 1067 description 1068 "Lower ICMP type of the ICMP type range."; 1069 } 1070 leaf upper-type { 1071 type uint8; 1072 must ". >= ../lower-type" { 1073 error-message 1074 "The upper ICMP type must be greater than 1075 or equal to lower ICMP type."; 1076 } 1077 description 1078 "Upper type of the ICMP type range."; 1079 } 1080 } 1081 } 1083 augment "/ietf-signal:dots-signal/ietf-signal:message-type/" 1084 + "ietf-signal:redirected-signal" { 1085 if-feature call-home; 1086 description 1087 "The alternate Call Home DOTS client."; 1089 leaf alt-ch-client { 1090 type string; 1091 description 1092 "FQDN of an alternate Call Home DOTS client."; 1093 } 1094 leaf-list alt-ch-client-record { 1095 type inet:ip-address; 1096 description 1097 "List of records for the alternate Call Home 1098 DOTS client."; 1099 } 1100 leaf ttl { 1101 type uint32; 1102 units "seconds"; 1103 description 1104 "The Time to live (TTL) of the alternate Call Home 1105 DOTS client."; 1106 } 1107 } 1108 } 1109 1111 4. IANA Considerations 1113 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number 1115 IANA is requested to assign the port number TBD to the DOTS signal 1116 channel Call Home protocol for both UDP and TCP from the "Service 1117 Name and Transport Protocol Port Number Registry" available at: 1118 https://www.iana.org/assignments/service-names-port-numbers/service- 1119 names-port-numbers.xhtml. 1121 Service Name: dots-call-home 1122 Port Number: TBD 1123 Transport Protocol(s): TCP/UDP 1124 Description: DOTS Signal Channel Call Home 1125 Assignee: IESG 1126 Contact: IETF Chair 1127 Reference: RFC XXXX 1129 The assignment of port number 4647 is strongly suggested (DOTS signal 1130 channel uses port number 4646). 1132 4.2. DOTS Signal Channel CBOR Mappings Registry 1134 This specification registers the 'source-prefix', 'source-port- 1135 range', and 'source-icmp-type-range' parameters in the IANA "DOTS 1136 Signal Channel CBOR Key Values" registry established by 1137 [I-D.ietf-dots-signal-channel] (Figure 13). 1139 The 'source-prefix', 'source-port-range', and 'source-icmp-type- 1140 range' are comprehension-optional parameters. 1142 o Note to the RFC Editor: Please delete (TBD1)-(TBD8) once CBOR keys 1143 are assigned from the 0x8000 - 0xBFFF range. 1145 +-------------------+------------+--------+---------------+--------+ 1146 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 1147 | | Type | Key | Type & | Type | 1148 | | | | Information | | 1149 +-------------------+------------+--------+---------------+--------+ 1150 | source-prefix | leaf-list | 0x8000 | 4 array | Array | 1151 | | inet: | (TBD1) | | | 1152 | | ip-prefix | | 3 text string | String | 1153 | source-port-range | list | 0x8001 | 4 array | Array | 1154 | | | (TBD2) | | | 1155 | source-icmp-type- | list | 0x8002 | 4 array | Array | 1156 | range | | (TBD3) | | | 1157 | lower-type | uint8 | 0x8003 | 0 unsigned | Number | 1158 | | | (TBD4) | | | 1159 | upper-type | uint8 | 0x8004 | 0 unsigned | Number | 1160 | | | (TBD5) | | | 1161 | alt-ch-client | string | 0x8005 | 3 text string | String | 1162 | | | (TBD6) | | | 1163 | alt-ch-client- | leaf-list | 0x8006 | 4 array | Array | 1164 | record | inet: | (TBD7) | | | 1165 | | ip-address| | 3 text string | String | 1166 | ttl | uint32 | 0x8007 | 0 unsigned | Number | 1167 | | | (TBD8) | | | 1168 +-------------------+------------+--------+---------------+--------+ 1170 Figure 13: Assigned DOTS Signal Channel CBOR Key Values 1172 4.3. New DOTS Conflict Cause 1174 This document requests IANA to assign a new code from the "DOTS 1175 Signal Channel Conflict Cause Codes" registry: 1177 +-----+-----------------------------------+-------------+-----------+ 1178 | Cod | Label | Description | Reference | 1179 | e | | | | 1180 +-----+-----------------------------------+-------------+-----------+ 1181 | 4 | request-rejected-legitimate- | Mitigation | [RFCXXXX] | 1182 | | traffic | request | | 1183 | | | rejected. | | 1184 | | | This code | | 1185 | | | is returned | | 1186 | | | by the DOTS | | 1187 | | | server to | | 1188 | | | indicate | | 1189 | | | the attack | | 1190 | | | traffic has | | 1191 | | | been | | 1192 | | | classified | | 1193 | | | as | | 1194 | | | legitimate | | 1195 | | | traffic. | | 1196 +-----+-----------------------------------+-------------+-----------+ 1198 4.4. DOTS Signal Call Home YANG Module 1200 This document requests IANA to register the following URI in the "ns" 1201 subregistry within the "IETF XML Registry" [RFC3688]: 1203 URI: urn:ietf:params:xml:ns:yang:ietf-dots-call-home 1204 Registrant Contact: The IESG. 1205 XML: N/A; the requested URI is an XML namespace. 1207 This document requests IANA to register the following YANG module in 1208 the "YANG Module Names" subregistry [RFC7950] within the "YANG 1209 Parameters" registry: 1211 name: ietf-dots-call-home 1212 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home 1213 maintained by IANA: N 1214 prefix: call-home 1215 reference: RFC XXXX 1217 5. Security Considerations 1219 This document deviates from classic DOTS signal channel usage by 1220 having the DOTS server initiate the (D)TLS connection. DOTS signal 1221 channel related security considerations discussed in Section 10 of 1222 [I-D.ietf-dots-signal-channel] MUST be considered. DOTS agents MUST 1223 authenticate each other using (D)TLS before a DOTS signal channel 1224 session is considered valid. 1226 An attacker may launch a DoS attack on the DOTS client by having it 1227 perform computationally expensive operations, before deducing that 1228 the attacker doesn't possess a valid key. For instance, in TLS 1.3 1229 [RFC8446], the ServerHello message contains a Key Share value based 1230 on an expensive asymmetric key operation for key establishment. 1231 Common precautions mitigating DoS attacks are recommended, such as 1232 temporarily blacklisting the source address after a set number of 1233 unsuccessful authentication attempts. 1235 Call Home DOTS servers may not blindly trust mitigation requests from 1236 Call Home DOTS clients. For example, DOTS servers can use the attack 1237 flow information in a mitigation request to enable full-fledged 1238 packet inspection function to inspect all the traffic from the 1239 compromised device to the target or to re-direct the traffic from the 1240 compromised device to the target to a DDoS mitigation system to scrub 1241 the suspicious traffic. Call Home DOTS servers can also seek the 1242 consent of DOTS server domain administrator to block the traffic from 1243 the compromised device to the target (see Section 3.3.1). 1245 6. Privacy Considerations 1247 The considerations discussed in [RFC6973] were taken into account to 1248 assess whether the DOTS Call Home introduces privacy threats. 1250 Concretely, the protocol does not leak any new information that can 1251 be used to ease surveillance. In particular, the Call Home DOTS 1252 server is not required to share information that is local to its 1253 network (e.g., internal identifiers of an attack source) with the 1254 Call Home DOTS client. 1256 The DOTS Call Home does not preclude the validation of mitigation 1257 requests received from a Call Home DOTS client. For example, a 1258 security service running on the CPE may require administrator's 1259 consent before the CPE acts upon the mitigation request indicated by 1260 the Call Home DOTS client. How the consent is obtained is out of 1261 scope of this document. 1263 Note that a Call Home DOTS server can seek for an administrator's 1264 consent, validate the request by inspecting the traffic, or proceed 1265 with both. 1267 The DOTS Call Home is only advisory in nature. Concretely, the DOTS 1268 Call Home does not impose any action to be enforced within the 1269 network hosting an attack source; it is up to the Call Home DOTS 1270 server (and/or network administrator) to decide whether and which 1271 actions are required. 1273 Moreover, the DOTS Call Home avoids misattribution by appropriately 1274 identifying the network to which a suspect attack source belongs to 1275 (e.g., address sharing issues discussed in Section 3.3.1). 1277 Triggers to send a DOTS mitigation request to a Call Home DOTS server 1278 are deployment-specific. For example, a Call Home DOTS client may 1279 rely on the output of some DDoS detection systems deployed within the 1280 DOTS client domain to detect potential outbound DDoS attacks or on 1281 abuse claims received from remote victim networks. Such DDoS 1282 detection and mitigation techniques are not meant to track the 1283 activity of users, but to protect the Internet and avoid altering the 1284 IP reputation of the DOTS client domain. 1286 7. Contributors 1288 The following individuals have contributed to this document: 1290 Joshi Harsha 1291 McAfee, Inc. 1292 Embassy Golf Link Business Park 1293 Bangalore, Karnataka 560071 1294 India 1296 Email: harsha_joshi@mcafee.com 1298 Wei Pan 1299 Huawei Technologies 1300 China 1302 Email: william.panwei@huawei.com 1304 8. Acknowledgements 1306 Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Toema 1307 Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments. 1309 9. References 1311 9.1. Normative References 1313 [I-D.ietf-dots-signal-channel] 1314 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 1315 Teague, "Distributed Denial-of-Service Open Threat 1316 Signaling (DOTS) Signal Channel Specification", draft- 1317 ietf-dots-signal-channel-37 (work in progress), July 2019. 1319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1320 Requirement Levels", BCP 14, RFC 2119, 1321 DOI 10.17487/RFC2119, March 1997, 1322 . 1324 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1325 DOI 10.17487/RFC3688, January 2004, 1326 . 1328 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1329 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1330 January 2012, . 1332 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1333 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1334 . 1336 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1337 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1338 . 1340 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1341 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1342 May 2017, . 1344 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1345 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1346 . 1348 9.2. Informative References 1350 [I-D.ietf-dots-multihoming] 1351 Boucadair, M., K, R., and W. Pan, "Multi-homing Deployment 1352 Considerations for Distributed-Denial-of-Service Open 1353 Threat Signaling (DOTS)", draft-ietf-dots-multihoming-02 1354 (work in progress), July 2019. 1356 [I-D.ietf-dots-server-discovery] 1357 Boucadair, M. and R. K, "Distributed-Denial-of-Service 1358 Open Threat Signaling (DOTS) Agent Discovery", draft-ietf- 1359 dots-server-discovery-05 (work in progress), August 2019. 1361 [I-D.ietf-dots-use-cases] 1362 Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, 1363 L., and K. Nishizuka, "Use cases for DDoS Open Threat 1364 Signaling", draft-ietf-dots-use-cases-20 (work in 1365 progress), September 2019. 1367 [I-D.ietf-i2nsf-terminology] 1368 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1369 Birkholz, "Interface to Network Security Functions (I2NSF) 1370 Terminology", draft-ietf-i2nsf-terminology-08 (work in 1371 progress), July 2019. 1373 [I-D.ietf-idr-flow-spec-v6] 1374 McPherson, D., Raszuk, R., Pithawala, B., 1375 akarch@cisco.com, a., and S. Hares, "Dissemination of Flow 1376 Specification Rules for IPv6", draft-ietf-idr-flow-spec- 1377 v6-09 (work in progress), November 2017. 1379 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1380 Translator (NAT) Terminology and Considerations", 1381 RFC 2663, DOI 10.17487/RFC2663, August 1999, 1382 . 1384 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1385 Congestion Control Protocol (DCCP)", RFC 4340, 1386 DOI 10.17487/RFC4340, March 2006, 1387 . 1389 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1390 (CIDR): The Internet Address Assignment and Aggregation 1391 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1392 2006, . 1394 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1395 Denial-of-Service Considerations", RFC 4732, 1396 DOI 10.17487/RFC4732, December 2006, 1397 . 1399 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1400 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1401 . 1403 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1404 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1405 . 1407 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1408 and D. McPherson, "Dissemination of Flow Specification 1409 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1410 . 1412 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 1413 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 1414 2011, . 1416 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1417 Morris, J., Hansen, M., and R. Smith, "Privacy 1418 Considerations for Internet Protocols", RFC 6973, 1419 DOI 10.17487/RFC6973, July 2013, 1420 . 1422 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1423 Farrer, "Lightweight 4over6: An Extension to the Dual- 1424 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 1425 July 2015, . 1427 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 1428 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 1429 Port with Encapsulation (MAP-E)", RFC 7597, 1430 DOI 10.17487/RFC7597, July 2015, 1431 . 1433 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1434 RFC 8071, DOI 10.17487/RFC8071, February 2017, 1435 . 1437 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1438 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1439 . 1441 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1442 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1443 Address Translation (NAT) and Network Prefix Translation 1444 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1445 . 1447 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 1448 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 1449 DOI 10.17487/RFC8513, January 2019, 1450 . 1452 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 1453 Jacquenet, "An Inventory of Transport-Centric Functions 1454 Provided by Middleboxes: An Operator Perspective", 1455 RFC 8517, DOI 10.17487/RFC8517, February 2019, 1456 . 1458 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 1459 Things (IoT) Security: State of the Art and Challenges", 1460 RFC 8576, DOI 10.17487/RFC8576, April 2019, 1461 . 1463 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 1464 Threat Signaling (DOTS) Requirements", RFC 8612, 1465 DOI 10.17487/RFC8612, May 2019, 1466 . 1468 [Sec] UK Department for Digital Culture, Media & Sport, "Secure 1469 by Design: Improving the cyber security of consumer 1470 Internet of Things Report", March 2018, 1471 . 1474 Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home 1476 With the DOTS signal channel Call Home, there is a chance that two 1477 DOTS agents can simultaneously establish two DOTS signal channels 1478 with different directions (base DOTS signal channel and DOTS signal 1479 channel Call Home). Here is one example drawn from the home network. 1480 Nevertheless, the outcome of the discussion is not specific to these 1481 networks, but applies to any DOTS Call Home scenario. 1483 In the Call Home scenario, the DOTS server in, for example, the home 1484 network can mitigate the DDoS attacks launched by the compromised 1485 device in its domain by receiving the mitigation request sent by the 1486 Call Home DOTS client in the ISP environment. In addition, the DOTS 1487 client in the home network can initiate a mitigation request to the 1488 DOTS server in the ISP environment to ask for help when the home 1489 network is under a DDoS attack. Such DOTS server and DOTS client in 1490 the home network can co-locate in the same home network element 1491 (e.g., the Customer Premises Equipment). In this case, with the same 1492 peer at the same time the home network element will have the base 1493 DOTS signal channel and the DOTS signal channel Call Home defined in 1494 this specification. Thus, these two signal channels need to be 1495 distinguished when they are both supported. Two approaches have been 1496 considered for distinguishing the two DOTS signal channels, but only 1497 the one that using the dedicated port number has been chosen as the 1498 best choice. 1500 By using a dedicated port number for each, these two signal channels 1501 can be separated unambiguously and easily. For example, the CPE uses 1502 the port number 4646 allocated in [I-D.ietf-dots-signal-channel] to 1503 initiate the basic signal channel to the ISP when it acts as the DOTS 1504 client, and uses the port number TBD to initiate the signal channel 1505 Call Home. Based on the different port numbers, the ISP can directly 1506 decide which kind of procedures should follow immediately after it 1507 receives the DOTS messages. This approach just requires two (D)TLS 1508 sessions to be established respectively for the basic signal channel 1509 and signal channel Call Home. 1511 The other approach is signaling the role of each DOTS agent (e.g., by 1512 using the DOTS data channel). For example, the DOTS agent in the 1513 home network first initiates a DOTS data channel to the peer DOTS 1514 agent in the ISP environment, at this time the DOTS agent in the home 1515 network is the DOTS client and the peer DOTS agent in the ISP 1516 environment is the DOTS server. After that, the DOTS agent in the 1517 home network retrieves the DOTS Call Home capability of the peer DOTS 1518 agent. If the peer supports the DOTS Call Home, the DOTS agent needs 1519 to subscribe to the peer to use this extension. Then, the reversal 1520 of DOTS role can be recognized as done by both DOTS agents. When the 1521 DOTS agent in the ISP environment, which now is the DOTS client, 1522 wants to filter the attackers' traffic, it requests the DOTS agent in 1523 the home network, which now is the DOTS server, for help. 1525 Signaling the role will complicate the DOTS protocol, and this 1526 complexity is not required in context where the DOTS Call Home is not 1527 required or only when the DOTS Call Home is needed. Besides, the 1528 DOTS data channel may not work during attack time. Even if changing 1529 the above example from using the DOTS data channel to the DOTS signal 1530 channel, the more procedures will still reduce the efficiency. Using 1531 the dedicated port number is much easier and more concise compared to 1532 the second approach, and its cost that establishing two (D)TLS 1533 sessions is much less. So, using a dedicated port number for the 1534 DOTS Call Home is chosen in this specification. 1536 Authors' Addresses 1538 Tirumaleswar Reddy 1539 McAfee, Inc. 1540 Embassy Golf Link Business Park 1541 Bangalore, Karnataka 560071 1542 India 1544 Email: kondtir@gmail.com 1546 Mohamed Boucadair 1547 Orange 1548 Rennes 35000 1549 France 1551 Email: mohamed.boucadair@orange.com 1553 Jon Shallow 1554 UK 1556 Email: supjps-ietf@jpshallow.com