idnits 2.17.1 draft-ietf-dots-signal-call-home-03.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 662 has weird spacing: '...er-port ine...' == Line 666 has weird spacing: '...er-type uin...' -- The document date (July 08, 2019) is 1759 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 860, but not defined == Unused Reference: 'RFC4732' is defined on line 1057, 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-04 == 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: 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: January 9, 2020 Orange 6 J. Shallow 7 July 08, 2019 9 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal 10 Channel Call Home 11 draft-ietf-dots-signal-call-home-03 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 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 January 9, 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 91 3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 8 92 3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 8 93 3.2. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 9 94 3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 10 95 3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 10 96 3.3.2. Address Sharing Considerations . . . . . . . . . . . 12 97 3.3.3. DOTS Signal Call Home YANG Module . . . . . . . . . . 15 99 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 100 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 19 101 4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 19 102 4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 20 103 4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 21 104 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 105 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 106 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 107 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 108 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 109 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 110 9.2. Informative References . . . . . . . . . . . . . . . . . 24 111 Appendix A. Disambiguate Base DOTS Signal vs. Call Home . . . . 26 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 114 1. Introduction 116 1.1. The Problem 118 The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is 119 used to carry information about a network resource or a network (or a 120 part thereof) that is under a Distributed Denial of Service (DDoS) 121 attack. Such information is sent by a DOTS client to one or multiple 122 DOTS servers so that appropriate mitigation actions are undertaken on 123 traffic deemed suspicious. Various use cases are discussed in 124 [I-D.ietf-dots-use-cases]. 126 Internet of Things (IoT) devices are becoming more and more prevalent 127 in home networks, and with compute and memory becoming cheaper and 128 cheaper, various types of IoT devices become available in the 129 consumer market at affordable prices. But on the downside, the main 130 threat being most of these IoT devices are bought off-the-shelf and 131 most manufacturers haven't considered security in the product design. 132 IoT devices deployed in home networks can be easily compromised, they 133 do not have an easy mechanism to upgrade, and IoT manufactures may 134 cease manufacture and/or discontinue patching vulnerabilities on IoT 135 devices (Sections 5.4 and 5.5 of [RFC8576]). However, these 136 vulnerable and compromised devices will continue to be used for a 137 long period of time in the home, and the end-user does not know that 138 IoT devices in his/her home are compromised. The compromised IoT 139 devices are typically used for launching DDoS attacks (Section 3 of 140 [RFC8576]) on victims while the owner/administrator of the home 141 network is not aware about such misbehaviors. Similar to other DDoS 142 attacks, the victim in this attack can be an application server, a 143 host, a router, a firewall, or an entire network. 145 Nowadays, network devices in a home network offer network security 146 (e.g., firewall or Intrusion Protection System (IPS) service on a 147 home router) to protect the devices connected to the home network 148 from both external and internal attacks. Over the years several 149 techniques have been identified to detect DDoS attacks, some of these 150 techniques can be enabled on home network devices but most of them 151 are used in the Internet Service Provider (ISP)'s network. The ISP 152 offering DDoS mitigation service can detect outgoing DDoS attack 153 traffic originating from its subscribers or the ISP may receive 154 filtering rules (e.g., using BGP flowspec [RFC5575]) from a 155 downstream service provider to filter, block, or rate-limit DDoS 156 attack traffic originating from the ISP's subscribers to a downstream 157 target. 159 Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris, 160 and Transport Layer Security (TLS) re-negotiation are difficult to 161 detect on a home network device without adversely affecting its 162 performance. The reason is typically home devices such as home 163 routers have fast path to boost the throughput. For every new TCP/ 164 UDP flow, only the first few packets are punted through the slow 165 path. Hence, it is not possible to detect various DDoS attacks in 166 the slow path, since the attack payload is sent to the target server 167 after the flow is switched to fast path. Deep Packet Inspection 168 (DPI) of all the packets of a flow would be able to detect some of 169 the attacks. However, a full-fledged DPI to detect these type of 170 DDoS attacks is functionally or operationally not possible for all 171 the devices attached to the home network owing to the memory and CPU 172 limitations of the home routers. Further, for certain DDoS attacks 173 the ability to distinguish legitimate traffic from attacker traffic 174 on a per packet basis is complex. This complexity is due to that the 175 packet itself may look "legitimate" and no attack signature can be 176 identified. The anomaly can be identified only after detailed 177 statistical analysis. 179 The ISP on the other hand can detect some DDoS attacks originating 180 from a home network (e.g., Section 2.6 of [RFC8517]), but the ISP 181 does not have a mechanism to detect which device in the home network 182 is generating the DDoS attack traffic. The primary reason being that 183 devices in an IPv4 home network are typically behind a Network 184 Address Translation (NAT) border. Even in case of an IPv6 home 185 network, although the ISP can identify the infected device in the 186 home network launching the DDoS traffic by tracking its unique IPv6 187 address, the infected device can easily change its IPv6 address to 188 evade remediation. 190 Existing approaches are still suffering from misused access network 191 resources by abusing devices; the support of means for blocking such 192 attacks close to the sources are missing. In particular, the DOTS 193 signal protocol does not discuss cooperative DDoS mitigation between 194 the network hosting an attack source and the ISP to the suppress the 195 outbound DDoS attack traffic originating from that network. 197 1.2. The Solution 199 This specification addresses the problems discussed in Section 1.1 200 and presents the DOTS signal channel Call Home extension, which 201 enables the DOTS server to initiate a secure connection to the DOTS 202 client, and the DOTS client then conveys the attack traffic 203 information to the DOTS server. 205 A DOTS client relies upon a variety of triggers to make use of the 206 Call Home function (e.g., scrubbing the traffic from the attack 207 source, receiving an alert from an attack target, a peer DDoS 208 Mitigation System (DMS), or a transit provider). The definition of 209 these triggers is deployment-specific. It is therefore out of the 210 scope of this document to elaborate on how these triggers are made 211 available to a DOTS client. 213 In a typical deployment scenario, the DOTS server is enabled on a 214 Customer Premises Equipment (CPE), which is aligned with recent 215 trends to enrich the CPE with advanced security features. Unlike 216 classic DOTS deployments [I-D.ietf-dots-use-cases], such DOTS server 217 maintains a single DOTS signal channel session for each DOTS-capable 218 upstream provisioning domain [I-D.ietf-dots-multihoming]. 220 For instance, the DOTS server in the home network initiates the Call 221 Home in 'idle' time and then subsequently the DOTS client in the ISP 222 environment can initiate a mitigation request whenever the ISP 223 detects there is an attack from a compromised device in the DOTS 224 server domain (i.e., from within the home network). 226 The DOTS server uses the DDoS attack traffic information to identify 227 the compromised device in its domain that is responsible for 228 launching the DDoS attack, optionally notifies a network 229 administrator, and takes appropriate mitigation action(s). A 230 mitigation action can be to quarantine the compromised device or 231 block its traffic to the attack target(s) until the mitigation 232 request is withdrawn. 234 Other motivations for introducing the Call Home function are 235 discussed in Section 1.1 of [RFC8071]. 237 This document assumes that DOTS servers are provisioned with a way to 238 know how to reach the upstream DOTS client(s), which could occur by a 239 variety of means (e.g., [I-D.ietf-dots-server-discovery]). The 240 specification of such means are out of scope of this document. 242 1.3. Applicability Scope 244 The aforementioned problems may be encountered in other deployments 245 than those discussed in Section 1.1 (e.g., data centers, enterprise 246 networks). The solution specified in this document can be used for 247 those deployments to block DDoS attack traffic closer to the 248 source(s) of the attack. The Call Home reference architecture is 249 shown in Figure 1. 251 +-------------+ 252 |Attack Target| 253 +-----+-------+ 254 | /\ 255 | || Target Network 256 ......................|.||.................... 257 | || 258 .--------+-||-------. 259 ( || )-. 260 .' || ' 261 ( Internet || ) 262 ( || -' 263 '-( || ) 264 '------+-||---------' 265 ......................|.||..................... 266 | || Network Provider 267 | || (DMS) 268 .--------+-||-------. 269 ( || )-. 270 .' DOTS || ' 271 ( client || ) 272 ( || -' 273 '-( || ) 274 '------+-||---------' 275 | || 276 ......................|.||....................... 277 | || Source Network 278 .--------+-||-------. 279 ( || )-. 280 .' DOTS || ' 281 ( server || Outbound ) 282 ( || DDoS -' 283 '-( || Attack ) 284 '------+-||---------' 285 | || 286 +-----+-++----+ 287 |Attack Source| 288 +-------------+ 290 Figure 1: Call Home Reference Architecture 292 It is out of the scope of this document to identify an exhaustive 293 list of such deployments. 295 2. Terminology 297 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 298 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 299 "OPTIONAL" in this document are to be interpreted as described in BCP 300 14 [RFC2119][RFC8174] when, and only when, they appear in all 301 capitals, as shown here. 303 The reader should be familiar with the terms defined in [RFC8612]. 305 The meaning of the symbols in YANG tree diagrams is defined in 306 [RFC8340]. 308 (D)TLS is used for statements that apply to both Transport Layer 309 Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS) 310 [RFC6347]. Specific terms are used for any statement that applies to 311 either protocol alone. 313 3. DOTS Signal Channel Call Home 315 3.1. Procedure 317 The DOTS signal channel Call Home extension preserves all but one of 318 the DOTS client/server roles in the DOTS protocol stack, as compared 319 to DOTS client-initiated DOTS signal channel protocol 320 [I-D.ietf-dots-signal-channel]. The role reversal that occurs is at 321 the (D)TLS layer; that is, (1) the DOTS server acts as a DTLS client 322 and the DOTS client acts as a DTLS server or (2) the DOTS server acts 323 as a TLS client initiating the underlying TCP connection and the DOTS 324 client acts as a TLS server. The DOTS server initiates (D)TLS 325 handshake to the DOTS client. 327 For example, a home network element (e.g., home router) co-located 328 with a DOTS server (likely, a client-domain DOTS gateway) is the 329 (D)TLS server. However, when calling home, the DOTS server initially 330 assumes the role of the (D)TLS client, but the network element's role 331 as a DOTS server remains the same. Furthermore, existing certificate 332 chains and mutual authentication mechanisms between the DOTS agents 333 are unaffected by the Call Home function. This Call Home function 334 enables the DOTS server co-located with a network element (possibly 335 behind NATs and firewalls) reachable by only the intended DOTS client 336 and hence the DOTS server cannot be subjected to DDoS attacks. 338 Figure 2 illustrates a sample Call Home flow exchange: 340 +--------+ +--------+ 341 | DOTS | | DOTS | 342 | server | | client | 343 +---+----+ +----+---+ 344 (D)TLS client (D)TLS server 345 | | 346 | 1. (D)TLS connection | 347 |----------------------------------->| 348 | 2. Mitigation request | 349 |<-----------------------------------| 350 | ... | 352 Figure 2: DOTS Signal Channel Call Home Sequence Diagram 354 The DOTS signal channel Call Home procedure is as follows: 356 1. If UDP transport is used, the DOTS server begins by initiating a 357 DTLS connection to the DOTS client. 359 If TCP is used, the DOTS server begins by initiating a TCP 360 connection to the DOTS client. Using this TCP connection, the 361 DOTS server initiates a TLS connection to the DOTS client. 363 In some cases, a DOTS client and server may have mutual agreement 364 to use a specific port number, such as by explicit configuration 365 or dynamic discovery [I-D.ietf-dots-server-discovery]. Absent 366 such mutual agreement, the DOTS signal channel call home MUST run 367 over port number TBD (that is, DOTS clients must support 368 accepting DTLS (or TCP) connections on TBD) as defined in 369 Section 4.1, for both UDP and TCP. The interaction between the 370 base DOTS signal channel and the call home is discussed in 371 Appendix A. 373 The Happy Eyeballs mechanism explained in Section 4.3 of 374 [I-D.ietf-dots-signal-channel] can be used for initiating (D)TLS 375 connections. 377 2. Using this (D)TLS connection, the DOTS client may request, 378 withdraw, or retrieve the status of mitigation requests. 380 3.2. Heartbeat Mechanism 382 The Heartbeat mechanism used for the Call Home deviates from the one 383 defined in Section 4.7 of [I-D.ietf-dots-signal-channel]. This 384 section specifies the behavior to be followed by DOTS agents for the 385 Call Home. 387 Once the (D)TLS section is established between the DOTS agents, the 388 DOTS client contacts the DOTS server to retrieve the session 389 configuration parameters (Section 4.5 of 390 [I-D.ietf-dots-signal-channel]). The DOTS server adjusts the 391 'heartbeat-interval' to accommodate binding timers used by on-path 392 NATs and firewalls. Heartbeats will be then exchanged by the DOTS 393 agents following the instructions retrieved using the signal channel 394 session configuration exchange. 396 It is the responsibility of DOTS servers to ensure that on-path 397 translators/firewalls are maintaining a binding so that the same 398 external IP address and/or port number is retained for the DOTS 399 signal channel session. A DOTS client MAY trigger their heartbeat 400 requests immediately after receiving heartbeat probes from its peer 401 DOTS server. 403 When an outgoing attack that saturates the outgoing link from the 404 DOTS server is detected and reported by a DOTS client, the latter 405 MUST continue to use the signal channel even if no traffic is 406 received from the DOTS server. 408 If the DOTS server receives traffic from the DOTS client, the DOTS 409 server MUST continue to use the signal channel even if the missing 410 heartbeat allowed threshold is reached. 412 If the DOTS server does not receive any traffic from the peer DOTS 413 client, the DOTS server sends heartbeat requests to the DOTS client 414 and after maximum 'missing-hb-allowed' threshold is reached, the DOTS 415 server concludes the session is disconnected. Then, the DOTS server 416 MUST try to resume the (D)TLS session. 418 3.3. DOTS Signal Channel Extension 420 3.3.1. Mitigation Request 422 This specification extends the mitigation request defined in 423 Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the 424 attacker source prefixes and source port numbers. The DOTS client 425 conveys the following new parameters in the CBOR body of the 426 mitigation request: 428 source-prefix: A list of attacker prefixes used to attack the 429 target. Prefixes are represented using Classless Inter-Domain 430 Routing (CIDR) notation [RFC4632]. 432 As a reminder, the prefix length MUST be less than or equal to 32 433 (or 128) for IPv4 (or IPv6). 435 The prefix list MUST NOT include broadcast, loopback, or multicast 436 addresses. These addresses are considered as invalid values. In 437 addition, the DOTS client MUST validate that attacker prefixes are 438 within the scope of the DOTS server domain. 440 This is an optional attribute for the base DOTS signal channel 441 operations [I-D.ietf-dots-signal-channel]. 443 source-port-range: A list of port numbers used by the attack traffic 444 flows. 446 A port range is defined by two bounds, a lower port number (lower- 447 port) and an upper port number (upper-port). When only 'lower- 448 port' is present, it represents a single port number. 450 For TCP, UDP, Stream Control Transmission Protocol (SCTP) 451 [RFC4960], or Datagram Congestion Control Protocol (DCCP) 452 [RFC4340], a range of ports can be any subrange of 0-65535, for 453 example, 0-1023, 1024-65535, or 1024-49151. 455 This is an optional attribute for the base DOTS signal channel 456 operations [I-D.ietf-dots-signal-channel]. 458 source-icmp-type-range: A list of ICMP types used by the attack 459 traffic flows. An ICMP type range is defined by two bounds, a 460 lower ICMP type (lower-type) and an upper ICMP type (upper-type). 461 When only 'lower-type' is present, it represents a single ICMP 462 type. 464 This is an optional attribute for the base DOTS signal channel 465 operations [I-D.ietf-dots-signal-channel]. 467 The 'source-prefix' parameter is a mandatory attribute when the 468 attack traffic information is signaled by a DOTS client in the Call 469 Home scenario (depicted in Figure 2). The 'target-uri' or 'target- 470 fqdn' parameters can be included in a mitigation request for 471 diagnostic purposes to notify the DOTS server domain administrator, 472 but SHOULD NOT be used to determine the target IP addresses. Note 473 that 'target-prefix' becomes a mandatory attribute in the mitigation 474 request signaling the attack information because 'target-uri' and 475 'target-fqdn' are optional attributes and 'alias-name' will not be 476 conveyed in a mitigation request. 478 In order to help attack source identification by a DOTS server, the 479 DOTS client SHOULD include in its mitigation request additional 480 information such as 'source-port-range' or 'source-icmp-type-range'. 481 The DOTS client may not include such information if 'source-prefix' 482 conveys an IPv6 address/prefix. 484 Only immediate mitigation requests (i.e., 'trigger-mitigation' set to 485 'true') are allowed; DOTS clients MUST NOT send requests with 486 'trigger-mitigation' set to 'false'. Such requests MUST be discarded 487 by the DOTS server with a 4.00 (Bad Request). 489 The DOTS server MUST check that the 'source-prefix' is within the 490 scope of the DOTS server domain in the Call Home scenario. Note that 491 in such scenario, the DOTS server considers, by default, that any 492 routeable IP prefix enclosed in 'target-prefix' is within the scope 493 of the DOTS client. Invalid mitigation requests are handled as per 494 Section 4.4.1 of [I-D.ietf-dots-signal-channel]. 496 The DOTS server domain administrator consent MAY be required to block 497 the traffic from the compromised device to the attack target. An 498 implementation MAY have a configuration knob to block the traffic 499 from the compromised device to the attack target with or without DOTS 500 server domain administrator consent. If the attack traffic is 501 blocked, the DOTS server informs the DOTS client that the attack is 502 being mitigated. 504 If the attack traffic information is identified by the DOTS server or 505 the DOTS server domain administrator as legitimate traffic, the 506 mitigation request is rejected, and 4.09 (Conflict) is returned to 507 the DOTS client. The conflict-clause (defined in Section 4.4.1 of 508 [I-D.ietf-dots-signal-channel]) indicates the cause of the conflict. 509 The following new value is defined: 511 4: Mitigation request rejected. This code is returned by the DOTS 512 server to indicate the attack traffic has been classified as 513 legitimate traffic. 515 Once the request is validated by the DOTS server, appropriate actions 516 are enforced to block the attack traffic within the source network. 517 The DOTS client is informed about the progress of the attack 518 mitigation following the rules in [I-D.ietf-dots-signal-channel]. 519 For example, if the DOTS server is embedded in a CPE, it can program 520 the packet processor to punt all the traffic from the compromised 521 device to the target to slow path. The CPE inspects the punted slow 522 path traffic to detect and block the outgoing DDoS attack traffic or 523 quarantine the device (e.g., using MAC level filtering) until it is 524 remediated, and notifies the CPE administrator about the compromised 525 device. 527 3.3.2. Address Sharing Considerations 529 If a Carrier Grade NAT (CGN, including NAT64) is located between the 530 DOTS client domain and DOTS server domain, communicating an external 531 IP address in a mitigation request is likely to be discarded by the 532 DOTS server because the external IP address is not visible locally to 533 the DOTS server (see Figure 3). The DOTS server is only aware of the 534 internal IP addresses/prefixes bound to its domain. Thus, the DOTS 535 client MUST NOT include the external IP address and/or port number 536 identifying the suspect attack source, but MUST include the internal 537 IP address and/or port number. To that aim, the DOTS client SHOULD 538 rely on mechanisms, such as [RFC8512] or [RFC8513], to retrieve the 539 internal IP address and port number which are mapped to an external 540 IP address and port number. 542 N | .-------------------. 543 E | ( )-. 544 T | .' ' 545 W | ( ) 546 O | ( DOTS client -' 547 R | '-( ) 548 K | '-------+-----------' 549 | | 550 P | | 551 R | +---+---+ 552 O | | CGN | External Realm 553 V |..............| |...................... 554 I | | | Internal Realm 555 D | +---+---+ 556 E | | 557 R | | 558 --- | 559 .---------+---------. 560 ( )-. 561 .' Source Network ' 562 ( ) 563 ( DOTS server -' 564 '-( ) 565 '------+------------' 566 | 567 +-----+-------+ 568 |Attack Source| 569 +-------------+ 571 Figure 3: Example of a CGN between DOTS Domains 573 If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the 574 provider's domain to service its customers, the identification of an 575 attack source bound to an IPv4 address/prefix MUST also rely on 576 source port numbers because the same IPv4 address is assigned to 577 multiple customers. The port information is required to 578 unambiguously identify the source of an attack. 580 If a translator is enabled on the boundaries of the domain hosting 581 the DOTS server (e.g., a CPE with NAT enabled as shown in Figures 4 582 and 5), the DOTS server uses the attack traffic information conveyed 583 in a mitigation request to find the internal source IP address of the 584 compromised device and blocks the traffic from the compromised device 585 traffic to the attack target until the mitigation request is 586 withdrawn. Doing so allows to isolate the suspicious device while 587 avoiding to disturb other services. 589 .-------------------. 590 ( )-. 591 .' Network Provider ' 592 ( (DMS) ) 593 ( DOTS client -' 594 '-( ) 595 '------+------------' 596 | 597 | 598 --- +--+----+ 599 S | | CPE | External Realm 600 O |..............| |................ 601 U | | NAT | Internal Realm 602 R | +-------+ 603 C | | 604 E | .--------+----------. 605 | ( )-. 606 N | .' ' 607 E | ( ) 608 T | ( DOTS server -' 609 W | '-( ) 610 O | '------+------------' 611 R | | 612 K | +-----+-------+ 613 | |Attack Source| 614 +-------------+ 616 Figure 4: Example of a DOTS Server Domain with a NAT Embedded in a 617 CPE 619 .-------------------. 620 ( )-. 621 .' Network Provider ' 622 ( (DMS) ) 623 ( DOTS client -' 624 '-( ) 625 '---------+---------' 626 | 627 | 628 --- +-----+-----+ 629 S | | CPE/NAT | External Realm 630 O |..............| |................ 631 U | |DOTS server| Internal Realm 632 R | +-----------+ 633 C | | 634 E | .--------+----------. 635 | ( )-. 636 N | .' ' 637 E | ( Local Area Network ) 638 T | ( -' 639 W | '-( ) 640 O | '------+------------' 641 R | | 642 K | +-----+-------+ 643 | |Attack Source| 644 +-------------+ 646 Figure 5: Example of a DOTS Server and a NAT Embedded in a CPE 648 3.3.3. DOTS Signal Call Home YANG Module 650 3.3.3.1. Tree Structure 652 This document augments the "dots-signal-channel" DOTS signal YANG 653 module defined in [I-D.ietf-dots-signal-channel] for signaling the 654 attack traffic information. This document defines the YANG module 655 "ietf-dots-call-home", which has the following tree structure: 657 module: ietf-dots-call-home 658 augment /ietf-signal:dots-signal/ietf-signal:message-type 659 /ietf-signal:mitigation-scope/ietf-signal:scope: 660 +--rw source-prefix* inet:ip-prefix {source-signaling}? 661 +--rw source-port-range* [lower-port] {source-signaling}? 662 | +--rw lower-port inet:port-number 663 | +--rw upper-port? inet:port-number 664 +--rw source-icmp-type-range* 665 | [lower-type] {source-signaling}? 666 +--rw lower-type uint8 667 +--rw upper-type? uint8 669 3.3.3.2. YANG Module 671 This module uses the common YANG types defined in [RFC6991]. 673 file "ietf-dots-call-home@2019-04-25.yang" 675 module ietf-dots-call-home { 676 yang-version 1.1; 677 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home"; 678 prefix call-home; 680 import ietf-inet-types { 681 prefix inet; 682 reference 683 "Section 4 of RFC 6991"; 684 } 685 import ietf-dots-signal-channel { 686 prefix ietf-signal; 687 reference 688 "RFC YYYY: Distributed Denial-of-Service Open Threat 689 Signaling (DOTS) Signal Channel Specification"; 690 } 692 organization 693 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 694 contact 695 "WG Web: 696 WG List: 698 Author: Konda, Tirumaleswar Reddy 699 ; 701 Author: Mohamed Boucadair 702 ; 704 Author: Jon Shallow 705 "; 707 description 708 "This module contains YANG definitions for the signaling 709 messages exchanged between a DOTS client and a DOTS server 710 for the Call Home deployment scenario. 712 Copyright (c) 2019 IETF Trust and the persons identified as 713 authors of the code. All rights reserved. 715 Redistribution and use in source and binary forms, with or 716 without modification, is permitted pursuant to, and subject 717 to the license terms contained in, the Simplified BSD License 718 set forth in Section 4.c of the IETF Trust's Legal Provisions 719 Relating to IETF Documents 720 (http://trustee.ietf.org/license-info). 722 This version of this YANG module is part of RFC XXXX; see 723 the RFC itself for full legal notices."; 725 revision 2019-04-25 { 726 description 727 "Initial revision."; 728 reference 729 "RFC XXXX: Distributed Denial-of-Service Open Threat 730 Signaling (DOTS) Signal Channel Call Home"; 731 } 733 feature source-signaling { 734 description 735 "This feature means that source-related information 736 can be supplied in mitigation requests."; 737 } 739 augment "/ietf-signal:dots-signal/ietf-signal:message-type/" 740 + "ietf-signal:mitigation-scope/ietf-signal:scope" { 741 if-feature source-signaling; 742 description "Attacker source details."; 744 leaf-list source-prefix { 745 type inet:ip-prefix; 746 description 747 "IPv4 or IPv6 prefix identifying the attacker(s)."; 748 } 749 list source-port-range { 750 key "lower-port"; 751 description 752 "Port range. When only lower-port is 753 present, it represents a single port number."; 754 leaf lower-port { 755 type inet:port-number; 756 mandatory true; 757 description 758 "Lower port number of the port range."; 759 } 760 leaf upper-port { 761 type inet:port-number; 762 must ". >= ../lower-port" { 763 error-message 764 "The upper port number must be greater than 765 or equal to lower port number."; 766 } 767 description 768 "Upper port number of the port range."; 769 } 770 } 771 list source-icmp-type-range { 772 key "lower-type"; 773 description 774 "ICMP type range. When only lower-type is 775 present, it represents a single ICMP type."; 776 leaf lower-type { 777 type uint8; 778 mandatory true; 779 description 780 "Lower ICMP type of the ICMP type range."; 781 } 782 leaf upper-type { 783 type uint8; 784 must ". >= ../lower-type" { 785 error-message 786 "The upper ICMP type must be greater than 787 or equal to lower ICMP type."; 788 } 789 description 790 "Upper type of the ICMP type range."; 791 } 792 } 793 } 794 } 795 797 4. IANA Considerations 799 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number 801 IANA is requested to assign the port number TBD to the DOTS signal 802 channel Call Home protocol for both UDP and TCP from the "Service 803 Name and Transport Protocol Port Number Registry" available at: 804 https://www.iana.org/assignments/service-names-port-numbers/service- 805 names-port-numbers.xhtml. 807 Service Name: dots-call-home 808 Port Number: TBD 809 Transport Protocol(s): TCP/UDP 810 Description: DOTS Signal Channel Call Home 811 Assignee: IESG 812 Contact: IETF Chair 813 Reference: RFC XXXX 815 The assignment of port number 4647 is strongly suggested (DOTS signal 816 channel uses port number 4646). 818 4.2. DOTS Signal Channel CBOR Mappings Registry 820 This specification registers the 'source-prefix', 'source-port- 821 range', and 'source-icmp-type-range' parameters in the IANA "DOTS 822 Signal Channel CBOR Key Values" registry established by 823 [I-D.ietf-dots-signal-channel] (Figure 6). 825 The 'source-prefix', 'source-port-range', and 'source-icmp-type- 826 range' are comprehension-optional parameters. 828 o Note to the RFC Editor: Please delete (TBD1)-(TBD5) once CBOR keys 829 are assigned from the 0x8000 - 0xBFFF range. 831 +-------------------+------------+--------+---------------+--------+ 832 | Parameter Name | YANG | CBOR | CBOR Major | JSON | 833 | | Type | Key | Type & | Type | 834 | | | | Information | | 835 +-------------------+------------+--------+---------------+--------+ 836 | source-prefix | leaf-list | 0x8000 | 4 array | Array | 837 | | inet: | (TBD1) | | | 838 | | ip-prefix | | 3 text string | String | 839 | source-port-range | list | 0x8001 | 4 array | Array | 840 | | | (TBD2) | | | 841 | source-icmp-type- | list | 0x8002 | 4 array | Array | 842 | range | | (TBD3) | | | 843 | lower-type | uint8 | 0x8003 | 0 unsigned | Number | 844 | | | (TBD4) | | | 845 | upper-type | uint8 | 0x8004 | 0 unsigned | Number | 846 | | | (TBD5) | | | 847 +-------------------+------------+--------+---------------+--------+ 849 Figure 6: Assigned DOTS Signal Channel CBOR Key Values 851 4.3. New DOTS Conflict Cause 853 This document requests IANA to assign a new code from the "DOTS 854 Signal Channel Conflict Cause Codes" registry: 856 +-----+-----------------------------------+-------------+-----------+ 857 | Cod | Label | Description | Reference | 858 | e | | | | 859 +-----+-----------------------------------+-------------+-----------+ 860 | 4 | request-rejected-legitimate- | Mitigation | [RFCXXXX] | 861 | | traffic | request | | 862 | | | rejected. | | 863 | | | This code | | 864 | | | is returned | | 865 | | | by the DOTS | | 866 | | | server to | | 867 | | | indicate | | 868 | | | the attack | | 869 | | | traffic has | | 870 | | | been | | 871 | | | classified | | 872 | | | as | | 873 | | | legitimate | | 874 | | | traffic. | | 875 +-----+-----------------------------------+-------------+-----------+ 877 4.4. DOTS Signal Call Home YANG Module 879 This document requests IANA to register the following URI in the "ns" 880 subregistry within the "IETF XML Registry" [RFC3688]: 882 URI: urn:ietf:params:xml:ns:yang:ietf-dots-call-home 883 Registrant Contact: The IESG. 884 XML: N/A; the requested URI is an XML namespace. 886 This document requests IANA to register the following YANG module in 887 the "YANG Module Names" subregistry [RFC7950] within the "YANG 888 Parameters" registry: 890 name: ietf-call-home 891 namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home 892 maintained by IANA: N 893 prefix: call-home 894 reference: RFC XXXX 896 5. Security Considerations 898 This document deviates from classic DOTS signal channel usage by 899 having the DOTS server initiate the (D)TLS connection. DOTS signal 900 channel related security considerations discussed in Section 10 of 901 [I-D.ietf-dots-signal-channel] MUST be considered. DOTS agents MUST 902 authenticate each other using (D)TLS before a DOTS signal channel 903 session is considered valid. 905 An attacker may launch a DoS attack on the DOTS client by having it 906 perform computationally expensive operations, before deducing that 907 the attacker doesn't possess a valid key. For instance, in TLS 1.3 908 [RFC8446], the ServerHello message contains a Key Share value based 909 on an expensive asymmetric key operation for key establishment. 910 Common precautions mitigating DoS attacks are recommended, such as 911 temporarily blacklisting the source address after a set number of 912 unsuccessful authentication attempts. 914 DOTS servers may not blindly trust mitigation requests from DOTS 915 clients. For example, DOTS servers can use the attack flow 916 information in a mitigation request to enable full-fledged packet 917 inspection function to inspect all the traffic from the compromised 918 device to the target or to re-direct the traffic from the compromised 919 device to the target to a DDoS mitigation system to scrub the 920 suspicious traffic. DOTS servers can also seek the consent of DOTS 921 server domain administrator to block the traffic from the compromised 922 device to the target (see Section 3.3.1). 924 6. Privacy Considerations 926 The considerations discussed in [RFC6973] were taken into account to 927 assess whether the DOTS Call Home extension introduces privacy 928 threats. 930 Concretely, the protocol does not leak any new information that can 931 be used to ease surveillance. In particular, the DOTS server is not 932 required to share information that is local to its network (e.g., 933 internal identifiers of an attack source) with the DOTS client. 935 The DOTS Call Home extension does not preclude the validation of 936 mitigation requests received from a DOTS client. For example, a 937 security service running on the CPE may require administrator's 938 consent before the CPE acts upon the mitigation request indicated by 939 the DOTS client. How the consent is obtained is out of scope of this 940 document. 942 Note that a DOTS server can seek for an administrator's consent, 943 validate the request by inspecting the traffic, or proceed with both. 945 The DOTS Call Home extension is only advisory in nature. Concretely, 946 the DOTS Call Home extension does not impose any action to be 947 enforced within the home network; it is up to the DOTS server (and/or 948 network administrator) to decide whether and which actions are 949 required. 951 Moreover, the DOTS Call Home extension avoids misattribution by 952 appropriately identifying the network to which a suspect attack 953 source belongs to (e.g., address sharing issues discussed in 954 Section 3.3.1). 956 Triggers to send a DOTS mitigation request to a DOTS server are 957 deployment-specific. For example, a DOTS client may rely on the 958 output of some DDoS detection systems deployed within the DOTS client 959 domain to detect potential outbound DDoS attacks or on abuse claims 960 received from remote victim networks. Such DDoS detection and 961 mitigation techniques are not meant to track the activity of users, 962 but to protect the Internet and avoid altering the IP reputation of 963 the DOTS client domain. 965 7. Contributors 967 The following individuals have contributed to this document: 969 Joshi Harsha 970 McAfee, Inc. 971 Embassy Golf Link Business Park 972 Bangalore, Karnataka 560071 973 India 975 Email: harsha_joshi@mcafee.com 977 Wei Pan 978 Huawei Technologies 979 China 981 Email: william.panwei@huawei.com 983 8. Acknowledgements 985 Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Toema 986 Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments. 988 9. References 990 9.1. Normative References 992 [I-D.ietf-dots-signal-channel] 993 K, R., Boucadair, M., Patil, P., Mortensen, A., and N. 994 Teague, "Distributed Denial-of-Service Open Threat 995 Signaling (DOTS) Signal Channel Specification", draft- 996 ietf-dots-signal-channel-34 (work in progress), May 2019. 998 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 999 Requirement Levels", BCP 14, RFC 2119, 1000 DOI 10.17487/RFC2119, March 1997, 1001 . 1003 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1004 DOI 10.17487/RFC3688, January 2004, 1005 . 1007 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1008 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1009 January 2012, . 1011 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1012 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1013 . 1015 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1016 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1017 . 1019 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1020 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1021 May 2017, . 1023 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1024 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1025 . 1027 9.2. Informative References 1029 [I-D.ietf-dots-multihoming] 1030 Boucadair, M. and R. K, "Multi-homing Deployment 1031 Considerations for Distributed-Denial-of-Service Open 1032 Threat Signaling (DOTS)", draft-ietf-dots-multihoming-01 1033 (work in progress), January 2019. 1035 [I-D.ietf-dots-server-discovery] 1036 Boucadair, M. and R. K, "Distributed-Denial-of-Service 1037 Open Threat Signaling (DOTS) Server Discovery", draft- 1038 ietf-dots-server-discovery-04 (work in progress), June 1039 2019. 1041 [I-D.ietf-dots-use-cases] 1042 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 1043 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 1044 Open Threat Signaling", draft-ietf-dots-use-cases-17 (work 1045 in progress), January 2019. 1047 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1048 Congestion Control Protocol (DCCP)", RFC 4340, 1049 DOI 10.17487/RFC4340, March 2006, 1050 . 1052 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1053 (CIDR): The Internet Address Assignment and Aggregation 1054 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1055 2006, . 1057 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet 1058 Denial-of-Service Considerations", RFC 4732, 1059 DOI 10.17487/RFC4732, December 2006, 1060 . 1062 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1063 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1064 . 1066 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1067 and D. McPherson, "Dissemination of Flow Specification 1068 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1069 . 1071 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1072 Morris, J., Hansen, M., and R. Smith, "Privacy 1073 Considerations for Internet Protocols", RFC 6973, 1074 DOI 10.17487/RFC6973, July 2013, 1075 . 1077 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1078 Farrer, "Lightweight 4over6: An Extension to the Dual- 1079 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 1080 July 2015, . 1082 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 1083 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 1084 Port with Encapsulation (MAP-E)", RFC 7597, 1085 DOI 10.17487/RFC7597, July 2015, 1086 . 1088 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1089 RFC 8071, DOI 10.17487/RFC8071, February 2017, 1090 . 1092 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1093 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1094 . 1096 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1097 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1098 Address Translation (NAT) and Network Prefix Translation 1099 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1100 . 1102 [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG 1103 Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, 1104 DOI 10.17487/RFC8513, January 2019, 1105 . 1107 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 1108 Jacquenet, "An Inventory of Transport-Centric Functions 1109 Provided by Middleboxes: An Operator Perspective", 1110 RFC 8517, DOI 10.17487/RFC8517, February 2019, 1111 . 1113 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 1114 Things (IoT) Security: State of the Art and Challenges", 1115 RFC 8576, DOI 10.17487/RFC8576, April 2019, 1116 . 1118 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 1119 Threat Signaling (DOTS) Requirements", RFC 8612, 1120 DOI 10.17487/RFC8612, May 2019, 1121 . 1123 Appendix A. Disambiguate Base DOTS Signal vs. Call Home 1125 With the call home extension, there is a chance that two DOTS agents 1126 can simultaneously establish two DOTS signal channels with different 1127 directions (base DOTS signal channel and DOTS signal channel call 1128 home). Here is one example drawn from the home network. 1129 Nevertheless, the outcome of the discussion is not specific to these 1130 networks, but applies to any DOTS call home scenario. 1132 In the call home scenario, the DOTS server in the home network can 1133 mitigate the DDoS attacks launched by the compromised device in its 1134 domain by receiving the mitigation request sent by the DOTS client in 1135 the ISP environment. In addition, the DOTS client in the home 1136 network can initiate a mitigation request to the DOTS server in the 1137 ISP environment to ask for help when the home network is under a DDoS 1138 attack. Such DOTS server and DOTS client in the home network can co- 1139 locate in the same home network element (e.g., the Customer Premises 1140 Equipment). In this case, with the same peer at the same time the 1141 home network element will have the basic DOTS signal channel defined 1142 in [I-D.ietf-dots-signal-channel] and the call home DOTS signal 1143 channel defined in this specification. Thus these two signal 1144 channels need to be distinguished when they are both supported. 1146 In the call home scenario, the DOTS server in, for example, the home 1147 network can mitigate the DDoS attacks launched by the compromised 1148 device in its domain by receiving the mitigation request sent by the 1149 DOTS client in the ISP environment. In addition, the DOTS client in 1150 the home network can initiate a mitigation request to the DOTS server 1151 in the ISP environment to ask for help when the home network is under 1152 a DDoS attack. Such DOTS server and DOTS client in the home network 1153 can co-locate in the same home network element (e.g., the Customer 1154 Premises Equipment). In this case, with the same peer at the same 1155 time the home network element will have the basic DOTS signal channel 1156 defined in [I-D.ietf-dots-signal-channel] and the call home DOTS 1157 signal channel defined in this specification. Thus these two signal 1158 channels need to be distinguished when they are both supported. Two 1159 approaches have been considered for distinguishing the two DOTS 1160 signal channels, but only the one that using the dedicated port 1161 number has been chosen as the best choice. 1163 By using a dedicated port number for each, these two signal channels 1164 can be separated unambiguously and easily. For example, the CPE uses 1165 the port number 4646 defined in [I-D.ietf-dots-signal-channel] to 1166 initiate the basic signal channel to the ISP when it acts as the DOTS 1167 client, and uses the port number TBD to initiate the call home signal 1168 channel. Based on the different ports, the ISP can directly decide 1169 which kind of procedures should follow immediately after it receives 1170 the DOTS messages. This approach just requires two (D)TLS sessions 1171 to be established respectively for the basic signal channel and call 1172 home signal channel. 1174 The other approach is signaling the role of each DOTS agent (e.g., by 1175 using the DOTS data channel). For example, the DOTS agent in the 1176 home network first initiates a DOTS data channel to the peer DOTS 1177 agent in the ISP environment, at this time the DOTS agent in the home 1178 network is the DOTS client and the peer DOTS agent in the ISP 1179 environment is the DOTS server. After that, the DOTS agent in the 1180 home network retrieves the DOTS call home capability of the peer DOTS 1181 agent. If the peer supports the call home extension, the DOTS agent 1182 needs to subscribe to the peer to use this extension. Then the 1183 reversal of DOTS role can be recognized as done by both DOTS agents. 1184 When the DOTS agent in the ISP environment, which now is the DOTS 1185 client, wants to filter the attackers' traffic, it requests the DOTS 1186 agent in the home network, which now is the DOTS server, for help. 1188 Signaling the role will complicate the DOTS protocol, and this 1189 complexity is not required in context where call home extension is 1190 not required or only when call home extension is needed. Besides, 1191 the DOTS data channel may not work during attack time. Even if 1192 changing the above example from using the DOTS data channel to the 1193 DOTS signal channel, the more procedures will still reduce the 1194 efficiency. Using the dedicated port number is much easier and more 1195 concise compared to the second approach, and its cost that 1196 establishing two (D)TLS sessions is much less. So, using a dedicated 1197 port number for the call home extension is chosen in this 1198 specification. 1200 Authors' Addresses 1202 Tirumaleswar Reddy 1203 McAfee, Inc. 1204 Embassy Golf Link Business Park 1205 Bangalore, Karnataka 560071 1206 India 1208 Email: kondtir@gmail.com 1210 Mohamed Boucadair 1211 Orange 1212 Rennes 35000 1213 France 1215 Email: mohamed.boucadair@orange.com 1217 Jon Shallow 1218 UK 1220 Email: supjps-ietf@jpshallow.com