idnits 2.17.1 draft-ietf-dots-signal-call-home-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 623 has weird spacing: '...er-port ine...' == Line 627 has weird spacing: '...er-type uin...' -- The document date (May 31, 2019) is 1791 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 810, but not defined == Unused Reference: 'RFC4732' is defined on line 997, but no explicit reference was found in the text == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-34 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-13) exists of draft-ietf-dots-multihoming-01 == Outdated reference: A later version (-15) exists of draft-ietf-dots-server-discovery-03 == Outdated reference: A later version (-25) exists of draft-ietf-dots-use-cases-17 -- 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: 1 error (**), 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: December 2, 2019 Orange 6 J. Shallow 7 May 31, 2019 9 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 10 Channel Call Home 11 draft-ietf-dots-signal-call-home-02 13 Abstract 15 This document specifies the DOTS signal channel Call Home service, 16 which 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 Call Home service is not specific to the home networks; the 23 solution targets any deployment which requires to block DDoS attack 24 traffic closer to the source(s) of a DDoS attack. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 2, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 4 63 1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 7 66 3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.2. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 8 68 3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 9 69 3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 9 70 3.3.2. DOTS Signal Call Home YANG Module . . . . . . . . . . 14 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 72 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 17 73 4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 17 74 4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 18 75 4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 18 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 77 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 78 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 82 9.2. Informative References . . . . . . . . . . . . . . . . . 21 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 85 1. Introduction 87 1.1. The Problem 89 The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is 90 used to carry information about a network resource or a network (or a 91 part thereof) that is under a Distributed Denial of Service (DDoS) 92 attack. Such information is sent by a DOTS client to one or multiple 93 DOTS servers so that appropriate mitigation actions are undertaken on 94 traffic deemed suspicious. Various use cases are discussed in 95 [I-D.ietf-dots-use-cases]. 97 Internet of Things (IoT) devices are becoming more and more prevalent 98 in home networks, and with compute and memory becoming cheaper and 99 cheaper, various types of IoT devices become available in the 100 consumer market at affordable price. But on the downside, the main 101 threat being most of these IoT devices are bought off-the-shelf and 102 most manufacturers haven't considered security in the product design. 103 IoT devices deployed in home networks can be easily compromised, they 104 do not have an easy mechanism to upgrade, and IoT manufactures may 105 cease manufacture and/or discontinue patching vulnerabilities on IoT 106 devices (Sections 5.4 and 5.5 of [RFC8576]). However, these 107 vulnerable and compromised devices will continue to be used for a 108 long period of time in the home, and the end-user does not know that 109 IoT devices in his/her home are compromised. The compromised IoT 110 devices are typically used for launching DDoS attacks (Section 3 of 111 [RFC8576]) on victims while the owner/administrator of the home 112 network is not aware about such misbehaviors. Similar to other DDoS 113 attacks, the victim in this attack can be an application server, a 114 host, a router, a firewall, or an entire network. 116 Nowadays, network devices in a home network offer network security 117 (e.g., firewall or Intrusion Protection System (IPS) service on a 118 home router) to protect the devices connected to the home network 119 from both external and internal attacks. Over the years several 120 techniques have been identified to detect DDoS attacks, some of these 121 techniques can be enabled on home network devices but most of them 122 are used in the Internet Service Provider (ISP)'s network. The ISP 123 offering DDoS mitigation service can detect outgoing DDoS attack 124 traffic originating from its subscribers or the ISP may receive 125 filtering rules (e.g., using BGP flowspec [RFC5575]) from a 126 downstream service provider to filter, block, or rate-limit DDoS 127 attack traffic originating from the ISP's subscribers to a downstream 128 target. 130 Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris, 131 and Transport Layer Security (TLS) re-negotiation are difficult to 132 detect on a home network device without adversely affecting its 133 performance. The reason is typically home devices such as home 134 routers have fast path to boost the throughput. For every new TCP/ 135 UDP flow, only the first few packets are punted through the slow 136 path. Hence, it is not possible to detect various DDoS attacks in 137 the slow path, since the attack payload is sent to the target server 138 after the flow is switched to fast path. Deep Packet Inspection 139 (DPI) of all the packets of a flow would be able to detect some of 140 the attacks. However, a full-fledged DPI to detect these type of 141 DDoS attacks is functionally or operationally not possible for all 142 the devices attached to the home network owing to the memory and CPU 143 limitations of the home routers. Further, for certain DDoS attacks 144 the ability to distinguish legitimate traffic from attacker traffic 145 on a per packet basis is complex. This complexity is due to that the 146 packet itself may look "legitimate" and no attack signature can be 147 identified. The anomaly can be identified only after detailed 148 statistical analysis. 150 The ISP on the other hand can detect some DDoS attacks originating 151 from a home network (e.g., Section 2.6 of [RFC8517]), but the ISP 152 does not have a mechanism to detect which device in the home network 153 is generating the DDoS attack traffic. The primary reason being that 154 devices in an IPv4 home network are typically behind a Network 155 Address Translation (NAT) border. Even in case of a IPv6 home 156 network, although the ISP can identify the infected device in the 157 home network launching the DDoS traffic by tracking its unique IPv6 158 address, the infected device can easily change its IPv6 address to 159 evade remediation. 161 Existing approaches are still suffering from misused access network 162 resources by abusing devices; the support of means for blocking such 163 attacks close to the sources are missing. In particular, the DOTS 164 signal protocol does not discuss cooperative DDoS mitigation between 165 the network hosting an attack source and the ISP to the suppress the 166 outbound DDoS attack traffic originating from that network. 168 1.2. The Solution 170 This specification addresses the problems discussed in Section 1.1 171 and presents the DOTS signal channel Call Home extension, which 172 enables the DOTS server to initiate a secure connection to the DOTS 173 client, and the DOTS client then conveys the attack traffic 174 information to the DOTS server. 176 A DOTS client relies upon a variety of triggers to make use of the 177 Call Home function (e.g., scrubbing the traffic from the attack 178 source, receiving an alert from an attack target, a peer DDoS 179 Mitigation System (DMS), or a transit provider). The definition of 180 these triggers is deployment-specific. It is therefore out of the 181 scope of this document to elaborate on how these triggers are made 182 available to a DOTS client. 184 In a typical deployment scenario, the DOTS server is enabled on a 185 Customer Premises Equipment (CPE), which is aligned with recent 186 trends to enrich the CPE with advanced security features. Unlike 187 classic DOTS deployments [I-D.ietf-dots-use-cases], such DOTS server 188 maintains a single DOTS signal channel session for each DOTS-capable 189 upstream provisioning domain [I-D.ietf-dots-multihoming]. 191 For instance, the DOTS server in the home network initiates the Call 192 Home in 'idle' time and then subsequently the DOTS client in the ISP 193 environment can initiate a mitigation request whenever the ISP 194 detects there is an attack from a compromised device in the DOTS 195 server domain (i.e., from within the home network). 197 The DOTS server uses the DDoS attack traffic information to identify 198 the compromised device in its domain that is responsible for 199 launching the DDoS attack, optionally notifies a network 200 administrator, and takes appropriate mitigation action(s). A 201 mitigation action can be to quarantine the compromised device or 202 block its traffic to the attack target(s) until the mitigation 203 request is withdrawn. 205 Other motivations for introducing the Call Home function are 206 discussed in Section 1.1 of [RFC8071]. 208 This document assumes that DOTS servers are provisioned with a way to 209 know how to reach the upstream DOTS client(s), which could occur by a 210 variety of means (e.g., [I-D.ietf-dots-server-discovery]). The 211 specification of such means are out of scope of this document. 213 1.3. Applicability Scope 215 The aforementioned problems may be encountered in other deployments 216 than those discussed in Section 1.1 (e.g., data centers, enterprise 217 networks). The solution specified in this document can be used for 218 those deployments to block DDoS attack traffic closer to the 219 source(s) of the attack. The Call Home reference architecture is 220 shown in Figure 1. 222 +-------------+ 223 |Attack Target| 224 +-----+-------+ 225 | /\ 226 | || Target Network 227 ......................|.||.................... 228 | || 229 .--------+-||-------. 230 ( || )-. 231 .' || ' 232 ( Internet || ) 233 ( || -' 234 '-( || ) 235 '------+-||---------' 236 ......................|.||..................... 237 | || Network Provider 238 | || (DMS) 239 .--------+-||-------. 240 ( || )-. 241 .' DOTS || ' 242 ( client || ) 243 ( || -' 244 '-( || ) 245 '------+-||---------' 246 | || 247 ......................|.||....................... 248 | || Source Network 249 .--------+-||-------. 250 ( || )-. 251 .' DOTS || ' 252 ( server || Outbound ) 253 ( || DDoS -' 254 '-( || Attack ) 255 '------+-||---------' 256 | || 257 +-----+-++----+ 258 |Attack Source| 259 +-------------+ 261 Figure 1: Call Home Reference Architecture 263 It is out of the scope of this document to identify an exhaustive 264 list of such deployments. 266 2. Terminology 268 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 269 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 270 "OPTIONAL" in this document are to be interpreted as described in BCP 271 14 [RFC2119][RFC8174] when, and only when, they appear in all 272 capitals, as shown here. 274 The reader should be familiar with the terms defined in 275 [I-D.ietf-dots-requirements]. 277 The meaning of the symbols in YANG tree diagrams is defined in 278 [RFC8340]. 280 (D)TLS is used for statements that apply to both Transport Layer 281 Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS) 282 [RFC6347]. Specific terms are used for any statement that applies to 283 either protocol alone. 285 3. DOTS Signal Channel Call Home 287 3.1. Procedure 289 The DOTS signal channel Call Home extension preserves all but one of 290 the DOTS client/server roles in the DOTS protocol stack, as compared 291 to DOTS client-initiated DOTS signal channel protocol 292 [I-D.ietf-dots-signal-channel]. The role reversal that occurs is at 293 the (D)TLS layer; that is, (1) the DOTS server acts as a DTLS client 294 and the DOTS client acts as a DTLS server or (2) the DOTS server acts 295 as a TLS client initiating the underlying TCP connection and the DOTS 296 client acts as a TLS server. The DOTS server initiates (D)TLS 297 handshake to the DOTS client. 299 For example, a home network element (e.g., home router) co-located 300 with a DOTS server (likely, a client-domain DOTS gateway) is the 301 (D)TLS server. However, when calling home, the DOTS server initially 302 assumes the role of the (D)TLS client, but the network element's role 303 as a DOTS server remains the same. Furthermore, existing certificate 304 chains and mutual authentication mechanisms between the DOTS agents 305 are unaffected by the Call Home function. This Call Home function 306 enables the DOTS server co-located with a network element (possibly 307 behind NATs and firewalls) reachable by only the intended DOTS client 308 and hence the DOTS server cannot be subjected to DDoS attacks. 310 Figure 2 illustrates a sample Call Home flow exchange: 312 +--------+ +--------+ 313 | DOTS | | DOTS | 314 | server | | client | 315 +---+----+ +----+---+ 316 | | 317 | 1. (D)TLS connection | 318 |----------------------------------->| 319 | 2. Mitigation request | 320 |<-----------------------------------| 321 | ... | 323 Figure 2: DOTS Signal Channel Call Home Sequence Diagram 325 The DOTS signal channel Call Home procedure is as follows: 327 1. If UDP transport is used, the DOTS server begins by initiating a 328 DTLS connection to the DOTS client. The DOTS client MUST support 329 accepting DTLS connection on the IANA-assigned port number 330 defined in Section 4.1, but MAY be configured to listen to a 331 different port number. 333 If TCP is used, the DOTS server begins by initiating a TCP 334 connection to the DOTS client. The DOTS client MUST support 335 accepting TCP connections on the IANA-assigned port number 336 defined in Section 4.1, but MAY be configured to listen to a 337 different port number. Using this TCP connection, the DOTS 338 server initiates a TLS connection to the DOTS client. 340 The Happy Eyeballs mechanism explained in Section 4.3 of 341 [I-D.ietf-dots-signal-channel] can be used for initiating (D)TLS 342 connections. 344 2. Using this (D)TLS connection, the DOTS client may request, 345 withdraw, or retrieve the status of mitigation requests. 347 3.2. Heartbeat Mechanism 349 The Heartbeat mechanism used for the Call Home deviates from the one 350 defined in Section 4.7 of [I-D.ietf-dots-signal-channel]. This 351 section specifies the behavior to be followed by DOTS agents for the 352 Call Home. 354 Once the (D)TLS section is established between the DOTS agents, the 355 DOTS client contacts the DOTS server to retrieve the session 356 configuration parameters (Section 4.5 of 357 [I-D.ietf-dots-signal-channel]). The DOTS server adjusts the 358 'heartbeat-interval' to accommodate binding timers used by on-path 359 NATs and firewalls. Heartbeats will be then exchanged by the DOTS 360 agents following the instructions retrieved using the signal channel 361 session configuration exchange. 363 It is the responsibility of DOTS servers to ensure that on-path 364 translators/firewalls are maintaining a binding so that the same 365 external IP address and/or port number is retained for the DOTS 366 signal channel session. A DOTS client MAY trigger their heartbeat 367 requests immediately after receiving heartbeat probes from its peer 368 DOTS server. 370 When an outgoing attack that saturates the outgoing link from the 371 DOTS server is detected and reported by a DOTS client, the latter 372 MUST continue to use the signal channel even if no traffic is 373 received from the DOTS server. It is most likely that the outgoing 374 traffic is exceeding the DOTS server domain capacity. As a reminder, 375 the DOTS client cannot initiate a (D)TLS connection. 377 If the DOTS server receives traffic from the DOTS client, the DOTS 378 server MUST continue to use the signal channel even if the missing 379 heartbeat allowed threshold is reached. 381 If the DOTS server does not receive any traffic from the peer DOTS 382 client, the DOTS server sends heartbeat requests to the DOTS client 383 and after maximum 'missing-hb-allowed' threshold is reached, the DOTS 384 server concludes the session is disconnected. Then, the DOTS server 385 MUST try to resume the (D)TLS session. 387 3.3. DOTS Signal Channel Extension 389 3.3.1. Mitigation Request 391 This specification extends the mitigation request defined in 392 Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the 393 attacker source prefixes and source port numbers. The DOTS client 394 conveys the following new parameters in the CBOR body of the 395 mitigation request: 397 source-prefix: A list of attacker prefixes used to attack the 398 target. Prefixes are represented using Classless Inter-Domain 399 Routing (CIDR) notation [RFC4632]. 401 As a reminder, the prefix length MUST be less than or equal to 32 402 (resp. 128) for IPv4 (resp. IPv6). 404 The prefix list MUST NOT include broadcast, loopback, or multicast 405 addresses. These addresses are considered as invalid values. In 406 addition, the DOTS client MUST validate that attacker prefixes are 407 within the scope of the DOTS server domain. 409 This is an optional attribute. 411 source-port-range: A list of port numbers used by the attack traffic 412 flows. 414 A port range is defined by two bounds, a lower port number (lower- 415 port) and an upper port number (upper-port). When only 'lower- 416 port' is present, it represents a single port number. 418 For TCP, UDP, Stream Control Transmission Protocol (SCTP) 419 [RFC4960], or Datagram Congestion Control Protocol (DCCP) 420 [RFC4340], a range of ports can be, for example, 0-1023, 421 1024-65535, or 1024-49151. 423 This is an optional attribute. 425 source-icmp-type: A list of ICMP types used by the attack traffic 426 flows. An ICMP type range is defined by two bounds, a lower ICMP 427 type (lower-type) and an upper ICMP type (upper-type). When only 428 'lower-type' is present, it represents a single ICMP type. 430 This is an optional attribute. 432 The 'source-prefix' parameter is a mandatory attribute when the 433 attack traffic information is signaled by a DOTS client in the Call 434 Home scenario. The 'target-uri' or 'target-fqdn' parameters can be 435 included in a mitigation request for diagnostic purposes to notify 436 the DOTS server domain administrator, but SHOULD NOT be used to 437 determine the target IP addresses. Note that 'target-prefix' becomes 438 a mandatory attribute in the mitigation request signaling the attack 439 information because 'target-uri' and 'target-fqdn' are optional 440 attributes and 'alias-name' will not be conveyed in a mitigation 441 request. 443 In order to help attack source identification by a DOTS server, the 444 DOTS client SHOULD include in its mitigation request additional 445 information such as 'source-port-range' or 'source-icmp-type-range'. 446 The DOTS client may not include such information if 'source-prefix' 447 conveys an IPv6 address/prefix. 449 Only immediate mitigation requests (i.e., 'trigger-mitigation' set to 450 'true') are allowed; DOTS clients MUST NOT send requests with 451 'trigger-mitigation' set to 'false'. Such requests MUST be discarded 452 by the DOTS server with a 4.00 (Bad Request). 454 If a Carrier Grade NAT (CGN, including NAT64) is located between the 455 DOTS client domain and DOTS server domain, communicating an external 456 IP address in a mitigation request is likely to be discarded by the 457 DOTS server because the external IP address is not visible locally to 458 the DOTS server (see Figure 3). The DOTS server is only aware of the 459 internal IP addresses/prefixes bound to its domain. Thus, the DOTS 460 client MUST NOT include the external IP address and/or port number 461 identifying the suspect attack source, but MUST include the internal 462 IP address and/or port number. To that aim, the DOTS client SHOULD 463 rely on mechanisms, such as [RFC8512] or [RFC8513], to retrieve the 464 internal IP address and port number which are mapped to an external 465 IP address and port number. 467 N | .-------------------. 468 E | ( )-. 469 T | .' ' 470 W | ( ) 471 O | ( DOTS client -' 472 R | '-( ) 473 K | '-------+-----------' 474 | | 475 P | | 476 R | +---+---+ 477 O | | CGN | External Realm 478 V |..............| |...................... 479 I | | | Internal Realm 480 D | +---+---+ 481 E | | 482 R | | 483 --- | 484 .---------+---------. 485 ( )-. 486 .' Source Network ' 487 ( ) 488 ( DOTS server -' 489 '-( ) 490 '------+------------' 491 | 492 +-----+-------+ 493 |Attack Source| 494 +-------------+ 496 Figure 3: Example of a CGN between DOTS Domains 498 If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the 499 provider's domain to service its customers, the identification of an 500 attack source bound to an IPv4 address/prefix MUST also rely on 501 source port numbers because the same IPv4 address is assigned to 502 multiple customers. The port information is required to 503 unambiguously identify the source of an attack. 505 The DOTS server MUST check that the 'source-prefix' is within the 506 scope of the DOTS server domain in the Call Home scenario. Note that 507 in such scenario, the DOTS server considers, by default, that any 508 routeable IP prefix enclosed in 'target-prefix' is within the scope 509 of the DOTS client. Invalid mitigation requests are handled as per 510 Section 4.4.1 of [I-D.ietf-dots-signal-channel]. 512 If a translator is enabled on the boundaries of the domain hosting 513 the DOTS server (e.g., a CPE with NAT enabled as shown in Figures 4 514 and 5), the DOTS server uses the attack traffic information conveyed 515 in a mitigation request to find the internal source IP address of the 516 compromised device and blocks the traffic from the compromised device 517 traffic to the attack target until the mitigation request is 518 withdrawn. Doing so allows to isolate the suspicious device while 519 avoiding to disturb other services. 521 .-------------------. 522 ( )-. 523 .' Network Provider ' 524 ( (DMS) ) 525 ( DOTS client -' 526 '-( ) 527 '------+------------' 528 | 529 | 530 --- +--+----+ 531 S | | CPE | External Realm 532 O |..............| |................ 533 U | | NAT | Internal Realm 534 R | +-------+ 535 C | | 536 E | .--------+----------. 537 | ( )-. 538 N | .' ' 539 E | ( ) 540 T | ( DOTS server -' 541 W | '-( ) 542 O | '------+------------' 543 R | | 544 K | +-----+-------+ 545 | |Attack Source| 546 +-------------+ 548 Figure 4: Example of a DOTS Server Domain with a NAT Embeded in a CPE 549 .-------------------. 550 ( )-. 551 .' Network Provider ' 552 ( (DMS) ) 553 ( DOTS client -' 554 '-( ) 555 '---------+---------' 556 | 557 | 558 --- +-----+-----+ 559 S | | CPE/NAT | External Realm 560 O |..............| |................ 561 U | |DOTS server| Internal Realm 562 R | +-----------+ 563 C | | 564 E | .--------+----------. 565 | ( )-. 566 N | .' ' 567 E | ( Local Area Network ) 568 T | ( -' 569 W | '-( ) 570 O | '------+------------' 571 R | | 572 K | +-----+-------+ 573 | |Attack Source| 574 +-------------+ 576 Figure 5: Example of a DOTS Server and a NAT Embeded in a CPE 578 The DOTS server domain administrator consent MAY be required to block 579 the traffic from the compromised device to the attack target. An 580 implementation MAY have a configuration knob to block the traffic 581 from the compromised device to the attack target with or without DOTS 582 server domain administrator consent. If the attack traffic is 583 blocked, the DOTS server informs the DOTS client that the attack is 584 being mitigated. 586 If the attack traffic information is identified by the DOTS server or 587 the DOTS server domain administrator as legitimate traffic, the 588 mitigation request is rejected, and 4.09 (Conflict) is returned to 589 the DOTS client. The conflict-clause (defined in Section 4.4.1 of 590 [I-D.ietf-dots-signal-channel]) indicates the cause of the conflict. 591 The following new value is defined: 593 4: Mitigation request rejected. This code is returned by the DOTS 594 server to indicate the attack traffic has been classified as 595 legitimate traffic. 597 Once the request is validated by the DOTS server, appropriate actions 598 are enforced to block the attack traffic within the source network. 599 The DOTS client is informed about the progress of the attack 600 mitigation following the rules in [I-D.ietf-dots-signal-channel]. 601 For example, if the DOTS server is embedded in a CPE, it can program 602 the packet processor to punt all the traffic from the compromised 603 device to the target to slow path. The CPE inspects the punted slow 604 path traffic to detect and block the outgoing DDoS attack traffic or 605 quarantine the device (e.g., using MAC level filtering) until it is 606 remediated, and notifies the CPE administrator about the compromised 607 device. 609 3.3.2. DOTS Signal Call Home YANG Module 611 3.3.2.1. Tree Structure 613 This document augments the "dots-signal-channel" DOTS signal YANG 614 module defined in [I-D.ietf-dots-signal-channel] for signaling the 615 attack traffic information. This document defines the YANG module 616 "ietf-dots-call-home", which has the following tree structure: 618 module: ietf-dots-call-home 619 augment /ietf-signal:dots-signal/ietf-signal:message-type 620 /ietf-signal:mitigation-scope/ietf-signal:scope: 621 +--rw source-prefix* inet:ip-prefix {source-signaling}? 622 +--rw source-port-range* [lower-port] {source-signaling}? 623 | +--rw lower-port inet:port-number 624 | +--rw upper-port? inet:port-number 625 +--rw source-icmp-type-range* 626 | [lower-type] {source-signaling}? 627 +--rw lower-type uint8 628 +--rw upper-type? uint8 630 3.3.2.2. YANG Module 632 This module uses the common YANG types defined in [RFC6991]. 634 file "ietf-dots-call-home@2019-04-25.yang" 636 module ietf-dots-call-home { 637 yang-version 1.1; 638 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home"; 639 prefix call-home; 641 import ietf-inet-types { 642 prefix inet; 643 reference 644 "Section 4 of RFC 6991"; 645 } 646 import ietf-dots-signal-channel { 647 prefix ietf-signal; 648 reference 649 "RFC YYYY: Distributed Denial-of-Service Open Threat 650 Signaling (DOTS) Signal Channel Specification"; 651 } 653 organization 654 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 655 contact 656 "WG Web: 657 WG List: 659 Author: Konda, Tirumaleswar Reddy 660 ; 662 Author: Mohamed Boucadair 663 ; 665 Author: Jon Shallow 666 "; 668 description 669 "This module contains YANG definitions for the signaling 670 messages exchanged between a DOTS client and a DOTS server 671 for the Call Home deployment scenario. 673 Copyright (c) 2019 IETF Trust and the persons identified as 674 authors of the code. All rights reserved. 676 Redistribution and use in source and binary forms, with or 677 without modification, is permitted pursuant to, and subject 678 to the license terms contained in, the Simplified BSD License 679 set forth in Section 4.c of the IETF Trust's Legal Provisions 680 Relating to IETF Documents 681 (http://trustee.ietf.org/license-info). 683 This version of this YANG module is part of RFC XXXX; see 684 the RFC itself for full legal notices."; 686 revision 2019-04-25 { 687 description 688 "Initial revision."; 689 reference 690 "RFC XXXX: Distributed Denial-of-Service Open Threat 691 Signaling (DOTS) Signal Channel Call Home"; 693 } 695 feature source-signaling { 696 description 697 "This feature means that source-related information 698 can be supplied in mitigation requests."; 699 } 701 augment "/ietf-signal:dots-signal/ietf-signal:message-type/" 702 + "ietf-signal:mitigation-scope/ietf-signal:scope" { 703 if-feature source-signaling; 704 description "Attacker source details."; 706 leaf-list source-prefix { 707 type inet:ip-prefix; 708 description 709 "IPv4 or IPv6 prefix identifying the attacker(s)."; 710 } 711 list source-port-range { 712 key "lower-port"; 713 description 714 "Port range. When only lower-port is 715 present, it represents a single port number."; 716 leaf lower-port { 717 type inet:port-number; 718 mandatory true; 719 description 720 "Lower port number of the port range."; 721 } 722 leaf upper-port { 723 type inet:port-number; 724 must ". >= ../lower-port" { 725 error-message 726 "The upper port number must be greater than 727 or equal to lower port number."; 728 } 729 description 730 "Upper port number of the port range."; 731 } 732 } 733 list source-icmp-type-range { 734 key "lower-type"; 735 description 736 "ICMP type range. When only lower-type is 737 present, it represents a single ICMP type."; 738 leaf lower-type { 739 type uint8; 740 mandatory true; 741 description 742 "Lower ICMP type of the ICMP type range."; 743 } 744 leaf upper-type { 745 type uint8; 746 must ". >= ../lower-type" { 747 error-message 748 "The upper ICMP type must be greater than 749 or equal to lower ICMP type."; 750 } 751 description 752 "Upper type of the ICMP type range."; 753 } 754 } 755 } 756 } 757 759 4. IANA Considerations 761 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number 763 IANA is requested to assign the port number TBD to the DOTS signal 764 channel Call Home protocol for both UDP and TCP from the "Service 765 Name and Transport Protocol Port Number Registry" available at: 766 https://www.iana.org/assignments/service-names-port-numbers/service- 767 names-port-numbers.xhtml. 769 The assignment of port number 4647 is strongly suggested (DOTS signal 770 channel uses port number 4646). 772 4.2. DOTS Signal Channel CBOR Mappings Registry 774 This specification registers the 'source-prefix' and 'source-port- 775 range' parameters in the IANA "DOTS Signal Channel CBOR Mappings" 776 registry established by [I-D.ietf-dots-signal-channel]. 778 The 'source-prefix', 'source-port-range', and 'source-icmp-type- 779 range' are comprehension-optional parameters. 781 o Note to the RFC Editor: Please delete (TBD1)-(TBD5) once CBOR keys 782 are assigned from the 0x8000 - 0xBFFF range. 784 +-------------------+------------+--------+---------------+--------+ 785 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 786 | | Type | Key | Type & | Type | 787 | | | | Information | | 788 +-------------------+------------+--------+---------------+--------+ 789 | source-prefix | leaf-list | 0x8000 | 4 array | Array | 790 | | inet: | (TBD1) | | | 791 | | ip-prefix | | 3 text string | String | 792 | source-port-range | list | 0x8001 | 4 array | Array | 793 | | | (TBD2) | | | 794 | source-icmp-type- | list | 0x8002 | 4 array | Array | 795 | range | | (TBD3) | | | 796 | lower-type | uint8 | 0x8003 | 0 unsigned | Number | 797 | | | (TBD4) | | | 798 | upper-type | uint8 | 0x8004 | 0 unsigned | Number | 799 | | | (TBD5) | | | 800 +-------------------+------------+--------+---------------+--------+ 802 4.3. New DOTS Conflict Cause 804 This document requests IANA to assign a new code from the "DOTS 805 Conflict Cause Codes" registry: 807 +------+------------------+-----------------------------+-----------+ 808 | Code | Label | Description | Reference | 809 +------+------------------+-----------------------------+-----------+ 810 | 4 | request-rejected | Mitigation request | [RFCXXXX] | 811 | | | rejected. This code is | | 812 | | | returned by the DOTS server | | 813 | | | to indicate the attack | | 814 | | | traffic has been classified | | 815 | | | as legitimate traffic. | | 816 +------+------------------+-----------------------------+-----------+ 818 4.4. DOTS Signal Call Home YANG Module 820 This document requests IANA to register the following URI in the 821 "IETF XML Registry" [RFC3688]: 823 URI: urn:ietf:params:xml:ns:yang:ietf-dots-call-home 824 Registrant Contact: The IESG. 825 XML: N/A; the requested URI is an XML namespace. 827 This document requests IANA to register the following YANG module in 828 the "YANG Module Names" registry [RFC7950]. 830 Name: ietf-call-home 831 Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home 832 Maintained by IANA: N 833 Prefix: call-home 834 Reference: RFC XXXX 836 5. Security Considerations 838 This document deviates from classic DOTS signal channel usage by 839 having the DOTS server initiate the (D)TLS connection. DOTS signal 840 channel related security considerations discussed in Section 10 of 841 [I-D.ietf-dots-signal-channel] MUST be considered. DOTS agents MUST 842 authenticate each other using (D)TLS before a DOTS signal channel 843 session is considered valid. 845 An attacker may launch a DoS attack on the DOTS client by having it 846 perform computationally expensive operations, before deducing that 847 the attacker doesn't possess a valid key. For instance, in TLS 1.3 848 [RFC8446], the ServerHello message contains a Key Share value based 849 on an expensive asymmetric key operation for key establishment. 850 Common precautions mitigating DoS attacks are recommended, such as 851 temporarily blacklisting the source address after a set number of 852 unsuccessful authentication attempts. 854 DOTS servers may not blindly trust mitigation requests from DOTS 855 clients. For example, DOTS servers can use the attack flow 856 information in a mitigation request to enable full-fledged packet 857 inspection function to inspect all the traffic from the compromised 858 to the target or to re-direct the traffic from the compromised device 859 to the target to a DDoS mitigation system to scrub the suspicious 860 traffic. DOTS servers can also seek the consent of DOTS server 861 domain administrator to block the traffic from the compromised device 862 to the target (see Section 3.3.1). 864 6. Privacy Considerations 866 The considerations discussed in [RFC6973] were taken into account to 867 assess whether the DOTS Call Home extension introduces privacy 868 threats. 870 Concretely, the protocol does not leak any new information that can 871 be used to ease surveillance. In particular, the DOTS server is not 872 required to share information that is local to its network (e.g., 873 internal identifiers of an attack source) with the DOTS client. 875 The DOTS Call Home extension does not preclude the validation of 876 mitigation requests received from a DOTS client. For example, a 877 security service running on the CPE may require administrator's 878 consent before the CPE acts upon the mitigation request indicated by 879 the DOTS client. How the consent is obtained is out of scope of this 880 document. 882 Note that a DOTS server can seek for an administrator's consent, 883 validate the request by inspecting the traffic, or proceed with both. 885 The DOTS Call Home extension is only advisory in nature. Concretely, 886 the DOTS Call Home extension does not impose any action to be 887 enforced within the home network; it is up to the DOTS server (and/or 888 network administrator) to decide whether and which actions are 889 required. 891 Moreover, the DOTS Call Home extension avoids misattribution by 892 appropriately identifying the network to which a suspect attack 893 source belongs to (e.g., address sharing issues discussed in 894 Section 3.3.1). 896 Triggers to send a DOTS mitigation request to a DOTS server are 897 deployment-specific. For example, a DOTS client may rely on the 898 output of some DDoS detection systems deployed within the DOTS client 899 domain to detect potential outbound DDoS attacks or on abuse claims 900 received from remote victim networks. Such DDoS detection and 901 mitigation techniques are not meant to track the activity of users, 902 but to protect the Internet and avoid altering the IP reputation of 903 the DOTS client domain. 905 7. Contributors 907 The following individuals have contributed to this document: 909 Joshi Harsha 910 McAfee, Inc. 911 Embassy Golf Link Business Park 912 Bangalore, Karnataka 560071 913 India 915 Email: harsha_joshi@mcafee.com 917 8. Acknowledgements 919 Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Toema 920 Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments. 922 9. References 924 9.1. Normative References 926 [I-D.ietf-dots-signal-channel] 927 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 928 Teague, "Distributed Denial-of-Service Open Threat 929 Signaling (DOTS) Signal Channel Specification", draft- 930 ietf-dots-signal-channel-34 (work in progress), May 2019. 932 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 933 Requirement Levels", BCP 14, RFC 2119, 934 DOI 10.17487/RFC2119, March 1997, 935 . 937 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 938 DOI 10.17487/RFC3688, January 2004, 939 . 941 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 942 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 943 January 2012, . 945 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 946 RFC 6991, DOI 10.17487/RFC6991, July 2013, 947 . 949 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 950 RFC 7950, DOI 10.17487/RFC7950, August 2016, 951 . 953 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 954 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 955 May 2017, . 957 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 958 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 959 . 961 9.2. Informative References 963 [I-D.ietf-dots-multihoming] 964 Boucadair, M. and R. K, "Multi-homing Deployment 965 Considerations for Distributed-Denial-of-Service Open 966 Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01 967 (work in progress), January 2019. 969 [I-D.ietf-dots-requirements] 970 Mortensen, A., K, R., and R. Moskowitz, "Distributed 971 Denial of Service (DDoS) Open Threat Signaling 972 Requirements", draft-ietf-dots-requirements-22 (work in 973 progress), March 2019. 975 [I-D.ietf-dots-server-discovery] 976 Boucadair, M. and R. K, "Distributed-Denial-of-Service 977 Open Threat Signaling (DOTS) Server Discovery", draft- 978 ietf-dots-server-discovery-03 (work in progress), May 979 2019. 981 [I-D.ietf-dots-use-cases] 982 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 983 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 984 Open Threat Signaling", draft-ietf-dots-use-cases-17 (work 985 in progress), January 2019. 987 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 988 Congestion Control Protocol (DCCP)", RFC 4340, 989 DOI 10.17487/RFC4340, March 2006, 990 . 992 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 993 (CIDR): The Internet Address Assignment and Aggregation 994 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 995 2006, . 997 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 998 Denial-of-Service Considerations", RFC 4732, 999 DOI 10.17487/RFC4732, December 2006, 1000 . 1002 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1003 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1004 . 1006 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1007 and D. McPherson, "Dissemination of Flow Specification 1008 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1009 . 1011 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1012 Morris, J., Hansen, M., and R. Smith, "Privacy 1013 Considerations for Internet Protocols", RFC 6973, 1014 DOI 10.17487/RFC6973, July 2013, 1015 . 1017 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1018 Farrer, "Lightweight 4over6: An Extension to the Dual- 1019 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 1020 July 2015, . 1022 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 1023 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 1024 Port with Encapsulation (MAP-E)", RFC 7597, 1025 DOI 10.17487/RFC7597, July 2015, 1026 . 1028 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1029 RFC 8071, DOI 10.17487/RFC8071, February 2017, 1030 . 1032 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1033 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1034 . 1036 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1037 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1038 Address Translation (NAT) and Network Prefix Translation 1039 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1040 . 1042 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 1043 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 1044 DOI 10.17487/RFC8513, January 2019, 1045 . 1047 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 1048 Jacquenet, "An Inventory of Transport-Centric Functions 1049 Provided by Middleboxes: An Operator Perspective", 1050 RFC 8517, DOI 10.17487/RFC8517, February 2019, 1051 . 1053 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 1054 Things (IoT) Security: State of the Art and Challenges", 1055 RFC 8576, DOI 10.17487/RFC8576, April 2019, 1056 . 1058 Authors' Addresses 1059 Tirumaleswar Reddy 1060 McAfee, Inc. 1061 Embassy Golf Link Business Park 1062 Bangalore, Karnataka 560071 1063 India 1065 Email: kondtir@gmail.com 1067 Mohamed Boucadair 1068 Orange 1069 Rennes 35000 1070 France 1072 Email: mohamed.boucadair@orange.com 1074 Jon Shallow 1075 UK 1077 Email: supjps-ietf@jpshallow.com