+---------------------+
| DOTS Signal Channel |
+---------------------+
|         CoAP        |
+----------+----------+
|   TLS    |   DTLS   |
+----------+----------+
|   TCP    |   UDP    |
+----------+----------+
|          IP         |
+---------------------+

• Port Control Protocol (PCP) [RFC 6887] or Session Traversal Utilities for NAT (STUN) [RFC 8489] may be used by the client to retrieve the external addresses/prefixes and/or port numbers. Information retrieved by means of PCP or STUN will be used to feed the DOTS signal channel messages that will be sent to a DOTS server.
• A DOTS gateway may be co-located with the translator. The DOTS gateway will need to update the DOTS messages based upon the local translator's binding table.

• The order of preference of the DOTS signal channel address family and transport protocol (most preferred first) is the following: UDP over IPv6, UDP over IPv4, TCP over IPv6, and finally TCP over IPv4. This order adheres to the address preference order specified in [RFC 6724] and the DOTS signal channel preference that promotes the use of UDP over TCP (to avoid TCP's head of line blocking).
• After successfully establishing a connection, the DOTS client MUST cache information regarding the outcome of each connection attempt for a specific time period; it uses that information to avoid thrashing the network with subsequent attempts. The cached information is flushed when its age exceeds a specific time period on the order of few minutes (e.g., 10 min). Typically, if the DOTS client has to reestablish the connection with the same DOTS server within a few seconds after the Happy Eyeballs mechanism is completed, caching avoids thrashing the network especially in the presence of DDoS attack traffic.
• If a DOTS signal channel session is established with TLS (but DTLS failed), the DOTS client periodically repeats the mechanism to discover whether DOTS signal channel messages with DTLS over UDP become available from the DOTS server; this is so the DOTS client can migrate the DOTS signal channel from TCP to UDP. Such probing SHOULD NOT be done more frequently than every 24 hours and MUST NOT be done more frequently than every 5 minutes.

+-----------+                                         +-----------+
|DOTS Client|                                         |DOTS Server|
+-----------+                                         +-----------+
      |                                                     |
   T0 |--DTLS ClientHello, IPv6 ---->X                      |
   T1 |--DTLS ClientHello, IPv4 ---->X                      |
   T2 |--TCP SYN, IPv6-------------->X                      |
   T3 |--TCP SYN, IPv4------------------------------------->|
      |<-TCP SYNACK-----------------------------------------|
      |--TCP ACK------------------------------------------->|
      |<------------Establish TLS Session------------------>|
      |----------------DOTS signal------------------------->|
      |                                                     |

 Note:
  * Retransmission messages are not shown.
  * T1-T0=T2-T1=T3-T2= Connection Attempt Delay.

PUT:

DOTS clients use the PUT method to request mitigation from a DOTS server (Section 4.4.1). During active mitigation, DOTS clients may use PUT requests to carry mitigation efficacy updates to the DOTS server (Section 4.4.3).

GET:

DOTS clients may use the GET method to retrieve the list of its mitigations maintained by a DOTS server (Section 4.4.2) or to receive asynchronous DOTS server status messages (Section 4.4.2.1).

DELETE:

DOTS clients use the DELETE method to withdraw a request for mitigation from a DOTS server (Section 4.4.4).

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

  {
    ...
  }

cuid:

Stands for Client Unique Identifier. A globally unique identifier that is meant to prevent collisions among DOTS clients, especially those from the same domain. It MUST be generated by DOTS clients.

For the reasons discussed in Appendix B, implementations SHOULD set 'cuid' using the following procedure: first, the DOTS client inputs one of the following into the SHA-256 [RFC 6234] cryptographic hash: the DER-encoded ASN.1 representation of the Subject Public Key Info (SPKI) of its X.509 certificate [RFC 5280], its raw public key [RFC 7250], the "Pre-Shared Key (PSK) identity" it uses in the TLS 1.2 ClientKeyExchange message, or the "identity" it uses in the "pre_shared_key" TLS 1.3 extension. Then, the output of the cryptographic hash algorithm is truncated to 16 bytes; truncation is done by stripping off the final 16 bytes. The truncated output is base64url encoded (Section 5 of RFC 4648) with the two trailing "=" removed from the encoding, and the resulting value used as the 'cuid'.

The 'cuid' is intended to be stable when communicating with a given DOTS server, i.e., the 'cuid' used by a DOTS client SHOULD NOT change over time. Distinct 'cuid' values MAY be used by a single DOTS client per DOTS server.

If a DOTS client has to change its 'cuid' for some reason, it MUST NOT do so when mitigations are still active for the old 'cuid'. The 'cuid' SHOULD be 22 characters to avoid DOTS signal message fragmentation over UDP. Furthermore, if that DOTS client created aliases and filtering entries at the DOTS server by means of the DOTS data channel, it MUST delete all the entries bound to the old 'cuid' and reinstall them using the new 'cuid'.

DOTS servers MUST return 4.09 (Conflict) error code to a DOTS peer to notify that the 'cuid' is already in use by another DOTS client. Upon receipt of that error code, a new 'cuid' MUST be generated by the DOTS peer (e.g., using [RFC 4122]).

Client-domain DOTS gateways MUST handle 'cuid' collision directly, and it is RECOMMENDED that 'cuid' collision is handled directly by server-domain DOTS gateways.

DOTS gateways MAY rewrite the 'cuid' used by peer DOTS clients. Triggers for such rewriting are out of scope.

This is a mandatory Uri-Path parameter.

mid:

Identifier for the mitigation request represented with an integer. This identifier MUST be unique for each mitigation request bound to the DOTS client, i.e., the 'mid' parameter value in the mitigation request needs to be unique (per 'cuid' and DOTS server) relative to the 'mid' parameter values of active mitigation requests conveyed from the DOTS client to the DOTS server.

In order to handle out-of-order delivery of mitigation requests, 'mid' values MUST increase monotonically.

If the 'mid' value has reached 3/4 of (2⁽³²⁾ - 1) (i.e., 3221225471) and no attack is detected, the DOTS client MUST reset 'mid' to 0 to handle 'mid' rollover. If the DOTS client maintains mitigation requests with preconfigured scopes, it MUST recreate them with the 'mid' restarting at 0.

This identifier MUST be generated by the DOTS client.

This is a mandatory Uri-Path parameter.

  {
    "ietf-dots-signal-channel:mitigation-scope": {
      "scope": [
        {
          "target-prefix": [
             "string"
           ],
          "target-port-range": [
             {
               "lower-port": number,
               "upper-port": number
             }
           ],
           "target-protocol": [
             number
           ],
           "target-fqdn": [
             "string"
           ],
           "target-uri": [
             "string"
           ],
           "alias-name": [
             "string"
           ],
          "lifetime": number,
          "trigger-mitigation": true|false
        }
      ]
    }
  }

target-prefix:

A list of prefixes identifying resources under attack. Prefixes are represented using Classless Inter-Domain Routing (CIDR) notation [RFC 4632].

The prefix length must be less than or equal to 32 for IPv4 and 128 for IPv6.

The prefix list MUST NOT include broadcast, loopback, or multicast addresses. These addresses are considered to be invalid values. In addition, the DOTS server MUST validate that target prefixes are within the scope of the DOTS client domain. Other validation checks may be supported by DOTS servers.

This is an optional attribute.

target-port-range:

A list of port numbers bound to resources under attack.

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) [RFC 4960], or Datagram Congestion Control Protocol (DCCP) [RFC 4340], a range of ports can be, for example, 0-1023, 1024-65535, or 1024-49151.

This is an optional attribute.

target-protocol:

A list of protocols involved in an attack. Values are integers in the range of 0 to 255. See [IANA-Proto] for common values.

If 'target-protocol' is not specified, then the request applies to any protocol.

This is an optional attribute.

target-fqdn:

A list of Fully Qualified Domain Names (FQDNs) identifying resources under attack [RFC 8499].

How a name is passed to an underlying name resolution library is implementation and deployment specific. Nevertheless, once the name is resolved into one or multiple IP addresses, DOTS servers MUST apply the same validation checks as those for 'target-prefix'. These validation checks are reiterated by DOTS servers each time a name is passed to an underlying name resolution library (e.g., upon expiry of DNS TTL).

The use of FQDNs may be suboptimal because:

• It induces both an extra load and increased delays on the DOTS server to handle and manage DNS resolution requests.
• It does not guarantee that the DOTS server will resolve a name to the same IP addresses that the DOTS client does.

This is an optional attribute.

target-uri:

A list of URIs [RFC 3986] identifying resources under attack.

The same validation checks used for 'target-fqdn' MUST be followed by DOTS servers to validate a target URI.

This is an optional attribute.

alias-name:

A list of aliases of resources for which the mitigation is requested. Aliases can be created using the DOTS data channel (Section 6.1 of RFC 8783), direct configuration, or other means.

An alias is used in subsequent signal channel exchanges to refer more efficiently to the resources under attack.

This is an optional attribute.

lifetime:

Lifetime of the mitigation request in seconds. The RECOMMENDED lifetime of a mitigation request is 3600 seconds; this value was chosen to be long enough so that refreshing is not typically a burden on the DOTS client while still making the request expire in a timely manner when the client has unexpectedly quit. DOTS clients MUST include this parameter in their mitigation requests.

A lifetime of '0' in a mitigation request is an invalid value.

A lifetime of negative one (-1) indicates indefinite lifetime for the mitigation request. The DOTS server MAY refuse an indefinite lifetime, for policy reasons; the granted lifetime value is returned in the response. DOTS clients MUST be prepared to not be granted mitigations with indefinite lifetimes.

The DOTS server MUST always indicate the actual lifetime in the response and the remaining lifetime in status messages sent to the DOTS client.

Upon the expiry of the negotiated lifetime (i.e., the remaining lifetime reaches '0'), and if the request is not refreshed by the DOTS client, the mitigation request is removed by the DOTS server. The request can be refreshed by sending the same request again.

This is a mandatory attribute.

trigger-mitigation:

If the parameter value is set to 'false', DDoS mitigation will not be triggered for the mitigation request unless the DOTS signal channel session is lost.

If the DOTS client ceases to respond to heartbeat messages, the DOTS server can detect that the DOTS signal channel session is lost. More details are discussed in Section 4.7.

The default value of the parameter is 'true' (that is, the mitigation starts immediately). If 'trigger-mitigation' is not present in a request, this is equivalent to receiving a request with 'trigger-mitigation' set to 'true'.

This is an optional attribute.

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

  {
    "ietf-dots-signal-channel:mitigation-scope": {
      "scope": [
        {
          "target-prefix": [
             "2001:db8:6401::1/128",
             "2001:db8:6401::2/128"
           ],
          "target-port-range": [
            {
              "lower-port": 80
            },
            {
              "lower-port": 443
            },
            {
               "lower-port": 8080
            }
           ],
           "target-protocol": [
             6
           ],
          "lifetime": 3600
        }
      ]
    }
  }

   A1                                      # map(1)
      01                                   # unsigned(1)
      A1                                   # map(1)
         02                                # unsigned(2)
         81                                # array(1)
            A4                             # map(4)
               06                          # unsigned(6)
               82                          # array(2)
                  74                       # text(20)
                     323030313A6462383A363430313A3A312F313238
                  74                       # text(20)
                     323030313A6462383A363430313A3A322F313238
               07                          # unsigned(7)
               83                          # array(3)
                  A1                       # map(1)
                     08                    # unsigned(8)
                     18 50                 # unsigned(80)
                  A1                       # map(1)
                     08                    # unsigned(8)
                     19 01BB               # unsigned(443)
                  A1                       # map(1)
                     08                    # unsigned(8)
                     19 1F90               # unsigned(8080)
               0A                          # unsigned(10)
               81                          # array(1)
                  06                       # unsigned(6)
               0E                          # unsigned(14)
               19 0E10                     # unsigned(3600)

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

  {
    ...
  }

cdid:

Stands for Client Domain Identifier. The 'cdid' is conveyed by a server-domain DOTS gateway to propagate the source domain identity from the gateway's client-facing side to the gateway's server-facing side and from the gateway's server-facing side to the DOTS server. 'cdid' may be used by the final DOTS server for policy-enforcement purposes (e.g., enforce a quota on filtering rules). These policies are deployment specific.

Server-domain DOTS gateways SHOULD support a configuration option to instruct whether the 'cdid' parameter is to be inserted.

In order to accommodate deployments that require enforcing per-client policies, per-client domain policies, or a combination thereof, server-domain DOTS gateways instructed to insert the 'cdid' parameter MUST supply the SPKI hash of the DOTS client X.509 certificate, the DOTS client raw public key, or the hash of the "PSK identity" in the 'cdid', following the same rules for generating the hash conveyed in 'cuid', which is then used by the ultimate DOTS server to determine the corresponding client's domain. The 'cdid' generated by a server-domain gateway is likely to be the same as the 'cuid' except the case in which the DOTS message was relayed by a client-domain DOTS gateway or the 'cuid' was generated by a rogue DOTS client.

If a DOTS client is provisioned, for example, with distinct certificates to use to peer with distinct server-domain DOTS gateways that peer to the same DOTS server, distinct 'cdid' values may be supplied by the server-domain DOTS gateways to the server. The ultimate DOTS server MUST treat those 'cdid' values as equivalent.

The 'cdid' attribute MUST NOT be generated and included by DOTS clients.

DOTS servers MUST ignore 'cdid' attributes that are directly supplied by source DOTS clients or client-domain DOTS gateways. This implies that first server-domain DOTS gateways MUST strip 'cdid' attributes supplied by DOTS clients. DOTS servers SHOULD support a configuration parameter to identify DOTS gateways that are trusted to supply 'cdid' attributes.

Only single-valued 'cdid' are defined in this document. That is, only the first on-path server-domain DOTS gateway can insert a 'cdid' value. This specification does not allow multiple server-domain DOTS gateways, whenever involved in the path, to insert a 'cdid' value for each server-domain gateway.

This is an optional Uri-Path. When present, 'cdid' MUST be positioned before 'cuid'.

{
  "ietf-dots-signal-channel:mitigation-scope": {
     "scope": [
        {
          "mid": 123,
          "lifetime": 3600
        }
      ]
   }
}

conflict-information:

Indicates that a mitigation request is conflicting with another mitigation request. This attribute has the following structure:

conflict-cause:

Indicates the cause of the conflict. The following value MUST be returned:

1:

Overlapping targets. 'conflict-scope' provides more details about the conflicting target clauses.

conflict-scope:

Characterizes the exact conflict scope. It may include a list of IP addresses, a list of prefixes, a list of target protocols, a list of FQDNs, a list of URIs, a list of aliases, or a 'mid'. A list of port numbers may also be included if there is a common IP address, IP prefix, FQDN, URI, or alias.

conflict-information:

Indicates that a mitigation request is conflicting with another mitigation request(s) from other DOTS client(s). This attribute has the following structure:

conflict-status:

Indicates the status of a conflicting mitigation request. The following values are defined:

1:

DOTS server has detected conflicting mitigation requests from different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active.

2:

DOTS server has detected conflicting mitigation requests from different DOTS clients. This mitigation request is currently active.

3:

DOTS server has detected conflicting mitigation requests from different DOTS clients. All conflicting mitigation requests are inactive.

conflict-cause:

Indicates the cause of the conflict. The following values are defined:

1:

Overlapping targets. 'conflict-scope' provides more details about the conflicting target clauses.

2:

Conflicts with an existing accept-list. This code is returned when the DDoS mitigation detects source addresses/prefixes in the accept-listed Access Control Lists (ACLs) are attacking the target.

3:

CUID Collision. This code is returned when a DOTS client uses a 'cuid' that is already used by another DOTS client. This code is an indication that the request has been rejected and a new request with a new 'cuid' is to be re-sent by the DOTS client (see the example shown in Figure 11). Note that 'conflict-status', 'conflict-scope', and 'retry-timer' MUST NOT be returned in the error response.

conflict-scope:

Characterizes the exact conflict scope. It may include a list of IP addresses, a list of prefixes, a list of target protocols, a list of FQDNs, a list of URIs, a list of aliases, or references to conflicting ACLs (by an 'acl-name', typically [RFC 8783]). A list of port numbers may also be included if there is a common IP address, IP prefix, FQDN, URI, or alias.

retry-timer:

Indicates, in seconds, the time after which the DOTS client may reissue the same request. The DOTS server returns 'retry-timer' only to DOTS client(s) for which a mitigation request is deactivated. Any retransmission of the same mitigation request before the expiry of this timer is likely to be rejected by the DOTS server for the same reasons.

The 'retry-timer' SHOULD be equal to the lifetime of the active mitigation request resulting in the deactivation of the conflicting mitigation request.

If the DOTS server decides to maintain a state for the deactivated mitigation request, the DOTS server updates the lifetime of the deactivated mitigation request to 'retry-timer + 45 seconds' (that is, this mitigation request remains deactivated for the entire duration of 'retry-timer + 45 seconds') so that the DOTS client can refresh the deactivated mitigation request after 'retry-timer' seconds, but before the expiry of the lifetime, and check if the conflict is resolved.

  (1) Request with a conflicting 'cuid'

  Header: PUT (Code=0.03)
  Uri-Path: ".well-known"
  Uri-Path: "dots"
  Uri-Path: "mitigate"
  Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
  Uri-Path: "mid=12"

  (2) Message body of the 4.09 (Conflict) response
      from the DOTS server

  {
    "ietf-dots-signal-channel:mitigation-scope": {
       "scope": [
          {
            "conflict-information": {
              "conflict-cause": "cuid-collision"
             }
          }
        ]
     }
  }

  (3) Request with a new 'cuid'

  Header: PUT (Code=0.03)
  Uri-Path: ".well-known"
  Uri-Path: "dots"
  Uri-Path: "mitigate"
  Uri-Path: "cuid=f30d281ce6b64fc5a0b91e"
  Uri-Path: "mid=12"

• Figure 12 shows the example of a GET request to retrieve all DOTS mitigation requests signaled by a DOTS client.
• Figure 13 shows the example of a GET request to retrieve a specific DOTS mitigation request signaled by a DOTS client. The configuration data to be reported in the response is formatted in the same order as it was processed by the DOTS server in the original mitigation request.

  Header: GET (Code=0.01)
  Uri-Path: ".well-known"
  Uri-Path: "dots"
  Uri-Path: "mitigate"
  Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
  Observe: 0

  Header: GET (Code=0.01)
  Uri-Path: ".well-known"
  Uri-Path: "dots"
  Uri-Path: "mitigate"
  Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
  Uri-Path: "mid=12332"
  Observe: 0

{
  "ietf-dots-signal-channel:mitigation-scope": {
    "scope": [
      {
        "mid": 12332,
        "mitigation-start": "1507818434",
        "target-prefix": [
             "2001:db8:6401::1/128",
             "2001:db8:6401::2/128"
        ],
        "target-protocol": [
          17
        ],
        "lifetime": 1756,
        "status": "attack-successfully-mitigated",
        "bytes-dropped": "134334555",
        "bps-dropped": "43344",
        "pkts-dropped": "333334444",
        "pps-dropped": "432432"
      },
      {
        "mid": 12333,
        "mitigation-start": "1507818393",
        "target-prefix": [
             "2001:db8:6401::1/128",
             "2001:db8:6401::2/128"
        ],
        "target-protocol": [
          6
        ],
        "lifetime": 1755,
        "status": "attack-stopped",
        "bytes-dropped": "0",
        "bps-dropped": "0",
        "pkts-dropped": "0",
        "pps-dropped": "0"
      }
    ]
  }
}

mitigation-start:

Mitigation start time is expressed in seconds relative to 1970-01-01T00:00Z in UTC time (Section 3.4.1 of RFC 8949). The CBOR encoding is modified so that the leading tag 1 (epoch-based date/time) MUST be omitted.

This is a mandatory attribute when an attack mitigation is active. Particularly, 'mitigation-start' is not returned for a mitigation with 'status' code set to 8.

lifetime:

The remaining lifetime of the mitigation request, in seconds.

This is a mandatory attribute.

status:

Status of attack mitigation. The various possible values of 'status' parameter are explained in Table 3.

This is a mandatory attribute.

bytes-dropped:

The total dropped byte count for the mitigation request since the attack mitigation was triggered. The count wraps around when it reaches the maximum value of unsigned integer64.

This is an optional attribute.

bps-dropped:

The average number of dropped bytes per second for the mitigation request since the attack mitigation was triggered. This average SHOULD be over five-minute intervals (that is, measuring bytes into five-minute buckets and then averaging these buckets over the time since the mitigation was triggered).

This is an optional attribute.

pkts-dropped:

The total number of dropped packet count for the mitigation request since the attack mitigation was triggered. The count wraps around when it reaches the maximum value of unsigned integer64.

This is an optional attribute.

pps-dropped:

The average number of dropped packets per second for the mitigation request since the attack mitigation was triggered. This average SHOULD be over five-minute intervals (that is, measuring packets into five-minute buckets and then averaging these buckets over the time since the mitigation was triggered).

This is an optional attribute.

• A notification message with 'status' code set to '7 (Attack mitigation is withdrawn)' and 'conflict-status' set to '1' is sent to a DOTS client to indicate that an active mitigation request is deactivated because a conflict is detected.
• A notification message with 'status' code set to '1 (Attack mitigation is in progress)' and 'conflict-status' set to '2' is sent to a DOTS client to indicate that this mitigation request is in progress, but a conflict is detected.

+-----------+                              +-----------+
|DOTS Client|                              |DOTS Server|
+-----------+                              +-----------+
      |                                          |
      |  GET /<mid>                              |
      |  Token: 0x4a                             | Registration
      |  Observe: 0                              |
      +----------------------------------------->|
      |                                          |
      |  2.05 Content                            |
      |  Token: 0x4a                             | Notification of
      |  Observe: 12                             | the current state
      |  status: "attack-mitigation-in-progress" |
      |<-----------------------------------------+
      |                                          |
      |  2.05 Content                            |
      |  Token: 0x4a                             | Notification upon
      |  Observe: 44                             | a state change
      |  status: "attack-successfully-mitigated" |
      |<-----------------------------------------+
      |                                          |
      |  2.05 Content                            |
      |  Token: 0x4a                             | Notification upon
      |  Observe: 60                             | a state change
      |  status: "attack-stopped"                |
      |<-----------------------------------------+
      |                                          |
                         ...

1. Heartbeat interval ('heartbeat-interval'): DOTS agents regularly send heartbeats to each other after mutual authentication is successfully completed in order to keep the DOTS signal channel open. Heartbeat messages are exchanged between DOTS agents every 'heartbeat-interval' seconds to detect the current status of the DOTS signal channel session.
2. Missing heartbeats allowed ('missing-hb-allowed'): This variable indicates the maximum number of consecutive heartbeat messages for which a DOTS agent did not receive a response before concluding that the session is disconnected or defunct.
3. Acceptable probing rate ('probing-rate'): This parameter indicates the average data rate that must not be exceeded by a DOTS agent in sending to a peer DOTS agent that does not respond.
4. Acceptable signal loss ratio: Maximum retransmissions ('max-retransmit'), retransmission timeout value ('ack-timeout'), and other message transmission parameters for Confirmable messages over the DOTS signal channel.

  Header: GET (Code=0.01)
  Uri-Path: ".well-known"
  Uri-Path: "dots"
  Uri-Path: "config"

{
  "ietf-dots-signal-channel:signal-config": {
    "mitigating-config": {
      "heartbeat-interval": {
        "max-value": number,
        "min-value": number,
        "current-value": number
      },
      "missing-hb-allowed": {
        "max-value": number,
        "min-value": number,
        "current-value": number
      },
      "probing-rate": {
        "max-value": number,
        "min-value": number,
        "current-value": number
      },
      "max-retransmit": {
        "max-value": number,
        "min-value": number,
        "current-value": number
      },
      "ack-timeout": {
        "max-value-decimal": "string",
        "min-value-decimal": "string",
        "current-value-decimal": "string"
      },
      "ack-random-factor": {
        "max-value-decimal": "string",
        "min-value-decimal": "string",
        "current-value-decimal": "string"
      }
    },
    "idle-config": {
      "heartbeat-interval": {
        "max-value": number,
        "min-value": number,
        "current-value": number
      },
      "missing-hb-allowed": {
        "max-value": number,
        "min-value": number,
        "current-value": number
      },
      "probing-rate": {
        "max-value": number,
        "min-value": number,
        "current-value": number
      },
      "max-retransmit": {
        "max-value": number,
        "min-value": number,
        "current-value": number
      },
      "ack-timeout": {
        "max-value-decimal": "string",
        "min-value-decimal": "string",
        "current-value-decimal": "string"
      },
      "ack-random-factor": {
        "max-value-decimal": "string",
        "min-value-decimal": "string",
        "current-value-decimal": "string"
      }
    }
  }
}

mitigating-config:

Set of configuration parameters to use when a mitigation is active. The following parameters may be included:

heartbeat-interval:

Time interval in seconds between two consecutive heartbeat messages.

'0' is used to disable the heartbeat mechanism.

This is an optional attribute.

missing-hb-allowed:

Maximum number of consecutive heartbeat messages for which the DOTS agent did not receive a response before concluding that the session is disconnected.

This is an optional attribute.

probing-rate:

The average data rate, in bytes/second, that must not be exceeded by a DOTS agent in sending to a peer DOTS agent that does not respond (referred to as PROBING_RATE parameter in CoAP).

This is an optional attribute.

max-retransmit:

Maximum number of retransmissions for a message (referred to as MAX_RETRANSMIT parameter in CoAP).

This is an optional attribute.

ack-timeout:

Timeout value in seconds used to calculate the initial retransmission timeout value (referred to as ACK_TIMEOUT parameter in CoAP).

This is an optional attribute.

ack-random-factor:

Random factor used to influence the timing of retransmissions (referred to as ACK_RANDOM_FACTOR parameter in CoAP).

This is an optional attribute.

idle-config:

Set of configuration parameters to use when no mitigation is active. This attribute has the same structure as 'mitigating-config'.

{
  "ietf-dots-signal-channel:signal-config": {
    "mitigating-config": {
      "heartbeat-interval": {
        "max-value": 240,
        "min-value": 15,
        "current-value": 30
      },
      "missing-hb-allowed": {
        "max-value": 20,
        "min-value": 3,
        "current-value": 15
      },
      "probing-rate": {
        "max-value": 20,
        "min-value": 5,
        "current-value": 15
      },
      "max-retransmit": {
        "max-value": 15,
        "min-value": 2,
        "current-value": 3
      },
      "ack-timeout": {
        "max-value-decimal": "30.00",
        "min-value-decimal": "1.00",
        "current-value-decimal": "2.00"
      },
      "ack-random-factor": {
        "max-value-decimal": "4.00",
        "min-value-decimal": "1.10",
        "current-value-decimal": "1.50"
      }
    },
    "idle-config": {
      "heartbeat-interval": {
        "max-value": 240,
        "min-value": 15,
        "current-value": 30
      },
      "missing-hb-allowed": {
        "max-value": 20,
        "min-value": 3,
        "current-value": 15
      },
      "probing-rate": {
        "max-value": 20,
        "min-value": 5,
        "current-value": 15
      },
      "max-retransmit": {
        "max-value": 15,
        "min-value": 2,
        "current-value": 3
      },
      "ack-timeout": {
        "max-value-decimal": "30.00",
        "min-value-decimal": "1.00",
        "current-value-decimal": "2.00"
      },
      "ack-random-factor": {
        "max-value-decimal": "4.00",
        "min-value-decimal": "1.10",
        "current-value-decimal": "1.50"
      }
    }
  }
}

  Header: PUT (Code=0.03)
  Uri-Path: ".well-known"
  Uri-Path: "dots"
  Uri-Path: "config"
  Uri-Path: "sid=123"
  Content-Format: "application/dots+cbor"

  {
   ...
  }

sid:

Session Identifier is an identifier for the DOTS signal channel session configuration data represented as an integer. This identifier MUST be generated by DOTS clients. 'sid' values MUST increase monotonically (when a new PUT is generated by a DOTS client to convey the configuration parameters for the signal channel).

This is a mandatory attribute.

  {
    "ietf-dots-signal-channel:signal-config": {
      "mitigating-config": {
        "heartbeat-interval": {
          "current-value": number
        },
        "missing-hb-allowed": {
          "current-value": number
        },
        "probing-rate": {
          "current-value": number
        },
        "max-retransmit": {
          "current-value": number
        },
        "ack-timeout": {
          "current-value-decimal": "string"
        },
        "ack-random-factor": {
          "current-value-decimal": "string"
        }
      },
      "idle-config": {
        "heartbeat-interval": {
          "current-value": number
        },
        "missing-hb-allowed": {
          "current-value": number
        },
        "probing-rate": {
          "current-value": number
        },
        "max-retransmit": {
          "current-value": number
        },
        "ack-timeout": {
          "current-value-decimal": "string"
        },
        "ack-random-factor": {
          "current-value-decimal": "string"
        }
      }
    }
  }

  Header: PUT (Code=0.03)
  Uri-Path: ".well-known"
  Uri-Path: "dots"
  Uri-Path: "config"
  Uri-Path: "sid=123"
  Content-Format: "application/dots+cbor"

  {
    "ietf-dots-signal-channel:signal-config": {
      "mitigating-config": {
        "heartbeat-interval": {
          "current-value": 30
        },
        "missing-hb-allowed": {
          "current-value": 15
        },
        "probing-rate": {
          "current-value": 15
        },
        "max-retransmit": {
          "current-value": 3
        },
        "ack-timeout": {
          "current-value-decimal": "2.00"
        },
        "ack-random-factor": {
          "current-value-decimal": "1.50"
        }
      },
      "idle-config": {
        "heartbeat-interval": {
          "current-value": 0
        },
        "max-retransmit": {
          "current-value": 3
        },
        "ack-timeout": {
          "current-value-decimal": "2.00"
        },
        "ack-random-factor": {
          "current-value-decimal": "1.50"
        }
      }
    }
  }

• If the request is missing a mandatory attribute, does not include a 'sid' Uri-Path, or contains one or more invalid or unknown parameters, 4.00 (Bad Request) MUST be returned in the response.
• If the DOTS server does not find the 'sid' parameter value conveyed in the PUT request in its configuration data and if the DOTS server has accepted the configuration parameters, then a Response Code 2.01 (Created) MUST be returned in the response.
• If the DOTS server finds the 'sid' parameter value conveyed in the PUT request in its configuration data and if the DOTS server has accepted the updated configuration parameters, 2.04 (Changed) MUST be returned in the response.
• If any of the 'heartbeat-interval', 'missing-hb-allowed', 'probing-rate', 'max-retransmit', 'target-protocol', 'ack-timeout', and 'ack-random-factor' attribute values are not acceptable to the DOTS server, 4.22 (Unprocessable Entity) MUST be returned in the response. Upon receipt of this error code, the DOTS client SHOULD retrieve the maximum and minimum attribute values acceptable to the DOTS server (Section 4.5.1). The DOTS client may retry and send the PUT request with updated attribute values acceptable to the DOTS server.

{
  "ietf-dots-signal-channel:redirected-signal": {
    "alt-server": "string",
    "alt-server-record": [
       "string"
    ]
  }
}

alt-server:

FQDN of an alternate DOTS server.

This is a mandatory attribute.

alt-server-record:

A list of IP addresses of an alternate DOTS server.

This is an optional attribute.

{
  "ietf-dots-signal-channel:redirected-signal": {
    "alt-server": "alt-server.example",
    "alt-server-record": [
       "2001:db8:6401::1",
       "2001:db8:6401::2"
    ]
  }
}

• DTLS record replay detection (Section 3.3 of RFC 6347) or an equivalent mechanism to protect against replay attacks.
• DTLS session resumption without server-side state to resume session and convey the DOTS signal.
• At least one of raw public keys [RFC 7250] or PSK handshake [RFC 4279] with (EC)DHE key exchange. This reduces the size of the ServerHello. Also, this can be used by DOTS agents that cannot obtain certificates.

• TLS False Start [RFC 7918], which reduces round trips by allowing the TLS client's second flight of messages (ChangeCipherSpec) to also contain the DOTS signal. TLS False Start is formally defined for use with TLS, but the same technique is applicable to DTLS as well.
• Cached Information Extension [RFC 7924], which avoids transmitting the server's certificate and certificate chain if the client has cached that information from a previous TLS handshake.

• A full handshake mode in which a DOTS client can send a DOTS mitigation request message after one round trip and the DOTS server immediately responds with a DOTS mitigation response. This assumes no packet loss is experienced.
• 0-RTT mode in which the DOTS client can authenticate itself and send DOTS mitigation request messages in the first message, thus reducing handshake latency. 0-RTT only works if the DOTS client has previously communicated with that DOTS server, which is very likely with the DOTS signal channel.

    DOTS Client                                    DOTS Server

    ClientHello
    (0-RTT DOTS signal message)
                              -------->
                                                    ServerHello
                                          {EncryptedExtensions}
                                                     {Finished}
                              <--------   [DOTS signal message]
    (end_of_early_data)       
    {Finished}                --------> 
    [DOTS signal message]     <------->   [DOTS signal message]

Note that:
    () Indicates messages protected 0-RTT keys
    {} Indicates messages protected using handshake keys
    [] Indicates messages protected using 1-RTT keys

4.00 (Bad Request)

is returned by the DOTS server when the DOTS client has sent a request that violates the DOTS protocol (Section 4).

4.01 (Unauthorized)

is returned by the DOTS server when the DOTS client is not authorized to access the DOTS server (Section 4).

4.02 (Bad Option)

is returned by the DOTS server when one or more CoAP options are unknown or malformed by the CoAP layer [RFC 7252].

4.04 (Not Found)

is returned by the DOTS server when the DOTS client is requesting a 'mid' or 'sid' that is not valid (Section 4).

4.05 (Method Not Allowed)

is returned by the DOTS server when the DOTS client is requesting a resource by a method (e.g., GET) that is not supported by the DOTS server [RFC 7252].

4.08 (Request Entity Incomplete)

is returned by the DOTS server if one or multiple blocks of a block transfer request is missing [RFC 7959].

4.09 (Conflict)

is returned by the DOTS server if the DOTS server detects that a request conflicts with a previous request. The response body is formatted using "application/dots+cbor" and contains the "conflict-clause" (Section 4.4.1.3).

4.13 (Request Entity Too Large)

may be returned by the DOTS server during a block transfer request [RFC 7959].

4.15 (Unsupported Content-Format)

is returned by the DOTS server when the Content-Format is used but the request is not formatted as "application/dots+cbor" (Section 4).

4.22 (Unprocessable Entity)

is returned by the DOTS server when one or more session configuration parameters are not valid (Section 4.5).

5.03 (Service Unavailable)

is returned by the DOTS server if the DOTS server is unable to handle the request (Section 4). An example is the DOTS server needs to redirect the DOTS client to use an alternate DOTS server (Section 4.6). The response body is formatted using "application/dots+cbor" and contains how to handle the 5.03 Response Code.

5.08 (Hop Limit Reached)

is returned by the DOTS server if there is a data path loop through upstream DOTS gateways. The response body is formatted using plain text and contains a list of servers that are in the data path loop [RFC 8768].

Service Name:

dots-signal

Port Number:

4646

Transport Protocol:

TCP

Description:

Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Protocol. The service name is used to construct the SRV service names "_dots-signal._udp" and "_dots-signal._tcp" for discovering DOTS servers used to establish DOTS signal channel.

Assignee:

IESG

Contact:

IETF Chair

Registration Date:

2020-01-16

Reference:

[RFC8973][RFC9132]

Service Name:

dots-signal

Port Number:

4646

Transport Protocol:

UDP

Description:

Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Protocol. The service name is used to construct the SRV service names "_dots-signal._udp" and "_dots-signal._tcp" for discovering DOTS servers used to establish DOTS signal channel.

Assignee:

IESG

Contact:

IETF Chair

Registration Date:

2020-01-16

Reference:

[RFC8973][RFC9132]

Type name:

application

Subtype name:

dots+cbor

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

binary

Security considerations:

See the Security Considerations section of RFC 9132.

Interoperability considerations:

N/A

Published specification:

RFC 9132

Applications that use this media type:

DOTS agents sending DOTS messages over CoAP over (D)TLS.

Fragment identifier considerations:

N/A

Additional information:

Deprecated alias names for this type:

N/A

Magic number(s):

N/A

File extension(s):

N/A

Macintosh file type code(s):

N/A

Person & email address to contact for further information:

IESG, iesg@ietf.org

Intended usage:

COMMON

Restrictions on usage:

none

Author:

See Authors' Addresses section.

Change controller:

IESG

Provisional registration?

No

Media Type:

application/dots+cbor

Encoding:

-

ID:

271

Reference:

[RFC9132]

Tag:

271

Data Item:

DDoS Open Threat Signaling (DOTS) signal channel object

Semantics:

DDoS Open Threat Signaling (DOTS) signal channel object, as defined in [RFC9132]

Reference:

[RFC9132]

Parameter name:

Parameter name, as used in the DOTS signal channel.

CBOR Key Value:

Key value for the parameter. The key value MUST be an integer in the 1-65535 range.

OLD:

Range	Registration Procedures	Note
1-16383	IETF Review	comprehension-required
16384-32767	Specification Required	comprehension-optional
32768-49151	IETF Review	comprehension-optional
49152-65535	Private Use	comprehension-optional

Table 7

NEW:

Range	Registration Procedures	Note
1-127	IETF Review	comprehension-required
128-255	IETF Review	comprehension-optional
256-16383	IETF Review	comprehension-required
16384-32767	Specification Required	comprehension-optional
32768-49151	IETF Review	comprehension-optional
49152-65535	Private Use	comprehension-optional

Table 8

Registration requests for the 16384-32767 range are evaluated after a three-week review period on the dots-signal-reg-review@ietf.org mailing list, on the advice of one or more designated experts. However, to allow for the allocation of values prior to publication, the designated experts may approve registration once they are satisfied that such a specification will be published. New registration requests should be sent in the form of an email to the review mailing list; the request should use an appropriate subject (e.g., "Request to register CBOR Key Value for DOTS: example"). IANA will only accept new registrations from the designated experts, and it will check that review was requested on the mailing list in accordance with these procedures.

Within the review period, the designated experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution.

Criteria that should be applied by the designated experts include determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or whether it is useful only for a single use case, and whether the registration description is clear. IANA must only accept registry updates to the 16384-32767 range from the designated experts and should direct all requests for registration to the review mailing list. It is suggested that multiple designated experts be appointed. In cases where a registration decision could be perceived as creating a conflict of interest for a particular expert, that expert should defer to the judgment of the other experts.

CBOR Major Type:

CBOR Major type and optional tag for the parameter.

Change Controller:

For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., email address) may also be included.

Specification Document(s):

Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.

URI:

urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel

Registrant Contact:

The IESG.

XML:

N/A; the requested URI is an XML namespace.

URI:

urn:ietf:params:xml:ns:yang:iana-dots-signal-channel

Registrant Contact:

IANA.

XML:

N/A; the requested URI is an XML namespace.

Name:

iana-dots-signal-channel

Maintained by IANA:

Y

Namespace:

urn:ietf:params:xml:ns:yang:iana-dots-signal-channel

Prefix:

iana-dots-signal

Reference:

[RFC9132]

Name:

ietf-dots-signal-channel

Maintained by IANA:

N

Namespace:

urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel

Prefix:

dots-signal

Reference:

[RFC9132]

"enum":

Replicates the label from the registry.

"value":

Contains the IANA-assigned value corresponding to the 'status', 'conflict-status', 'conflict-cause', or 'attack-status'.

"description":

Replicates the description from the registry.

"reference":

Replicates the reference from the registry and adds the title of the document.

[RFC0791]

J. Postel, "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.

[RFC1122]

R. Braden, "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.

[RFC2119]

S. Bradner, "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]

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

[RFC3986]

T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.

[RFC4279]

P. Eronen, and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005,
<https://www.rfc-editor.org/info/rfc4279>.

[RFC4632]

V. Fuller, and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006,
<https://www.rfc-editor.org/info/rfc4632>.

[RFC4648]

S. Josefsson, "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.

[RFC5246]

T. Dierks, and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.

[RFC5280]

D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.

[RFC6020]

M. Bjorklund, "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>.

[RFC6066]

D. Eastlake 3rd, "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.

[RFC6125]

P. Saint-Andre, and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011,
<https://www.rfc-editor.org/info/rfc6125>.

[RFC6347]

E. Rescorla, 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]

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

[RFC7250]

P. Wouters, H. Tschofenig, J. Gilmore, S. Weiler, and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014,
<https://www.rfc-editor.org/info/rfc7250>.

[RFC7252]

Z. Shelby, K. Hartke, and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.

[RFC7525]

Y. Sheffer, R. Holz, and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015,
<https://www.rfc-editor.org/info/rfc7525>.

[RFC7641]

K. Hartke, "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>.

[RFC7918]

A. Langley, N. Modadugu, and B. Moeller, "Transport Layer Security (TLS) False Start", RFC 7918, DOI 10.17487/RFC7918, August 2016,
<https://www.rfc-editor.org/info/rfc7918>.

[RFC7924]

S. Santesson, and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016,
<https://www.rfc-editor.org/info/rfc7924>.

[RFC7950]

M. Bjorklund, "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.

[RFC7959]

C. Bormann, and Z. Shelby, "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/info/rfc7959>.

[RFC8085]

L. Eggert, G. Fairhurst, and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017,
<https://www.rfc-editor.org/info/rfc8085>.

[RFC8126]

M. Cotton, B. Leiba, and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

[RFC8174]

B. Leiba, "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>.

[RFC8200]

S. Deering, and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.

[RFC8305]

D. Schinazi, and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.

[RFC8323]

C. Bormann, S. Lemay, H. Tschofenig, K. Hartke, B. Silverajan, and B. Raymor, "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>.

[RFC8446]

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

[RFC8615]

M. Nottingham, "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.

[RFC8768]

M. Boucadair, T. Reddy.K, and J. Shallow, "Constrained Application Protocol (CoAP) Hop-Limit Option", RFC 8768, DOI 10.17487/RFC8768, March 2020,
<https://www.rfc-editor.org/info/rfc8768>.

[RFC8783]

M. Boucadair, and T. Reddy.K, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification", RFC 8783, DOI 10.17487/RFC8783, May 2020,
<https://www.rfc-editor.org/info/rfc8783>.

[RFC8791]

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

[RFC8949]

C. Bormann, and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.

[CORE-COMI]

M Veillette, P Stok, A Pelov, A Bierman, and I Petrov, "CoAP Management Interface (CORECONF)", Internet-Draft draft-ietf-core-comi-11, January 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-11>.

[CORE-YANG-CBOR]

M Veillette, I Petrov, and A Pelov, "CBOR Encoding of Data Modeled with YANG", Internet-Draft draft-ietf-core-yang-cbor-16, January 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-cbor-16>.

[DOTS-EARLYDATA]

McAfee, Inc., M. Boucadair, and T. Reddy.K, "Using Early Data in DOTS", Internet-Draft draft-boucadair-dots-earlydata-00, January 2019,
<https://datatracker.ietf.org/doc/html/draft-boucadair-dots-earlydata-00>.

[DOTS-MULTIHOMING]

Huawei Technologies, M. Boucadair, T. Reddy.K, and W. Pan, "Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS)", Internet-Draft draft-ietf-dots-multihoming-07, July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-dots-multihoming-07>.

[DOTS-TELEMETRY]

M Boucadair, T Reddy.K, E Doron, M Chen, and J Shallow, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry", Internet-Draft draft-ietf-dots-telemetry-16, December 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-16>.

[IANA-CBOR-Tags]

IANA, "Concise Binary Object Representation (CBOR) Tags",
<https://www.iana.org/assignments/cbor-tags>.

[IANA-CoAP-Content-Formats]

IANA, "CoAP Content-Formats",
<https://www.iana.org/assignments/core-parameters>.

[IANA-MediaTypes]

IANA, "Media Types",
<https://www.iana.org/assignments/media-types>.

[IANA-Proto]

IANA, "Protocol Numbers",
<https://www.iana.org/assignments/protocol-numbers>.

[REG-DOTS]

IANA, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel",
<https://www.iana.org/assignments/dots>.

[RFC3022]

P. Srisuresh, and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001,
<https://www.rfc-editor.org/info/rfc3022>.

[RFC4034]

R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.

[RFC4122]

P. Leach, M. Mealling, and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>.

[RFC4340]

E. Kohler, M. Handley, and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>.

[RFC4732]

IAB, M. Handley, and E. Rescorla, "Internet Denial-of-Service Considerations", RFC 4732, DOI 10.17487/RFC4732, December 2006,
<https://www.rfc-editor.org/info/rfc4732>.

[RFC4787]

F. Audet, and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007,
<https://www.rfc-editor.org/info/rfc4787>.

[RFC4960]

R. Stewart, "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.

[RFC4987]

W. Eddy, "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
<https://www.rfc-editor.org/info/rfc4987>.

[RFC5925]

J. Touch, A. Mankin, and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010,
<https://www.rfc-editor.org/info/rfc5925>.

[RFC6052]

C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, 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]

M. Bagnulo, P. Matthews, 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>.

[RFC6234]

D. Eastlake 3rd, and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.

[RFC6296]

M. Wasserman, and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
<https://www.rfc-editor.org/info/rfc6296>.

[RFC6724]

D. Thaler, R. Draves, A. Matsumoto, and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.

[RFC6838]

N. Freed, J. Klensin, and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.

[RFC6887]

D. Wing, S. Cheshire, M. Boucadair, R. Penno, and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013,
<https://www.rfc-editor.org/info/rfc6887>.

[RFC6888]

S. Perreault, I. Yamagata, S. Miyakawa, A. Nakagawa, and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013,
<https://www.rfc-editor.org/info/rfc6888>.

[RFC7030]

M. Pritikin, P. Yee, and D. Harkins, "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>.

[RFC7413]

Y. Cheng, J. Chu, S. Radhakrishnan, and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>.

[RFC7452]

H. Tschofenig, J. Arkko, D. Thaler, and D. McPherson, "Architectural Considerations in Smart Object Networking", RFC 7452, DOI 10.17487/RFC7452, March 2015,
<https://www.rfc-editor.org/info/rfc7452>.

[RFC7589]

M. Badra, A. Luchuk, and J. Schoenwaelder, "Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication", RFC 7589, DOI 10.17487/RFC7589, June 2015,
<https://www.rfc-editor.org/info/rfc7589>.

[RFC7858]

Z. Hu, L. Zhu, J. Heidemann, A. Mankin, D. Wessels, and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016,
<https://www.rfc-editor.org/info/rfc7858>.

[RFC7951]

L. Lhotka, "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>.

[RFC8340]

M. Bjorklund, and L. Berger, "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.

[RFC8484]

P. Hoffman, and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.

[RFC8489]

M. Petit-Huguenin, G. Salgueiro, J. Rosenberg, D. Wing, R. Mahy, and P. Matthews, "Session Traversal Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489, February 2020,
<https://www.rfc-editor.org/info/rfc8489>.

[RFC8499]

P. Hoffman, A. Sullivan, and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019,
<https://www.rfc-editor.org/info/rfc8499>.

[RFC8612]

A. Mortensen, T. Reddy, and R. Moskowitz, "DDoS Open Threat Signaling (DOTS) Requirements", RFC 8612, DOI 10.17487/RFC8612, May 2019,
<https://www.rfc-editor.org/info/rfc8612>.

[RFC8782]

T. Reddy.K, M. Boucadair, P. Patil, A. Mortensen, and N. Teague, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020,
<https://www.rfc-editor.org/info/rfc8782>.

[RFC8811]

A. Mortensen, T. Reddy.K, F. Andreasen, N. Teague, and R. Compton, "DDoS Open Threat Signaling (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, August 2020,
<https://www.rfc-editor.org/info/rfc8811>.

[RFC8903]

R. Dobbins, D. Migault, R. Moskowitz, N. Teague, L. Xia, and K. Nishizuka, "Use Cases for DDoS Open Threat Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021,
<https://www.rfc-editor.org/info/rfc8903>.

[RFC8973]

M. Boucadair, and T. Reddy.K, "DDoS Open Threat Signaling (DOTS) Agent Discovery", RFC 8973, DOI 10.17487/RFC8973, January 2021,
<https://www.rfc-editor.org/info/rfc8973>.

[TLS-DTLS13]

Google, Inc., E. Rescorla, H. Tschofenig, and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Internet-Draft draft-ietf-tls-dtls13-43, April 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-43>.

[URI]

IANA, "Well-Known URIs",
<https://www.iana.org/assignments/well-known-uris>.

• Update the "ietf-dots-signal-channel" YANG module (Section 5.3) and the tree structure (Section 5.1) to follow the new YANG data structure specified in [RFC 8791]. In particular:
  • Add in 'choice' to indicate the communication direction in which a data node applies. If no 'choice' is indicated, a data node can appear in both directions (i.e., from DOTS clients to DOTS servers and vice versa).
  • Remove 'config' clauses. Note that 'config' statements will be ignored (if present) anyway, according to Section 4 of RFC 8791. This supersedes the references to the use of 'ro' and 'rw', which are now covered by 'choice' above.
  • Remove 'cuid', 'cdid', and 'sid' data nodes from the structure because these data nodes are included as Uri-Path options, not within the message body.
  • Remove the list keys for the mitigation scope message type (i.e., 'cuid' and 'mid'). 'mid' is not indicated as a key because it is included as a Uri-Path option for requests and in the message body for responses. Note that Section 4 of RFC 8791 specifies that a list does not require to have a key statement defined.
• Add a new section with a summary of the error code responses that can be returned by a DOTS server (Section 9).
• Update the IANA section to allocate a new range for comprehension-optional attributes (Section 10.6.1.1). This modification is motivated by the need to allow for compact DOTS signal messages that include a long list of comprehension-optional attributes, e.g., DOTS telemetry messages [DOTS-TELEMETRY].
• Add Appendix C to list recommended/default values of key DOTS signal channel parameters.
• Add subsections to Section 4.4.1 for better readability.

• SPKI is globally unique.
• It is deterministic.
• It allows the avoidance of extra cycles that may be induced by 'cuid' collision.
• DOTS clients do not need to store the 'cuid' in a persistent storage.
• It allows the detection of compromised DOTS clients that do not adhere to the 'cuid' generation algorithm.

Tirumaleswar Reddy.K (editor)

Mohamed Boucadair (editor)

Prashanth Patil

Andrew Mortensen

Nik Teague

Jon Shallow

Mike Geller

Robert Moskowitz

Mohamed Boucadair

Jon Shallow

Tirumaleswar Reddy.K