RFC 9066

Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home

📅 published December 2021, from ietf

Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home 🎀

  • RFC number: 9066 📜
  • Publisher: Internet Engineering Task Force (IETF)
  • Category: Standards Track ⭐
  • ISSN: 2070-1721
  • Date: December 2021 🗓️
  • Authors: T. Reddy.K (Akamai), M. Boucadair, Ed. (Orange), J. Shallow (no affiliation listed)
  • Obsoletes / Updates: none listed in this title block 🧚

Abstract 💖

okay bestie, this doc specs the DOTS signal channel Call Home 🦋 It lets a Call Home DOTS server start a secure connection to a Call Home DOTS client, and then receive attack traffic info from that client. The server uses that info to spot compromised devices that are launching outgoing DDoS attacks, and then takes appropriate mitigation action(s). Iconic behavior, ngl 💅

The DOTS signal channel Call Home isn't just for home networks. 🏠 It's for any deployment where you need to block DDoS attack traffic closer to the source(s) of the attack. Main character energy for sure ✨

Status of This Memo 📜

This is an Internet Standards Track document. 🌈

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 🎀

Info about the current status of this document, any errata, and how to send feedback on it can be found at https://www.rfc-editor.org/info/rfc9066 🔗

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date this document was published. Please read these carefully, because they explain your rights and restrictions with respect to this document. Code Components extracted from this document have to include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Revised BSD License. Don't skip this part, it's serious 🙈

Table of Contents 🧚

   1.  Introduction
   2.  Terminology
   3.  Applicability Scope
   4.  Coexistence of a Base DOTS Signal Channel and DOTS Call Home
   5.  DOTS Signal Channel Call Home
     5.1.  Procedure
     5.2.  DOTS Signal Channel Variations
       5.2.1.  Heartbeat Mechanism
       5.2.2.  Redirected Signaling
     5.3.  DOTS Signal Channel Extension
       5.3.1.  Mitigation Request
       5.3.2.  Address Sharing Considerations
   6.  DOTS Signal Call Home YANG Module
     6.1.  Tree Structure
     6.2.  YANG/JSON Mapping Parameters to CBOR
     6.3.  YANG Module
   7.  IANA Considerations
     7.1.  DOTS Signal Channel CBOR Mappings Registry
     7.2.  New DOTS Conflict Cause
     7.3.  DOTS Signal Call Home YANG Module
   8.  Security Considerations
   9.  Privacy Considerations
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Appendix A.  Some Home Network Issues
   Appendix B.  Disambiguating Base DOTS Signal vs. DOTS Call Home
   Acknowledgements
   Contributors
   Authors' Addresses

1. Introduction ✨

Okay so, the DOTS signal channel protocol [RFC9132] carries info about a network resource, or a network (or part of one), that's under a Distributed Denial-of-Service (DDoS) attack [RFC4732]. A DOTS client sends that info to one or more DOTS servers, so the right mitigation actions get applied to traffic that looks suspicious 👀 More use cases are covered in [RFC8903] if you want to go deeper 🧚

But here's the tea ☕ [RFC9132] only covers how to mitigate when you're the one being attacked. That means protecting a network from inbound DDoS attacks. It does not cover how to shut down attacks close to their source(s), where the traffic is misusing network resources (outbound DDoS attacks). In particular, the DOTS signal protocol doesn't discuss cooperative DDoS mitigation between the network hosting an attack source and the Internet Service Provider (ISP). That cooperation is what would suppress outbound DDoS attack traffic coming from that network. Quick reminder of the base basic DOTS architecture (yes, it says "base basic," lol) in Figure 1 (Section 2 of [RFC8811]) 💅

                 +-----------+            +-------------+
                 | Mitigator | ~~~~~~~~~~ | DOTS Server |
                 +-----------+            +-------------+
                                                 |
                                                 |
                                                 |
                 +---------------+        +-------------+
                 | Attack Target | ~~~~~~ | DOTS Client |
                 +---------------+        +-------------+

                     Figure 1: Basic DOTS Architecture

Appendix A explains why the rise of Internet of Things (IoT) devices makes it so much easier for them to be used as malicious actors that need to be controlled. 🧸 Similar issues show up in enterprise networks, data centers, etc. The ISP offering a DDoS mitigation service can detect outgoing DDoS attack traffic coming from its subscribers. Or the ISP might get filtering rules (for example, using BGP Flowspec [RFC8955] [RFC8956]) from a transit provider. Those rules let it filter, block, or rate-limit DDoS attack traffic that comes from the ISP's subscribers and is headed to a downstream target. Still, the DOTS signal channel doesn't give the ISP a way to ask for those attacks to be blocked close to their sources without also messing with legitimate traffic. This document fills that gap by specifying an extension to the DOTS signal channel: DOTS signal channel Call Home 🦋

Note: Another design approach would be to extend the DOTS signal channel with a new attribute that explicitly says whether a mitigation request concerns an outbound DDoS attack. In that approach, a DOTS server is deployed within the domain hosting the attack source(s), while a DOTS client is enabled within an upstream network (for example, an access network). But starting a DOTS signal channel from an upstream network toward a source network gets complicated because of translators and firewalls. Also, using the same signal channel for both inbound and outbound attacks makes both the heartbeat and redirection mechanisms more complicated. Those mechanisms run differently depending on the attack direction (see Sections 5.2.1 and 5.2.2). And the DOTS server would be exposed to fingerprinting (for example, with scanning tools) and DoS attacks (for example, by making the DOTS server perform computationally expensive operations). The various management and deployment considerations that motivate the Call Home functionality are listed in Section 1.1 of [RFC8071]. 🙈

"DOTS signal channel Call Home" (or "DOTS Call Home" for short) means a DOTS signal channel that's set up on the DOTS server's initiative, thanks to a role reversal at the (D)TLS layer (Section 5.1). In other words, the DOTS server starts a secure connection to a DOTS client and uses that connection to receive the attack traffic info (for example, attack sources) from the DOTS client 🔐

A high-level DOTS Call Home functional architecture is shown in Figure 2. The attack source(s) are inside the DOTS server domain 🏡

                                             Scope
                                   +.-.-.-.-.-.-.-.-.-.-.-.+
              +---------------+    :    +-------------+    :
              |    Alert      | ~~~:~~~ |  Call Home  |    :
              |               |    :    | DOTS client |    :
              +---------------+    :    +------+------+    :
                                   :           |           :
                                   :           |           :
                                   :           |           :
              +---------------+    :    +------+------+    :
              |    Attack     | ~~~:~~~ |  Call Home  |    :
              |   Source(s)   |    :    | DOTS server |    :
              +---------------+    :    +-------------+    :
                                   +.-.-.-.-.-.-.-.-.-.-.-.+

   Figure 2: Basic DOTS Signal Channel Call Home Functional Architecture

Otherwise, DOTS agents involved in DOTS Call Home follow the DOTS roles defined in [RFC8612]. For clarity, this document uses "Call Home DOTS client" (or "Call Home DOTS server") to mean a DOTS client (or DOTS server) deployed in a Call Home scenario (Figure 2). Call Home DOTS agents may (or may not) be co-located with DOTS agents that comply with [RFC9132] (see Section 4 for more details) 🌸

A Call Home DOTS client relies on a bunch of triggers to use the Call Home function. Examples include scrubbing traffic from the attack source, or receiving an alert from an attack target, a peer DDoS Mitigation System (DMS), or a transit provider. How these triggers work is deployment specific. So it's out of scope for this document to explain how those triggers get made available to a Call Home DOTS client 🤷‍♀️

In a typical deployment, the Call Home DOTS server is enabled on a Customer Premises Equipment (CPE). That fits recent trends of loading the CPE up with advanced security features 🔒 For example, the DOTS Call Home service can be part of the services supported by an ISP-managed CPE, or part of a managed security service the user subscribes to. Unlike classic DOTS deployments [RFC8903], a Call Home DOTS server maintains a single DOTS signal channel session for each DOTS-capable upstream provisioning domain [DOTS-MULTIHOMING] 🍓

For instance, the Call Home DOTS server in the home network starts the signal channel Call Home while it's in "idle" time. Later, the Call Home DOTS client in the ISP environment can send a mitigation request whenever the ISP detects an attack from a compromised device in the DOTS server domain (that is, from inside the home network) 👑

The Call Home DOTS server uses the DDoS attack traffic info to find the compromised device in its domain that's responsible for launching the DDoS attack. It can optionally notify a network administrator, and it takes appropriate mitigation action(s). For example, one mitigation action is to quarantine the compromised device, or to block its traffic to the attack target(s) until the mitigation request is withdrawn 🚫

This document assumes that Call Home DOTS servers are provisioned with a way to know how to reach the upstream Call Home DOTS client(s). That could happen through a variety of means (for example, [RFC8973]). Specifying those means is out of scope for this document 🧭

For more info about the applicability scope of the DOTS signal channel Call Home, see Section 3 🦋

2. Terminology ✨

okay so first things first, bestie 💅 the BCP 14 key words in this doc are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". they only count as BCP 14 key words when they show up in ALL CAPS like that, and then they're read as described in BCP 14 [RFC2119] [RFC8174] 🎀 lowercase ones are just regular English, no special meaning 🙈

the reader should be familiar with the terms defined in Section 1.2 of [RFC8612] 🌸 so go read that first, it's giving prerequisite energy

"DDoS Mitigation System (DMS)" just means a system that does DDoS mitigation 🛡️ simple, iconic

"Base DOTS signal channel" refers to [RFC9132] 🦋

the meaning of the symbols in YANG tree diagrams is defined in [RFC8340] and [RFC8791] 🌈

(D)TLS is the shorthand for statements that apply to both Transport Layer Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS) [RFC6347] [DTLS13] 💜 if a statement is only about one of them, it uses the specific name instead ✨

3. Applicability Scope 🧚

okay the problems we talked about in Section 1 may show up in lots of deployments 🏠🏢🌐🏭 like home networks, enterprise networks, transit networks, and data centers 💖 the solution in this doc can be used in those places to block DDoS attack traffic closer to where the attack starts 🔥 so an attack launched from inside an enterprise network or a data center gets blocked before it ever leaves that network 👑

here's what a Call Home setup looks like 👀 (Figure 3!!)

                             +-------------+
                             |Attack Target|
                             +-----+-------+
                                   | /\      Target Network
             ......................|.||....................
                          .--------+-||-------.
                         (           ||        )-.
                       .'            ||           '
                       (  Internet   ||            )
                        (            ||          -'
                         '-(         ||          )
                            '------+-||---------'
             ......................|.||.....................
                          .--------+-||-------.      Network
                         (           ||        )-.  Provider
                       .' Call Home  ||           '   (DMS)
                       ( DOTS client ||            )
                        (            ||          -'
                         '-(         ||          )
                            '------+-||---------'
             ......................|.||.......................
                          .--------+-||-------. Source Network
                         (           ||        )-.
                       .' Call Home  ||           '
                       ( DOTS server || Outbound   )
                        (            ||   DDoS   -'
                         '-(         ||  Attack  )
                            '------+-||---------'
                                   | ||
                             +-----+-++----+
                             |Attack Source|
                             +-------------+

       Figure 3: DOTS Signal Channel Call Home Reference Architecture

it is out of the scope of this doc to list every single deployment 🙃 that's not the point, it's just a sampler platter 🍓

Call Home DOTS agent relationships are pretty similar to the ones in Section 2.3 of [RFC8811] 🫶 for example, multiple Call Home DOTS servers from the same domain can be tied to the same Call Home DOTS client 🌸 and a Call Home DOTS client has options: it can contact those servers one after another, fork a mitigation request to all of them at once, or pick one Call Home DOTS server to send the mitigation request to ✨ which one it picks is implementation specific, so that's up to the implementer 💅

some mitigations might need an administrator to say yes first before a filtering action happens 🔐 how you ask for that consent is deployment specific 🦋 there's a whole bunch of ways to do it, like push notifications through a dedicated app, Syslog, etc. 🌈 this doc is not going to recommend how those interactions get built (see Figure 2) 💜

the Call Home DOTS server can run on a border router or on a dedicated appliance 🖥️ for home networks, it can be enabled on a managed CPE, or bundled with a CPE management app that an ISP gives its subscribers 🏠 these managed services are likely built to hide the messy complexity of managing (including configuring) the CPE 🧼 for example, managed CPEs can notify the user when a new device shows up and ask whether that device should get access 📲 those notification features can be upgraded to talk to the Call Home DOTS server 🚀 and users can customize the notifications (e.g., triggers, type) and the default actions 🎀 bestie, control is everything 👑

4. Coexistence of a Base DOTS Signal Channel and DOTS Call Home ✨

okay so bestie, the DOTS signal channel Call Home does not require the base DOTS signal channel to be turned on, but it also doesn't preclude it 💅 (the base one is [RFC9132]). this section walks through a few sample deployment schemes, just for illustration 🦋

The network that hosts an attack source may also be subject to inbound DDoS attacks 😭. In that case, both the base DOTS signal channel and DOTS signal channel Call Home may be enabled, as shown in Figure 4 (same DMS provider) or Figure 5 (distinct DMS providers) 🌸.

               DOTS Signal Channel      Base DOTS
                   Call Home          Signal Channel
              +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
              :          +------+ :: +------+          :
              :          | DOTS | :: | DOTS |          :
              :          |client| :: |server|          :
              :          +--+---+ :: +---+--+          :
              :     /\      |     ::     |             : Network
              :     ||      |     ::     |             :Provider
              :     ||      |     ::     |             :  (DMS)
           ...:.....||......|.....::.....|.............:........
           Outbound ||      |     ::     |       || Inbound
             DDoS   ||      |     ::     |       ||   DDoS
            Attack  ||      |     ::     |       \/  Attack
              :          +--+---+ :: +---+--+          :
              :          | DOTS | :: | DOTS |          :
              :          |server| :: |client|          :
              :          +------+ :: +------+          :
              +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
                              Network #A

      Figure 4: Activation of a Base DOTS Signal Channel and Call Home
                            (Same DMS Provider)

Note that a DMS provider may not be on the default forwarding path of inbound DDoS attack traffic targeting a network (e.g., Network #B in Figure 5) 🙈. Nevertheless, the DOTS signal channel Call Home requires the DMS provider to be on the default forwarding path of the outbound traffic from a given network 👑.

               DOTS Signal Channel      Base DOTS
                   Call Home          Signal Channel
              +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
              : Network  +------+ :: +------+   Third  :
              : Provider | DOTS | :: | DOTS |   Party  :
              :  (DMS)   |client| :: |server|    DMS   :
              :          +--+---+ :: +---+--+ Provider :
              :     /\      |     ::     |             :
              :     ||      |     ::     |             :
              :     ||      |     ::     |             :
           ...:.....||......|.....::.....|.............:........
           Outbound ||      |     ::     |       || Inbound
             DDoS   ||      |     ::     |       ||   DDoS
            Attack  ||      |     ::     |       \/  Attack
              :          +--+---+ :: +---+--+          :
              :          | DOTS | :: | DOTS |          :
              :          |server| :: |client|          :
              :          +------+ :: +------+          :
              +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
                              Network #B

      Figure 5: Activation of a Base DOTS Signal Channel and Call Home
                          (Distinct DMS Providers)

Figures 6 and 7 depict examples where the same node embeds both base DOTS and Call Home DOTS agents 🧚. For example, a DOTS server and a Call Home DOTS client may be enabled on the same device within the infrastructure of a DMS provider (e.g., Node #i in Figure 6), or a DOTS client and a Call Home DOTS server may be enabled on the same device within a source network (e.g., Node #j with Network #D shown in Figure 7) 💜.

               DOTS Signal Channel      Base DOTS
                   Call Home          Signal Channel
              +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
              :        +----------------------+        :
              :        |       Node #i        |        :
              :        | +------+    +------+ |        :
              :        | | DOTS |    | DOTS | |        :
              :        | |client|    |server| |        :
              :        | +--+---+    +---+--+ |        :
              :        +----|-----::-----|----+        : Network
              :     /\      |     ::     |             :Provider
              :     ||      |     ::     |             :  (DMS)
           ...:.....||......|.....::.....|.............:........
           Outbound ||      |     ::     |       || Inbound
             DDoS   ||      |     ::     |       ||   DDoS
            Attack  ||      |     ::     |       \/  Attack
              :          +--+---+ :: +---+--+          :
              :          | DOTS | :: | DOTS |          :
              :          |server| :: |client|          :
              :          +------+ :: +------+          :
              +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
                              Network #C

      Figure 6: The Same Node Embedding a Call Home DOTS Client and a
                 DOTS Server at the Network Provider's Side
               DOTS Signal Channel      Base DOTS
                   Call Home          Signal Channel
              +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
              :        +----------------------+        :
              :        |       Node #k        |        :
              :        | +------+    +------+ |        :
              :        | | DOTS |    | DOTS | |        :
              :        | |client|    |server| |        :
              :        | +--+---+    +---+--+ |        :
              :        +----|-----::-----|----+        : Network
              :     /\      |     ::     |             :Provider
              :     ||      |     ::     |             :  (DMS)
           ...:.....||......|.....::.....|.............:........
           Outbound ||      |     ::     |       || Inbound
             DDoS   ||      |     ::     |       ||   DDoS
            Attack  ||      |     ::     |       \/  Attack
              :        +----|-----::-----|----+        :
              :        | +--+---+    +---+--+ |        :
              :        | | DOTS |    | DOTS | |        :
              :        | |server|    |client| |        :
              :        | +------+    +------+ |        :
              :        |       Node #j        |        :
              :        +----------------------+        :
              +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
                              Network #D

      Figure 7: The Same Node Embedding both a DOTS Client and a Call
                              Home DOTS Server

Whether the same or distinct nodes are used to host base DOTS and Call Home DOTS agents is specific to each domain 🌈. Appendix B elaborates on the considerations to unambiguously distinguish DOTS messages that belong to each of these channels 🔥.

5. DOTS Signal Channel Call Home 🎀

5.1. Procedure

The DOTS signal channel Call Home preserves all but one of the DOTS client/server roles in the DOTS protocol stack, compared to the client-initiated DOTS signal channel protocol [RFC9132] 🦋. The role reversal happens at the (D)TLS layer, meaning (1) the Call Home DOTS server acts as a DTLS client, and the Call Home DOTS client acts as a DTLS server; or (2) the Call Home DOTS server acts as a TLS client initiating the underlying TCP connection, and the Call Home DOTS client acts as a TLS server 😭. The Call Home DOTS server initiates a (D)TLS handshake to the Call Home DOTS client ✨.

For example, a home network element (e.g., home router) co-located with a Call Home DOTS server is the (D)TLS client 🏠. So the Call Home DOTS server takes on the (D)TLS client role, but the network element's role as a DOTS server stays the same 💅.

Existing certificate chains and mutual authentication mechanisms between the DOTS agents are unaffected by the Call Home function 🫶. From a deployment standpoint, and given the scale of Call Home DOTS servers that may be involved, enabling means for automating the provisioning of credentials on Call Home DOTS servers to authenticate to the Call Home DOTS client is encouraged 🍓. It is out of the scope of this document to elaborate on these means 🙈.

Figure 8 illustrates a sample DOTS Call Home flow exchange:

          +-----------+                        +-----------+
          | Call Home |                        | Call Home |
          |    DOTS   |                        |    DOTS   |
          |   server  |                        |   client  |
          +-----+-----+                        +-----+-----+
          (D)TLS client                        (D)TLS server
                |                                    |
                |         1. (D)TLS connection       |
                |----------------------------------->|
                |         2. Mitigation request      |
                |<-----------------------------------|
                |              ...                   |

      Figure 8: DOTS Signal Channel Call Home Sequence Diagram

The DOTS signal channel Call Home procedure is as follows:

  1. If UDP transport is used, the Call Home DOTS server begins by initiating a DTLS connection to the Call Home DOTS client.

If TCP is used, the Call Home DOTS server begins by initiating a TCP connection to the Call Home DOTS client. Once connected, the Call Home DOTS server continues to initiate a TLS connection to the Call Home DOTS client 🌸.

Peer DOTS agents may have mutual agreement to use a specific port number, such as by explicit configuration or dynamic discovery [RFC8973] 🧚. The interaction between the base DOTS signal channel and the Call Home is discussed in Appendix B 💜.

The Happy Eyeballs mechanism explained in Section 4.3 of [RFC9132] is used for initiating (D)TLS connections 🌈.

  1. Using this (D)TLS connection, the Call Home DOTS client may request, withdraw, or retrieve the status of mitigation requests 👑. The Call Home DOTS client supplies the source information by means of new attributes defined in Section 5.3.1 🔥.

The heartbeat mechanism used for the DOTS Call Home deviates from the one defined in Section 4.7 of [RFC9132] 💀. Section 5.2.1 specifies the behavior to be followed by Call Home DOTS agents 🫶.

5.2. DOTS Signal Channel Variations

5.2.1. Heartbeat Mechanism 💓

Once the (D)TLS session is established between the DOTS agents, the Call Home DOTS client reaches out to the Call Home DOTS server to grab the session configuration parameters (Section 4.5 of [RFC9132]) 📋. The Call Home DOTS server tweaks the heartbeat-interval so it fits the binding timers used by on-path NATs and firewalls 🛡️. After that, the DOTS agents exchange heartbeats following the instructions they got from the signal channel session configuration exchange. Bestie, it's giving well-organized 💅

It's the Call Home DOTS server's job to make sure on-path translators and firewalls keep a binding, so the same external IP address and/or port number sticks around for the DOTS signal channel session 🔐. A Call Home DOTS client MAY trigger its heartbeat requests right after it gets heartbeat probes from its peer Call Home DOTS server ✨.

When a Call Home DOTS client detects and reports an outgoing attack that saturates the outgoing link from the Call Home DOTS server 🚨, that client MUST keep using the DOTS signal channel, even if no traffic is coming back from the Call Home DOTS server. Not me being dramatic, but this is a must-do 😭

If the Call Home DOTS server is getting traffic from the Call Home DOTS client, the server MUST keep using the DOTS signal channel even if the allowed missing heartbeats threshold (missing-hb-allowed) has been hit 🫶. Traffic is the vibe check that matters here.

Now the sad part 🥀. If the Call Home DOTS server gets zero traffic from the peer Call Home DOTS client for the whole time it takes to use up the maximum missing-hb-allowed threshold, the server decides the session is disconnected 📴. At that point the Call Home DOTS server MUST try to set up a brand-new DOTS signal channel session, preferably by resuming the (D)TLS session 🔄. Resumption is the glow-up we want 🌸.

5.2.2. Redirected Signaling 🦋

A Call Home DOTS server MUST NOT support the redirected signaling mechanism from Section 4.6 of [RFC9132] 🚫. That's the one where a 5.03 response carries an alternate DOTS server's Fully Qualified Domain Name (FQDN) or IP address(es). A Call Home DOTS client MUST silently discard that kind of message, because only a Call Home DOTS server is allowed to start a new (D)TLS connection 🙅‍♀️. Know your lane, bestie.

Now, if a Call Home DOTS client wants to redirect a Call Home DOTS server over to another Call Home DOTS client, it MUST send a Non-confirmable PUT request to the predefined resource .well-known/dots/redirect 🎀. The body of that PUT request carries these attributes:

  • alt-ch-client: The FQDN of an alternate Call Home DOTS client. It also doubles as a reference identifier for authentication purposes 🪪.
    • This one is mandatory for DOTS signal Call Home. It MUST NOT be used for base DOTS signal channel operations 🙅‍♀️.
  • alt-ch-client-record: A list of IP addresses for the alternate Call Home DOTS client. If you don't include an alt-ch-client-record, the Call Home DOTS server passes the alt-ch-client name to a name resolution library to look up one or more IP addresses for that alternate client 🔍.
    • This one is optional for DOTS signal Call Home. It MUST NOT be used for base DOTS signal channel operations 🙅‍♀️.
  • ttl: The Time To Live (TTL) of the alternate Call Home DOTS client. In other words, it's the time interval during which a Call Home DOTS server may cache that alternate client ⏳.
    • This one is optional for DOTS signal Call Home. It MUST NOT be used for base DOTS signal channel operations 🙅‍♀️.

When the Call Home DOTS server gets this PUT request, it replies with a 2.01 (Created), closes this connection, and sets up a connection with the new Call Home DOTS client 🤝. The TTL gets processed as described in Section 4.6 of [RFC9132] ⏱️. If the Call Home DOTS server can't service the PUT request, the response is a 4.00 (Bad Request) 💀.

Figure 9 shows a PUT request example that conveys the alternate Call Home DOTS client "alt-call-home-client.example" along with its IP addresses 2001:db8:6401::1 and 2001:db8:6401::2 🌈. This alternate client is valid for 10 minutes ⭐.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "redirect"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "mid=123"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-signal-channel:redirected-signal": {
       "ietf-dots-call-home:alt-ch-client":
                     "alt-call-home-client.example",
       "ietf-dots-call-home:alt-ch-client-record": [
          "2001:db8:6401::1",
          "2001:db8:6401::2"
        ],
       "ietf-dots-call-home:ttl": 600
   }

Figure 9: Example of a PUT Request for Redirected Signaling 🧚

Figure 9 uses the JSON encoding of YANG-modeled data for the CoAP message body 💜. The same encoding is used in Figure 10 (Section 5.3.1) 🍓.

5.3. DOTS Signal Channel Extension 🌟

5.3.1. Mitigation Request

Okay bestie, this part extends the mitigation request from Section 4.4.1 of [RFC9132] 🦋 so the DOTS client can spill the tea on where the attack is coming from, like source prefixes and source port numbers ✨. The DOTS client adds these new params to the Concise Binary Object Representation (CBOR) body of the mitigation request 💅

source-prefix: This is a list of attacker IP prefixes used to attack the target. The prefixes are written in Classless Inter-Domain Routing (CIDR) notation (BCP 122 [RFC4632]) 🎀

As a reminder, the prefix length MUST be less than or equal to 32 (or 128) for IPv4 (or IPv6) 💀

The prefix list MUST NOT include broadcast, loopback, or multicast addresses. Those are considered invalid values, so no sneaking them in 🙅‍♀️ Link-local addresses are allowed though. The Call Home DOTS client MUST validate that attacker prefixes are within the scope of the Call Home DOTS server domain (for example, prefixes assigned to the Call Home DOTS server domain or networks it services). This check is meant to avoid contacting Call Home DOTS servers that are not entitled to enforce actions on specific prefixes. It's giving responsible behavior 🫶

This is an optional attribute for the base DOTS signal channel operations 🌸

source-port-range: This is a list of port numbers used by the attack traffic flows 🧚

A port range is defined by two bounds, a lower port number ("lower-port") and an upper port number ("upper-port"). When only "lower-port" is present, it represents a single port number.

For TCP, UDP, Stream Control Transmission Protocol (SCTP) [RFC4960], or Datagram Congestion Control Protocol (DCCP) [RFC4340], a range of ports can be any subrange of 0-65535. For example, 0-1023, 1024-65535, or 1024-49151 are all valid, iconic choices 👑

This is an optional attribute for the base DOTS signal channel operations 🍓

source-icmp-type-range: This is a list of ICMP types used by the attack traffic flows. An ICMP type range is defined by two bounds, a lower ICMP type (lower-type) and an upper ICMP type (upper-type). When only "lower-type" is present, it represents a single ICMP type. Both ICMP [RFC0792] and ICMPv6 [RFC4443] types are supported. Whether ICMP or ICMPv6 types are used is determined by the address family of the "target-prefix" 🌈

This is an optional attribute for the base DOTS signal channel operations 💜

The "source-prefix" parameter is a mandatory attribute when the attack traffic information is signaled by a Call Home DOTS client (i.e., the Call Home scenario depicted in Figure 8). Main character energy, no notes 👑 The "target-prefix" attribute MUST be included in the mitigation request signaling the attack information to a Call Home DOTS server 🎯 The "target-uri" or "target-fqdn" parameters can be included in a mitigation request for diagnostic purposes, to notify the Call Home DOTS server domain administrator, but they SHOULD NOT be used to determine the target IP addresses 🙈 "alias-name" is unlikely to be conveyed in a Call Home mitigation request, given that a target may be any IP resource and that there is no incentive for a Call Home DOTS server (embedded, for example, in a CPE) to maintain aliases. Lowkey not a vibe 💅

In order to help attack source identification by a Call Home DOTS server, the Call Home DOTS client SHOULD include additional information in its mitigation request, such as "source-port-range" or "source-icmp-type-range", to disambiguate nodes sharing the same "source-prefix" 🔥 IPv6 addresses/prefixes are sufficient to uniquely identify a network endpoint, without needing port numbers or ICMP type information. While this is also possible for IPv4, it is much less often the case than for IPv6. More address sharing implications on the setting of source information ("source-prefix", "source-port-range") are discussed in Section 5.3.2 🧠

Only immediate mitigation requests (i.e., "trigger-mitigation" set to "true") are allowed. Call Home DOTS clients MUST NOT send requests with "trigger-mitigation" set to "false". Such requests MUST be discarded by the Call Home DOTS server with a 4.00 (Bad Request) 🚫

An example of a mitigation request sent by a Call Home DOTS client is shown in Figure 10 🦋

  Header: PUT (Code=0.03)
  Uri-Path: ".well-known"
  Uri-Path: "dots"
  Uri-Path: "mitigate"
  Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
  Uri-Path: "mid=56"
  Content-Format: "application/dots+cbor"

  {
    "ietf-dots-signal-channel:mitigation-scope": {
      "scope": [
        {
          "target-prefix": [
             "2001:db8:c000::/128"
           ],
          "ietf-dots-call-home:source-prefix": [
             "2001:db8:123::1/128"
           ],
          "lifetime": 3600
        }
      ]
    }
  }

    Figure 10: An Example of a Mitigation Request Issued by a Call
                           Home DOTS Client

The Call Home DOTS server MUST check that the "source-prefix" is within the scope of the Call Home DOTS server domain. Note that in a DOTS Call Home scenario, the Call Home DOTS server considers, by default, that any routable IP prefix enclosed in "target-prefix" is within the scope of the Call Home DOTS client. Invalid mitigation requests are handled as per Section 4.4.1 of [RFC9132] 🔍

Note: These validation checks do not apply when the source information is included as a hint in the context of the base DOTS signal channel.

Call Home DOTS server domain administrator consent MAY be required to block the traffic from the compromised device to the attack target. An implementation MAY have a configuration knob to block the traffic from the compromised device to the attack target with or without DOTS server domain administrator consent. Choices, choices 🎀

If consent from the Call Home DOTS server domain administrator is required, the Call Home DOTS server replies with 2.01 (Created) and the "status" code set to 1 (attack-mitigation-in-progress). Then, the mechanisms defined in Section 4.4.2 of [RFC9132] are followed by the DOTS agents to update the mitigation status. In particular, if the attack traffic is blocked, the Call Home DOTS server informs the Call Home DOTS client that the attack is being mitigated, by setting the "status" code to 2 (attack-successfully-mitigated) ✨

If the attack traffic information is identified by the Call Home DOTS server or the Call Home DOTS server domain administrator as legitimate traffic, the mitigation request is rejected with a 4.09 (Conflict) (for example, when no consent is required from an administrator), or with a notification message with the "conflict-clause" (Section 4.4.1 of [RFC9132]) set to the following new value 🙅‍♀️

4: Mitigation request rejected. This code is returned by the DOTS server to indicate the attack traffic has been classified as legitimate traffic 🥲

Once the request is validated by the Call Home DOTS server, appropriate actions are enforced to block the attack traffic within the source network. For example, if the Call Home DOTS server is embedded in a CPE, it can program the packet processor to punt all the traffic from the compromised device to the target to the slow path. The CPE inspects the punted slow path traffic to detect and block the outgoing DDoS attack traffic, or quarantines the device (for example, using MAC-level filtering) until it is remediated, and notifies the CPE administrator about the compromised device. Note that the Call Home DOTS client is informed about the progress of the attack mitigation following the rules in Section 4.4.2 of [RFC9132] 🧚

The DOTS agents follow the same procedures specified in [RFC9132] for managing a mitigation request 🫶

5.3.2. Address Sharing Considerations ✨

okay so bestie, picture this 🌸 a network provider hosts a Call Home DOTS client and drops a Carrier-Grade NAT (CGN) between the DOTS client domain and the DOTS server domain. Figure 11 shows the whole setup. In that situation, if the Call Home DOTS client puts an external IP address in a mitigation request, the Call Home DOTS server will probably throw it out 💀, because that external IP is not visible locally to the server. The server only knows the internal IP addresses/prefixes bound to its own domain (the ones in the internal realm in Figure 11).

So, Call Home DOTS clients that know there's an on-path CGN MUST NOT include the external IP address and/or port number identifying the suspect attack source (the ones from the external realm in Figure 11), but they MUST include the internal IP address and/or port number instead. 🫶 To get there, the Call Home DOTS client SHOULD rely on mechanisms like the ones described in [RFC8512] or [RFC8513] to look up the internal IP address and port number mapped to an external IP address and port number. And for the particular case of NAT64 [RFC6146], if the target address is an IPv4 address, the IPv4-converted IPv6 address of this target address [RFC6052] SHOULD be used. 🦋

              N |        .-------------------.
              E |       (                     )-.
              T |     .'                         '
              W |     (        Call Home          )
              O |      (      DOTS client       -'
              R |       '-(                     )
              K |          '-------+-----------'
                |                  |
              P |                  |
              R |              +---+---+
              O |              |  CGN  |        External Realm
              V |..............|       |......................
              I |              |       |        Internal Realm
              D |              +---+---+
              E |                  |
              R |                  |
               ---                 |
                         .---------+---------.
                        (                     )-.
                      .'     Source Network      '
                      (                           )
                       (        Call Home        -'
                        '-(    DOTS server      )
                           '------+------------'
                                  |
                            +-----+-------+
                            |Attack Source|
                            +-------------+

              Figure 11: Example of a CGN between DOTS Domains

If a Mapping of Address and Port (MAP) Border Relay [RFC7597] or a Lightweight Address Family Transition Router (lwAFTR) [RFC7596] is enabled in the provider's domain to service its customers, then identifying an attack source bound to an IPv4 address/prefix MUST also rely on source port numbers 🎀, because the same IPv4 address is assigned to multiple customers. The port information is REQUIRED to unambiguously identify the source of an attack. Literally the only way to pinpoint the right person 😭

If a translator is enabled on the boundaries of the domain hosting the Call Home DOTS server (for example, a CPE with NAT enabled as shown in Figures 12 and 13), the Call Home DOTS server uses the attack traffic information conveyed in a mitigation request to find the internal source IP address of the compromised device. It then blocks traffic from the compromised device to the attack target until the mitigation request is withdrawn. The Call Home DOTS server does a NAT mapping table lookup using the attack information (or a subset of it) as a key. That lookup can happen locally (Figure 12) or through a dedicated administration interface offered by the CPE (Figure 13). This way the suspicious device gets isolated without disturbing other services 🧚

                            .-------------------.
                           (                     )-.
                         .'   Network Provider (DMS)'
                         (                           )
                          (        Call Home       -'
                           '-(    DOTS client      )
                              '-------+-----------'
                                      |
                  ---             +---+---+
                 S |              |  CPE  |  External Realm
                 O |..............|       |................
                 U |              |  NAT  |  Internal Realm
                 R |              +---+---+
                 C |                  |
                 E |        .---------+---------.
                   |       (                     )-.
                 N |     .'                         '
                 E |     (          Call Home        )
                 T |      (        DOTS server     -'
                 W |       '-(                     )
                 O |          '-------+-----------'
                 R |                  |
                 K |           +------+------+
                   |           |Attack Source|
                               +-------------+

     Figure 12: Example of a DOTS Server Domain with a NAT Embedded in
                                   a CPE
                          .-------------------.
                         (                     )-.
                       .'  Network Provider (DMS) '
                       (                           )
                        (        Call Home       -'
                         '-(    DOTS client      )
                            '---------+---------'
                                      |
                ---             +-----+-----+
               S |              |  CPE/NAT  |  External Realm
               O |..............|           |................
               U |              | Call Home |  Internal Realm
               R |              |DOTS server|
               C |              +-----+-----+
               E |                    |
                 |        .-----------+-------.
                 |       (                     )-.
               N |     .'                         '
               E |     (     Local Area Network    )
               T |      (                        -'
               W |       '-(                     )
               O |          '--------+----------'
               R |                   |
               K |            +------+------+
                 |            |Attack Source|
                              +-------------+

      Figure 13: Example of a Call Home DOTS Server and a NAT Embedded
                                  in a CPE

If, for any reason, address sharing is deployed in both the source and provider networks, both Call Home DOTS agents have to do address mapping lookups, following the behavior described for Figure 11 (network provider) and Figures 12 and 13 (source network). 💜

6. DOTS Signal Call Home YANG Module 🌈

6.1. Tree Structure

This document augments the "ietf-dots-signal-channel" (dots-signal) DOTS signal YANG module defined in [RFC9132] so it can signal the attack traffic information. It defines the YANG module "ietf-dots-call-home", which has the following tree structure 👑

module: ietf-dots-call-home

  augment-structure /dots-signal:dots-signal/dots-signal:message-type
                    /dots-signal:mitigation-scope/dots-signal:scope:
    +-- source-prefix*            inet:ip-prefix
    +-- source-port-range* [lower-port]
    |  +-- lower-port    inet:port-number
    |  +-- upper-port?   inet:port-number
    +-- source-icmp-type-range* [lower-type]
       +-- lower-type    uint8
       +-- upper-type?   uint8
  augment-structure /dots-signal:dots-signal/dots-signal:message-type
                    /dots-signal:redirected-signal:
    +-- (type)?
       +--:(call-home-only)
          +-- alt-ch-client           inet:domain-name
          +-- alt-ch-client-record*   inet:ip-address
          +-- ttl?                    uint32

6.2. YANG/JSON Mapping Parameters to CBOR 🍓

The YANG/JSON mapping parameters to CBOR are listed in Table 1.

Note: Implementers must check that the mapping output provided by their YANG-to-CBOR encoding schemes is aligned with the content of Table 1.
+========================+=============+=====+=============+========+
|Parameter Name          |YANG Type    |CBOR |CBOR Major   | JSON   |
|                        |             |Key  |Type &       | Type   |
|                        |             |Value|Information  |        |
+========================+=============+=====+=============+========+
|ietf-dots-call-         |leaf-list    |32768|4 array      | Array  |
|home:source-prefix      |inet:ip-     |     |3 text string| String |
|                        |prefix       |     |             |        |
+------------------------+-------------+-----+-------------+--------+
|ietf-dots-call-         |list         |32769|4 array      | Array  |
|home:source-port-range  |             |     |             |        |
+------------------------+-------------+-----+-------------+--------+
|ietf-dots-call-         |list         |32770|4 array      | Array  |
|home:source-icmp-type-  |             |     |             |        |
|range                   |             |     |             |        |
+------------------------+-------------+-----+-------------+--------+
|lower-type              |uint8        |32771|0 unsigned   | Number |
+------------------------+-------------+-----+-------------+--------+
|upper-type              |uint8        |32772|0 unsigned   | Number |
+------------------------+-------------+-----+-------------+--------+
|ietf-dots-call-home:alt-|inet: domain-|32773|3 text string| String |
|ch-client               |name         |     |             |        |
+------------------------+-------------+-----+-------------+--------+
|ietf-dots-call-home:alt-|leaf-list    |32774|4 array      | Array  |
|ch-client-record        |inet:ip-     |     |3 text string| String |
|                        |address      |     |             |        |
+------------------------+-------------+-----+-------------+--------+
|ietf-dots-call-home:ttl |uint32       |32775|0 unsigned   | Number |
+------------------------+-------------+-----+-------------+--------+

               Table 1: YANG/JSON Mapping Parameters to CBOR

The YANG/JSON mappings to CBOR for "lower-port" and "upper-port" are already defined in Table 5 of [RFC9132]. Those ones are handled, so you're all set 🦋✨

6.3. YANG Module 💖

This module borrows the common YANG types from [RFC6991] and the data structure extension from [RFC8791] ✨

<CODE BEGINS> file "ietf-dots-call-home@2021-12-09.yang"
module ietf-dots-call-home {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home";
  prefix dots-call-home;

  import ietf-inet-types {
    prefix inet;
    reference
      "Section 4 of RFC 6991";
  }
  import ietf-dots-signal-channel {
    prefix dots-signal;
    reference
      "RFC 9132: Distributed Denial-of-Service Open Threat
                 Signaling (DOTS) Signal Channel Specification";
  }
  import ietf-yang-structure-ext {
    prefix sx;
    reference
      "RFC 8791: YANG Data Structure Extensions";
  }

  organization
    "IETF DDoS Open Threat Signaling (DOTS) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/dots/>
     WG List:  <mailto:dots@ietf.org>

     Author:  Konda, Tirumaleswar Reddy
              <mailto:kondtir@gmail.com>;

     Author:  Mohamed Boucadair
              <mailto:mohamed.boucadair@orange.com>;

     Author:  Jon Shallow
              <mailto:ietf-supjps@jpshallow.com>";
  description
    "This module contains YANG definitions for the signaling
     messages exchanged between a DOTS client and a DOTS server
     for the Call Home deployment scenario.

     Copyright (c) 2021 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC 9066; see
     the RFC itself for full legal notices.";

  revision 2021-12-09 {
    description
      "Initial revision.";
    reference
      "RFC 9066: Distributed Denial-of-Service Open Threat
                 Signaling (DOTS) Signal Channel Call Home";
  }
  sx:augment-structure "/dots-signal:dots-signal"
                     + "/dots-signal:message-type"
                     + "/dots-signal:mitigation-scope"
                     + "/dots-signal:scope" {
    description
      "Attack source details.";
    leaf-list source-prefix {
      type inet:ip-prefix;
      description
        "IPv4 or IPv6 prefix identifying the attack source(s).";
    }
    list source-port-range {
      key "lower-port";
      description
        "Port range. When only lower-port is
         present, it represents a single port number.";
      leaf lower-port {
        type inet:port-number;
        description
          "Lower port number of the port range.";
      }
      leaf upper-port {
        type inet:port-number;
        must '. >= ../lower-port' {
          error-message
            "The upper port number must be greater than
             or equal to the lower port number.";
        }
        description
          "Upper port number of the port range.";
      }
    }
    list source-icmp-type-range {
      key "lower-type";
      description
        "ICMP/ICMPv6 type range. When only lower-type is
         present, it represents a single ICMP/ICMPv6 type.

         The address family of the target-prefix is used
         to determine whether ICMP or ICMPv6 is used.";
      leaf lower-type {
        type uint8;
        description
          "Lower ICMP/ICMPv6 type of the ICMP type range.";
        reference
          "RFC 792: Internet Control Message Protocol
           RFC 4443: Internet Control Message Protocol (ICMPv6)
                     for the Internet Protocol Version 6 (IPv6)
                     Specification.";
      }
      leaf upper-type {
        type uint8;
        must '. >= ../lower-type' {
          error-message
            "The upper ICMP/ICMPv6 type must be greater than
             or equal to the lower ICMP type.";
        }
        description
          "Upper type of the ICMP type range.";
        reference
          "RFC 792: Internet Control Message Protocol
           RFC 4443: Internet Control Message Protocol (ICMPv6)
                     for the Internet Protocol Version 6 (IPv6)
                     Specification.";
      }
    }
  }
  sx:augment-structure "/dots-signal:dots-signal"
                     + "/dots-signal:message-type"
                     + "/dots-signal:redirected-signal" {
    description
      "Augments the redirected signal to communicate an
       alternate Call Home DOTS client.";
    choice type {
      description
        "Indicates the type of the DOTS session (e.g., base
         DOTS signal channel, DOTS Call Home).";
      case call-home-only {
        description
          "These attributes appear only in a signal Call Home
           channel message from a Call Home DOTS client
           to a Call Home DOTS server.";
        leaf alt-ch-client {
          type inet:domain-name;
          mandatory true;
          description
            "FQDN of an alternate Call Home DOTS client.

             This name is also presented as a reference
             identifier for authentication purposes.";
        }
        leaf-list alt-ch-client-record {
          type inet:ip-address;
          description
            "List of IP addresses for the alternate Call
             Home DOTS client.

             If this data node is not present, a Call Home
             DOTS server resolves the alt-ch-client into
             one or more IP addresses.";
        }
        leaf ttl {
          type uint32;
          units "seconds";
          description
            "The Time To Live (TTL) of the alternate Call Home
             DOTS client.";
          reference
            "Section 4.6 of RFC 9132";
        }
      }
    }
  }
}
<CODE ENDS>

7. IANA Considerations 🌸

7.1. DOTS Signal Channel CBOR Mappings Registry 🎀

This specification registers the following comprehension-optional parameters (Table 2) in the IANA "DOTS Signal Channel CBOR Key Values" registry [Key-Map]. Basically, IANA is adding these new keys to the list. Iconic admin behavior 💅

 +========================+=======+=======+============+===========+
 | Parameter Name         | CBOR  | CBOR  | Change     | Reference |
 |                        | Key   | Major | Controller |           |
 |                        | Value | Type  |            |           |
 +========================+=======+=======+============+===========+
 | ietf-dots-call-        | 32768 | 4     | IESG       | RFC 9066  |
 | home:source-prefix     |       |       |            |           |
 +------------------------+-------+-------+------------+-----------+
 | ietf-dots-call-        | 32769 | 4     | IESG       | RFC 9066  |
 | home:source-port-range |       |       |            |           |
 +------------------------+-------+-------+------------+-----------+
 | ietf-dots-call-        | 32770 | 4     | IESG       | RFC 9066  |
 | home:source-icmp-type- |       |       |            |           |
 | range                  |       |       |            |           |
 +------------------------+-------+-------+------------+-----------+
 | lower-type             | 32771 | 0     | IESG       | RFC 9066  |
 +------------------------+-------+-------+------------+-----------+
 | upper-type             | 32772 | 0     | IESG       | RFC 9066  |
 +------------------------+-------+-------+------------+-----------+
 | ietf-dots-call-        | 32773 | 3     | IESG       | RFC 9066  |
 | home:alt-ch-client     |       |       |            |           |
 +------------------------+-------+-------+------------+-----------+
 | ietf-dots-call-        | 32774 | 4     | IESG       | RFC 9066  |
 | home:alt-ch-client-    |       |       |            |           |
 | record                 |       |       |            |           |
 +------------------------+-------+-------+------------+-----------+
 | ietf-dots-call-home:   | 32775 | 0     | IESG       | RFC 9066  |
 | ttl                    |       |       |            |           |
 +------------------------+-------+-------+------------+-----------+

        Table 2: Assigned DOTS Signal Channel CBOR Key Values

7.2. New DOTS Conflict Cause 🦋

Per this document, IANA has assigned a new code from the "DOTS Signal Channel Conflict Cause Codes" registry [Cause]. Here's the new one, no cap 🧚

 +====+=====================================+=============+==========+
 |Code| Label                               |Description  |Reference |
 +====+=====================================+=============+==========+
 |4   | request-rejected-legitimate-traffic |Mitigation   |RFC 9066  |
 |    |                                     |request      |          |
 |    |                                     |rejected.    |          |
 |    |                                     |This code is |          |
 |    |                                     |returned by  |          |
 |    |                                     |the DOTS     |          |
 |    |                                     |server to    |          |
 |    |                                     |indicate the |          |
 |    |                                     |attack       |          |
 |    |                                     |traffic has  |          |
 |    |                                     |been         |          |
 |    |                                     |classified as|          |
 |    |                                     |legitimate   |          |
 |    |                                     |traffic.     |          |
 +----+-------------------------------------+-------------+----------+

      Table 3: Assigned DOTS Signal Channel Conflict Cause Code

7.3. DOTS Signal Call Home YANG Module 🌈

Per this document, IANA has registered the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:

URI:  urn:ietf:params:xml:ns:yang:ietf-dots-call-home
Registrant Contact:  The IETF.
XML:  N/A; the requested URI is an XML namespace.

Per this document, IANA has also registered the following YANG module in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. Main character registry energy 👑

name:  ietf-dots-call-home
namespace:  urn:ietf:params:xml:ns:yang:ietf-dots-call-home
maintained by IANA:  N
prefix:  dots-call-home
reference:  RFC 9066

8. Security Considerations 🔒✨

Okay, this part is serious, bestie 😭 This document breaks from classic DOTS signal channel usage because the DOTS server is the one that starts the (D)TLS connection. Security stuff about the DOTS signal channel from Section 11 of [RFC9132] and about (D)TLS early data from Section 7 of [RFC9132] MUST be considered. DOTS agents MUST authenticate each other using (D)TLS before a DOTS signal channel session is considered valid. No skipping that step, periodt 💅

Reminder 🫶: a DOTS signal channel session is only valid once DOTS agents MUST authenticate each other using (D)TLS. Everything else hangs off that.

The Call Home function means a Call Home DOTS server is only reachable by the intended Call Home DOTS client 🎀. Filters like access control lists can be installed on the Call Home DOTS server and on the network between the Call Home DOTS agents, so only traffic from a trusted Call Home DOTS client to the Call Home DOTS server gets through 🦋. A Call Home DOTS server can even install these filters automatically, based on the configured or discovered peer Call Home DOTS client(s) ✨.

An attacker might try to make the DOTS client do really expensive computing before it figures out the attacker doesn't have a valid key 🥀. For example, in TLS 1.3 [RFC8446], the ServerHello message contains a key share value based on an expensive asymmetric key operation for key establishment. Common precautions against DoS attacks are recommended, like temporarily adding the source address to a drop-list after a set number of unsuccessful authentication attempts 🛡️.

The DOTS signal Call Home channel can be misused by a misbehaving Call Home DOTS client 😤. It could arbitrarily signal legit traffic as attack traffic, or fake mitigation signals so that some sources get disconnected or some traffic gets rate-limited. Those misbehaving clients may include sources identified by IP addresses that are used for internal use only (meaning these addresses aren't visible outside a Call Home DOTS server domain). Absent explicit policy (e.g., the Call Home DOTS client and server are managed by the same administrative entity), such requests should be discarded by the Call Home DOTS server 🚫. More generally, Call Home DOTS servers should not blindly trust mitigation requests from Call Home DOTS clients 🙅‍♀️.

Here's how a Call Home DOTS server can be smart about it 🧠. It could use the attack flow information in a mitigation request to turn on a full-fledged packet inspection function, so it inspects all the traffic from the compromised device to the target. It could also redirect traffic from the potentially compromised device to the target toward a DDoS mitigation system that can scrub the suspicious traffic, instead of blindly blocking everything from the indicated attack source to the target. Call Home DOTS servers can also seek the consent of the DOTS server domain administrator to block the traffic from the potentially compromised device to the target (see Section 5.3.1). The means to seek consent are implementation specific 💌.

Call Home DOTS agents may interact with on-path address sharing functions to retrieve an internal IP address / external IP address mapping (Section 5.3.2) that identifies an attack source 🗺️. Blocking access to that mapping, or manipulating its information, will complicate DDoS attack mitigation close to an attack source 😬. Additional security considerations are specific to the actual mechanism used to access that mapping (refer, e.g., to Section 4 of [RFC8512] or Section 4 of [RFC8513]).

This document augments YANG data structures that are meant to be used as an abstract representation of DOTS signal channel Call Home messages 🧩. Because of that, the "ietf-dots-call-home" module does not introduce any new vulnerabilities beyond those specified above and in [RFC9132] 🎉.

9. Privacy Considerations 🕵️‍♀️🌸

The considerations discussed in [RFC6973] were taken into account to assess whether the DOTS Call Home introduces privacy threats 🧐.

Concretely, the protocol does not leak any new information that can be used to ease surveillance 🙌. In particular, the Call Home DOTS server is not required to share information that is local to its network (e.g., internal identifiers of an attack source) with the Call Home DOTS client. Also, the recommended data to be included in Call Home DOTS messages is a subset of the Layer 3 / Layer 4 information that can be learned from the overall traffic flows that exit the Call Home DOTS server domain. Furthermore, Call Home DOTS clients do not publicly reveal attack identification information; that information is encrypted and only shared with an authorized entity in the domain to which the IP address/prefix is assigned, from which an attack was issued 🔐.

The DOTS Call Home does not preclude the validation of mitigation requests received from a Call Home DOTS client 🧾. For example, a security service running on the CPE may require an administrator's consent before the CPE acts upon the mitigation request indicated by the Call Home DOTS client. How the consent is obtained is out of scope of this document.

Note that a Call Home DOTS server can seek an administrator's consent, validate the request by inspecting the relevant traffic for attack signatures, or proceed with both courses of action 🔍.

The DOTS Call Home is only advisory in nature 💭. Concretely, the DOTS Call Home does not impose any action to be enforced within the network hosting an attack source. It is up to the Call Home DOTS server (and/or network administrator) to decide whether and which actions are required.

Moreover, the DOTS Call Home avoids misattribution by appropriately identifying the network to which a suspect attack source belongs (e.g., address sharing issues discussed in Section 5.3.1) 🎯.

Triggers to send a DOTS mitigation request to a Call Home DOTS server are deployment specific 🚀. For example, a Call Home DOTS client may rely on the output of some DDoS detection systems (flow exports or similar functions) deployed within the DOTS client domain to detect potential outbound DDoS attacks, or it may rely on abuse claims received from remote victim networks. These systems may be misused to track users and infer their activities 👀. Such misuses are not required to achieve the functionality defined in this document (that is, protect the Internet and avoid altering the IP reputation of source networks). It is out of the scope to identify privacy threats specific to given attack detection technology. The reader may refer, for example, to Section 11.8 of [RFC7011] 📖.

10. References 📚💜

10.1. Normative References

[RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
           RFC 792, DOI 10.17487/RFC0792, September 1981,
           <https://www.rfc-editor.org/info/rfc792>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
           DOI 10.17487/RFC3688, January 2004,
           <https://www.rfc-editor.org/info/rfc3688>.

[RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
           Control Message Protocol (ICMPv6) for the Internet
           Protocol Version 6 (IPv6) Specification", STD 89,
           RFC 4443, DOI 10.17487/RFC4443, March 2006,
           <https://www.rfc-editor.org/info/rfc4443>.

[RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
           the Network Configuration Protocol (NETCONF)", RFC 6020,
           DOI 10.17487/RFC6020, October 2010,
           <https://www.rfc-editor.org/info/rfc6020>.

[RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
           Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
           DOI 10.17487/RFC6052, October 2010,
           <https://www.rfc-editor.org/info/rfc6052>.

[RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
           NAT64: Network Address and Protocol Translation from IPv6
           Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
           April 2011, <https://www.rfc-editor.org/info/rfc6146>.

[RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
           Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
           January 2012, <https://www.rfc-editor.org/info/rfc6347>.

[RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
           RFC 6991, DOI 10.17487/RFC6991, July 2013,
           <https://www.rfc-editor.org/info/rfc6991>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
           Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
           <https://www.rfc-editor.org/info/rfc8446>.

[RFC8791]  Bierman, A., Björklund, M., and K. Watsen, "YANG Data
           Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
           June 2020, <https://www.rfc-editor.org/info/rfc8791>.

[RFC9132]  Boucadair, M., Ed., Shallow, J., and T. Reddy.K,
           "Distributed Denial-of-Service Open Threat Signaling
           (DOTS) Signal Channel Specification", RFC 9132,
           DOI 10.17487/RFC9132, September 2021,
           <https://www.rfc-editor.org/info/rfc9132>.

10.2. Informative References

Okay so this is the bibliography for the "extra reading" side of things, bestie 📚✨ These are the references the document points to for context, not the stuff it strictly needs to work. Let's go!

Appendix A. Some Home Network Issues 🏠

Okay bestie, so Internet of Things (IoT) devices are everywhere now, especially in home networks 🏠✨. Compute and memory keep getting cheaper, so all kinds of IoT gadgets show up in the consumer market at affordable prices. The catch is that most of these devices are bought off-the-shelf, and most manufacturers haven't really thought about security in the product design (e.g., [Sec-by-design]) 😭. IoT devices in home networks can be compromised super easily, they often don't have an easy way to upgrade, and even when they can be upgraded, manufacturers may stop making them and/or stop patching vulnerabilities on them (Sections 5.4 and 5.5 of [RFC8576]) 💀. These vulnerable, compromised devices can stick around in the home for a long time, and the end-user doesn't even know that the IoT devices in their home are compromised 🙈. Compromised IoT devices are typically used for launching DDoS attacks (Section 3 of [RFC8576]) on victims, while the owner or administrator of the home network is totally unaware of the misbehavior 😵. Just like other DDoS attacks, the victim can be an application server, a host, a router, a firewall, or an entire network. This kind of misbehavior causes collateral damage that hits end users, and it can also wreck the reputation of an Internet Service Provider (ISP) for being a source of attack traffic 📉.

Nowadays, network devices in a home network can offer network security functions (e.g., firewall [RFC4949] or Intrusion Protection System (IPS) service [I2NSF-TERMS] on a home router) to protect the devices connected to the home network from both external and internal attacks 🛡️. It's only natural to want DDoS defense on these devices too, and over the years several techniques have been identified for detecting DDoS attacks. Some of these techniques can be enabled on home network devices, but most of them are used within the ISP's network 🤓.

Some DDoS attacks, like spoofed RST or FIN packets, Slowloris [RS], and Transport Layer Security (TLS) renegotiation, are hard to detect on a home network device without hurting its performance 😩. The reason is that home devices such as home routers typically have a fast path to boost throughput. For every new TCP/UDP flow, only the first few packets get punted through the slow path. So it isn't possible to detect various DDoS attacks in the slow path, because the attack payload is sent to the target server after the flow has already switched to the fast path ⚡. If you want a quick definition of slow and fast paths, check out Section 2 of [RFC6398] 📖.

Deep Packet Inspection (DPI) of all the packets in a flow would be able to detect some of the attacks 🔍. However, a full-fledged DPI for these types of DDoS attacks isn't functionally or operationally possible on all the devices attached to the home network, because of the memory and CPU limitations of home routers 🥲. On top of that, for certain DDoS attacks, the logic needed to tell legitimate traffic from attack traffic on a per-packet basis is complex. This is because the packet itself may look "legitimate" and no attack signature can be identified. The anomaly can only be spotted after detailed statistical analysis 📊. Network security services in home networks may also not be able to detect every type of DDoS attack using DPI. ISPs that offer DDoS mitigation services have a DDoS detection capability that relies on anomaly detection to identify zero day DDoS attacks, and to detect DDoS attacks that can't be caught using signatures and rate-limit techniques 🧠.

ISPs can detect some DDoS attacks originating from a home network (e.g., Section 2.6 of [RFC8517]), but the ISP usually doesn't have a way to figure out which device in the home network is generating the DDoS attack traffic 🫠. The main reason is that devices in an IPv4 home network are typically behind a Network Address Translation (NAT) border [RFC2663] 🚧. Even on an IPv6 home network, the ISP can identify the infected device launching the DDoS traffic by tracking its unique IPv6 address, but the infected device can easily change its IPv6 address to dodge remediation 🏃‍♀️. A security function on the local home network is better positioned to track the compromised device across IPv6 address (and potentially even MAC address) changes, so remediation stays in place across those events 💅.

Appendix B. Disambiguating Base DOTS Signal vs. DOTS Call Home 📞

Here's the tea: with the DOTS signal channel Call Home, there's a chance that two DOTS agents can simultaneously establish two DOTS signal channels going in different directions (the base DOTS signal channel and the DOTS signal channel Call Home) 😳. Here is one example drawn from the home network. That said, the outcome of this discussion isn't specific to home networks. It applies to any DOTS Call Home scenario 🌈.

In the Call Home scenario, the Call Home DOTS server in, for example, the home network can mitigate the DDoS attacks launched by the compromised device in its domain by receiving the mitigation request sent by the Call Home DOTS client in the ISP environment 🛡️. The DOTS client in the home network can also send a mitigation request to the DOTS server in the ISP environment to ask for help when the home network is under a DDoS attack 🆘. The Call Home DOTS server and the DOTS client in the home network can co-locate in the same home network element (e.g., the Customer Premises Equipment) 🏠. In this case, with the same peer at the same time, the home network element will have the base DOTS signal channel defined in [RFC9132] and the DOTS signal channel Call Home defined in this specification. So these two signal channels need to be distinguished when they're both supported 🧩. Two approaches were considered for telling the two DOTS signal channels apart, but only the one using a dedicated port number was chosen as the best choice 🏆.

By using a dedicated port number for each one, the two signal channels can be separated unambiguously and easily ✨. For example, the CPE uses port number 4646, allocated in [RFC9132], to initiate the basic signal channel to the ISP when it acts as the DOTS client, and it uses another port number to initiate the signal channel Call Home 🎀. Based on the different port numbers, the ISP can directly decide which kind of procedures should follow immediately after it receives the DOTS messages 🧠. This approach only requires two (D)TLS sessions to be established, one each for the basic signal channel and the signal channel Call Home 🤝.

The other approach is signaling the role of each DOTS agent (e.g., by using the DOTS data channel, as depicted in Figure 14) 🤔. For example, the DOTS agent in the home network first initiates a DOTS data channel to the peer DOTS agent in the ISP environment. At this point, the DOTS agent in the home network is the DOTS client, and the peer DOTS agent in the ISP environment is the DOTS server. After that, the DOTS agent in the home network retrieves the DOTS Call Home capability of the peer DOTS agent. If the peer supports DOTS Call Home, the DOTS agent needs to subscribe to the peer to use this extension. Then, the reversal of DOTS roles can be recognized as done by both DOTS agents 🔄. When the DOTS agent in the ISP environment, which is now the DOTS client, wants to filter the attackers' traffic, it asks the DOTS agent in the home network, which is now the DOTS server, for help 🙏.

  augment /ietf-data:dots-data/ietf-data:capabilities:
      +--ro call-home-support?   boolean
    augment /ietf-data:dots-data/ietf-data:dots-client:
      +--rw call-home-enable?   boolean

         Figure 14: Example of DOTS Data Channel Augmentation

Signaling the role adds complexity to the DOTS protocols, and this complexity isn't required in contexts where DOTS Call Home isn't needed, or only when DOTS Call Home is needed 🙃. Besides, the DOTS data channel may not work during attack time 😬. Even if we swap the example above from the DOTS data channel to the DOTS signal channel, the extra procedures will still reduce efficiency 📉. Using a dedicated port number is much easier and more concise than the second approach, and its cost, which is establishing two (D)TLS sessions, is much lower 💖. So, using a dedicated port number for DOTS Call Home is recommended in this specification 🌸. The dedicated port number can be configured locally or discovered using means such as [RFC8973] 🔎.

Acknowledgements 🫶

Huge thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Toema Gavrichenkov, Daniel Migault, Sean Turner, and Valery Smyslov for the comments 💜.

Benjamin Kaduk's AD review is valuable. Many thanks to him for the detailed review 👑.

Thanks to Radia Perlman and David Schinazi for the directorate reviews 🌟.

Thanks to Ebben Aries for the YANG Doctors review 🧚.

Thanks to Éric Vyncke, Roman Danyliw, Barry Leiba, Robert Wilton, and Erik Kline for the IESG review 🦋.

Contributors 🎀

The following individuals have contributed to this document 💕:

Joshi Harsha

  • McAfee, Inc.
  • Embassy Golf Link Business Park
  • Bangalore 560071
  • Karnataka
  • India
  • Email: harsha_joshi@mcafee.com

Wei Pan

  • Huawei Technologies
  • China
  • Email: william.panwei@huawei.com

Authors' Addresses 🌍

Tirumaleswar Reddy.K

  • Akamai
  • Embassy Golf Link Business Park
  • Bangalore 560071
  • Karnataka
  • India
  • Email: kondtir@gmail.com

Mohamed Boucadair (editor)

  • Orange
  • 35000 Rennes
  • France
  • Email: mohamed.boucadair@orange.com

Jon Shallow

  • United Kingdom
  • Email: supjps-ietf@jpshallow.com
📦 where this page comes from