Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification
RFC 8782
| Document | Type |
RFC
- Proposed Standard
(May 2020)
Errata
Obsoleted by RFC 9132
|
|
|---|---|---|---|
| Authors | Tirumaleswar Reddy.K , Mohamed Boucadair , Prashanth Patil , Andrew Mortensen , Nik Teague | ||
| Last updated | 2021-03-04 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Benjamin Kaduk | |
| Send notices to | (None) |
RFC 8782
quot;. 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.
9.6.1.2. Initial Subregistry Content
+---------------------+------------+-----+----------+---------------+
| Parameter Name | CBOR Key |CBOR | Change | Specification |
| | Value |Major|Controller| Document(s) |
| | |Type | | |
+=====================+============+=====+==========+===============+
| Reserved | 0 | | | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| ietf-dots-signal- | 1 | 5 | IESG | [RFC8782] |
| channel:mitigation- | | | | |
| scope | | | | |
+---------------------+------------+-----+----------+---------------+
| scope | 2 | 4 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| cdid | 3 | 3 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| cuid | 4 | 3 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| mid | 5 | 0 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| target-prefix | 6 | 4 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| target-port-range | 7 | 4 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| lower-port | 8 | 0 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| upper-port | 9 | 0 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| target-protocol | 10 | 4 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| target-fqdn | 11 | 4 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| target-uri | 12 | 4 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| alias-name | 13 | 4 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| lifetime | 14 | 0/1 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| mitigation-start | 15 | 0 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| status | 16 | 0 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
|conflict-information | 17 | 5 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| conflict-status | 18 | 0 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| conflict-cause | 19 | 0 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| retry-timer | 20 | 0 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| conflict-scope | 21 | 5 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| acl-list | 22 | 4 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| acl-name | 23 | 3 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| acl-type | 24 | 3 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| bytes-dropped | 25 | 0 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| bps-dropped | 26 | 0 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| pkts-dropped | 27 | 0 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| pps-dropped | 28 | 0 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| attack-status | 29 | 0 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| ietf-dots-signal- | 30 | 5 | IESG | [RFC8782] |
|channel:signal-config| | | | |
+---------------------+------------+-----+----------+---------------+
| sid | 31 | 0 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| mitigating-config | 32 | 5 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| heartbeat-interval | 33 | 5 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| min-value | 34 | 0 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| max-value | 35 | 0 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| current-value | 36 | 0 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| missing-hb-allowed | 37 | 5 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| max-retransmit | 38 | 5 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| ack-timeout | 39 | 5 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| ack-random-factor | 40 | 5 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| min-value-decimal | 41 |6tag4| IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| max-value-decimal | 42 |6tag4| IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
|current-value-decimal| 43 |6tag4| IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| idle-config | 44 | 5 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| trigger-mitigation | 45 | 7 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| ietf-dots-signal- | 46 | 5 | IESG | [RFC8782] |
| channel:redirected- | | | | |
| signal | | | | |
+---------------------+------------+-----+----------+---------------+
| alt-server | 47 | 3 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| alt-server-record | 48 | 4 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| ietf-dots-signal- | 49 | 5 | IESG | [RFC8782] |
| channel:heartbeat | | | | |
+---------------------+------------+-----+----------+---------------+
| probing-rate | 50 | 5 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| peer-hb-status | 51 | 7 | IESG | [RFC8782] |
+---------------------+------------+-----+----------+---------------+
| Unassigned | 52-49151 | | | |
+---------------------+------------+-----+----------+---------------+
|Reserved for Private |49152-65535 | | | [RFC8782] |
| Use | | | | |
+---------------------+------------+-----+----------+---------------+
Table 7: Initial DOTS Signal Channel CBOR Key Values Registry
9.6.2. Status Codes Subregistry
IANA has created a new subregistry titled "DOTS Signal Channel Status
Codes". Codes in this registry are used as valid values of 'status'
parameter.
The registry is initially populated with the following values:
+--------------+---------------+----------------------+-----------+
| Code | Label | Description | Reference |
+==============+===============+======================+===========+
| 0 | Reserved | | [RFC8782] |
+--------------+---------------+----------------------+-----------+
| 1 | attack- | Attack mitigation | [RFC8782] |
| | mitigation- | setup is in progress | |
| | in-progress | (e.g., changing the | |
| | | network path to | |
| | | redirect the inbound | |
| | | traffic to a DOTS | |
| | | mitigator). | |
+--------------+---------------+----------------------+-----------+
| 2 | attack- | Attack is being | [RFC8782] |
| | successfully- | successfully | |
| | mitigated | mitigated (e.g., | |
| | | traffic is | |
| | | redirected to a DDoS | |
| | | mitigator and attack | |
| | | traffic is dropped). | |
+--------------+---------------+----------------------+-----------+
| 3 | attack- | Attack has stopped | [RFC8782] |
| | stopped | and the DOTS client | |
| | | can withdraw the | |
| | | mitigation request. | |
+--------------+---------------+----------------------+-----------+
| 4 | attack- | Attack has exceeded | [RFC8782] |
| | exceeded- | the mitigation | |
| | capability | provider capability. | |
+--------------+---------------+----------------------+-----------+
| 5 | dots-client- | DOTS client has | [RFC8782] |
| | withdrawn- | withdrawn the | |
| | mitigation | mitigation request | |
| | | and the mitigation | |
| | | is active but | |
| | | terminating. | |
+--------------+---------------+----------------------+-----------+
| 6 | attack- | Attack mitigation is | [RFC8782] |
| | mitigation- | now terminated. | |
| | terminated | | |
+--------------+---------------+----------------------+-----------+
| 7 | attack- | Attack mitigation is | [RFC8782] |
| | mitigation- | withdrawn. | |
| | withdrawn | | |
+--------------+---------------+----------------------+-----------+
| 8 | attack- | Attack mitigation | [RFC8782] |
| | mitigation- | will be triggered | |
| | signal-loss | for the mitigation | |
| | | request only when | |
| | | the DOTS signal | |
| | | channel session is | |
| | | lost. | |
+--------------+---------------+----------------------+-----------+
| 9-2147483647 | Unassigned | | |
+--------------+---------------+----------------------+-----------+
Table 8: Initial DOTS Signal Channel Status Codes
New codes can be assigned via Standards Action [RFC8126].
9.6.3. Conflict Status Codes Subregistry
IANA has created a new subregistry titled "DOTS Signal Channel
Conflict Status Codes". Codes in this registry are used as valid
values of 'conflict-status' parameter.
The registry is initially populated with the following values:
+--------------+-------------------+--------------------+-----------+
| Code | Label | Description | Reference |
+==============+===================+====================+===========+
| 0 | Reserved | | [RFC8782] |
+--------------+-------------------+--------------------+-----------+
| 1 | request-inactive- | DOTS server | [RFC8782] |
| | other-active | 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 | request-active | DOTS server | [RFC8782] |
| | | has detected | |
| | | conflicting | |
| | | mitigation | |
| | | requests from | |
| | | different DOTS | |
| | | clients. This | |
| | | mitigation | |
| | | request is | |
| | | currently | |
| | | active. | |
+--------------+-------------------+--------------------+-----------+
| 3 | all-requests- | DOTS server | [RFC8782] |
| | inactive | has detected | |
| | | conflicting | |
| | | mitigation | |
| | | requests from | |
| | | different DOTS | |
| | | clients. All | |
| | | conflicting | |
| | | mitigation | |
| | | requests are | |
| | | inactive. | |
+--------------+-------------------+--------------------+-----------+
| 4-2147483647 | Unassigned | | |
+--------------+-------------------+--------------------+-----------+
Table 9: Initial DOTS Signal Channel Conflict Status Codes
New codes can be assigned via Standards Action [RFC8126].
9.6.4. Conflict Cause Codes Subregistry
IANA has created a new subregistry titled "DOTS Signal Channel
Conflict Cause Codes". Codes in this registry are used as valid
values of 'conflict-cause' parameter.
The registry is initially populated with the following values:
+--------------+---------------------+----------------+-----------+
| Code | Label | Description | Reference |
+==============+=====================+================+===========+
| 0 | Reserved | | [RFC8782] |
+--------------+---------------------+----------------+-----------+
| 1 | overlapping-targets | Overlapping | [RFC8782] |
| | | targets. | |
+--------------+---------------------+----------------+-----------+
| 2 | conflict-with- | Conflicts with | [RFC8782] |
| | acceptlist | an existing | |
| | | accept-list. | |
| | | This code is | |
| | | returned when | |
| | | the DDoS | |
| | | mitigation | |
| | | detects source | |
| | | addresses/ | |
| | | prefixes in | |
| | | the accept- | |
| | | listed ACLs | |
| | | are attacking | |
| | | the target. | |
+--------------+---------------------+----------------+-----------+
| 3 | cuid-collision | CUID | [RFC8782] |
| | | Collision. | |
| | | This code is | |
| | | returned when | |
| | | a DOTS client | |
| | | uses a 'cuid' | |
| | | that is | |
| | | already used | |
| | | by another | |
| | | DOTS client. | |
+--------------+---------------------+----------------+-----------+
| 4-2147483647 | Unassigned | | |
+--------------+---------------------+----------------+-----------+
Table 10: Initial DOTS Signal Channel Conflict Cause Codes
New codes can be assigned via Standards Action [RFC8126].
9.6.5. Attack Status Codes Subregistry
IANA has created a new subregistry titled "DOTS Signal Channel Attack
Status Codes". Codes in this registry are used as valid values of
'attack-status' parameter.
The registry is initially populated with the following values:
+--------------+----------------------+-----------------+-----------+
| Code | Label | Description | Reference |
+==============+======================+=================+===========+
| 0 | Reserved | | [RFC8782] |
+--------------+----------------------+-----------------+-----------+
| 1 | under-attack | The DOTS | [RFC8782] |
| | | client | |
| | | determines | |
| | | that it is | |
| | | still under | |
| | | attack. | |
+--------------+----------------------+-----------------+-----------+
| 2 | attack-successfully- | The DOTS | [RFC8782] |
| | mitigated | client | |
| | | determines | |
| | | that the | |
| | | attack is | |
| | | successfully | |
| | | mitigated. | |
+--------------+----------------------+-----------------+-----------+
| 3-2147483647 | Unassigned | | |
+--------------+----------------------+-----------------+-----------+
Table 11: Initial DOTS Signal Channel Attack Status Codes
New codes can be assigned via Standards Action [RFC8126].
9.7. DOTS Signal Channel YANG Modules
IANA has registered the following URIs in the "ns" subregistry within
the "IETF XML Registry" [RFC3688]:
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.
IANA has registered the following YANG modules in the "YANG Module
Names" subregistry [RFC7950] within the "YANG Parameters" registry.
Name: ietf-dots-signal-channel
Maintained by IANA: N
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel
Prefix: signal
Reference: RFC8782
Name: iana-dots-signal-channel
Maintained by IANA: Y
Namespace: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel
Prefix: iana-signal
Reference: RFC8782
This document defines the initial version of the IANA-maintained
iana-dots-signal-channel YANG module. IANA has added this note:
Status, conflict status, conflict cause, and attack status values
must not be directly added to the iana-dots-signal-channel YANG
module. They must instead be respectively added to the "DOTS
Status Codes", "DOTS Conflict Status Codes", "DOTS Conflict Cause
Codes", and "DOTS Attack Status Codes" registries.
When a 'status', 'conflict-status', 'conflict-cause', or 'attack-
status' value is respectively added to the "DOTS Status Codes", "DOTS
Conflict Status Codes", "DOTS Conflict Cause Codes", or "DOTS Attack
Status Codes" registry, a new "enum" statement must be added to the
iana-dots-signal-channel YANG module. The following "enum"
statement, and substatements thereof, should be defined:
"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.
When the iana-dots-signal-channel YANG module is updated, a new
"revision" statement must be added in front of the existing revision
statements.
IANA added this note to "DOTS Status Codes", "DOTS Conflict Status
Codes", "DOTS Conflict Cause Codes", and "DOTS Attack Status Codes"
registries:
When this registry is modified, the YANG module iana-dots-signal-
channel must be updated as defined in [RFC8782].
10. Security Considerations
High-level DOTS security considerations are documented in [RFC8612]
and [DOTS-ARCH].
Authenticated encryption MUST be used for data confidentiality and
message integrity. The interaction between the DOTS agents requires
Datagram Transport Layer Security (DTLS) or Transport Layer Security
(TLS) with a cipher suite offering confidentiality protection, and
the guidance given in [RFC7525] MUST be followed to avoid attacks on
(D)TLS. The (D)TLS protocol profile used for the DOTS signal channel
is specified in Section 7.
If TCP is used between DOTS agents, an attacker may be able to inject
RST packets, bogus application segments, etc., regardless of whether
TLS authentication is used. Because the application data is TLS
protected, this will not result in the application receiving bogus
data, but it will constitute a DoS on the connection. This attack
can be countered by using TCP Authentication Option (TCP-AO)
[RFC5925]. Although not widely adopted, if TCP-AO is used, then any
bogus packets injected by an attacker will be rejected by the TCP-AO
integrity check and therefore will never reach the TLS layer.
If the 'cuid' is guessable, a misbehaving DOTS client from within the
client's domain can use the 'cuid' of another DOTS client of the
domain to delete or alter active mitigations. For this attack vector
to happen, the misbehaving client needs to pass the security
validation checks by the DOTS server, and eventually the checks of a
client-domain DOTS gateway.
A similar attack can be achieved by a compromised DOTS client that
can sniff the TLS 1.2 handshake, use the client certificate to
identify the 'cuid' used by another DOTS client. This attack is not
possible if algorithms such as version 4 Universally Unique
IDentifiers (UUIDs) in Section 4.4 of [RFC4122] are used to generate
the 'cuid' because such UUIDs are not a deterministic function of the
client certificate. Likewise, this attack is not possible with TLS
1.3 because most of the TLS handshake is encrypted and the client
certificate is not visible to eavesdroppers.
A compromised DOTS client can collude with a DDoS attacker to send
mitigation request for a target resource, get the mitigation efficacy
from the DOTS server, and convey the mitigation efficacy to the DDoS
attacker to possibly change the DDoS attack strategy. Obviously,
signaling an attack by the compromised DOTS client to the DOTS server
will trigger attack mitigation. This attack can be prevented by
monitoring and auditing DOTS clients to detect misbehavior and to
deter misuse, and by only authorizing the DOTS client to request
mitigation for specific target resources (e.g., an application server
is authorized to request mitigation for its IP addresses, but a DDoS
mitigator can request mitigation for any target resource in the
network). Furthermore, DOTS clients are typically co-located on
network security services (e.g., firewall), and a compromised
security service potentially can do a lot more damage to the network.
Rate-limiting DOTS requests, including those with new 'cuid' values,
from the same DOTS client defend against DoS attacks that would
result in varying the 'cuid' to exhaust DOTS server resources. Rate-
limit policies SHOULD be enforced on DOTS gateways (if deployed) and
DOTS servers.
In order to prevent leaking internal information outside a client's
domain, DOTS gateways located in the client domain SHOULD NOT reveal
the identification information that pertains to internal DOTS clients
(e.g., source IP address, client's hostname) unless explicitly
configured to do so.
DOTS servers MUST verify that requesting DOTS clients are entitled to
trigger actions on a given IP prefix. That is, only actions on IP
resources that belong to the DOTS client's domain MUST be authorized
by a DOTS server. The exact mechanism for the DOTS servers to
validate that the target prefixes are within the scope of the DOTS
client domain is deployment specific.
The presence of DOTS gateways may lead to infinite forwarding loops,
which is undesirable. To prevent and detect such loops, this
document uses the Hop-Limit option.
When FQDNs are used as targets, the DOTS server MUST rely upon DNS
privacy-enabling protocols (e.g., DNS over TLS [RFC7858] or DNS over
HTTPS (DoH) [RFC8484]) to prevent eavesdroppers from possibly
identifying the target resources protected by the DDoS mitigation
service to ensure the target FQDN resolution is authentic (e.g.,
DNSSEC [RFC4034]).
CoAP-specific security considerations are discussed in Section 11 of
[RFC7252], while CBOR-related security considerations are discussed
in Section 8 of [RFC7049].
11. References
11.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., 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] Eronen, P., Ed. and H. Tschofenig, Ed., "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] Fuller, V. 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] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC5246] Dierks, T. 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] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., 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>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. 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] 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>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., 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] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7525] Sheffer, Y., Holz, R., 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] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>.
[RFC7918] Langley, A., Modadugu, N., 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] Santesson, S. 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] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "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] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8126] Cotton, M., Leiba, B., 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] 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>.
[RFC8200] Deering, S. 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] Schinazi, D. 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] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "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] 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>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC8768] Boucadair, M., Reddy.K, T., 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>.
11.2. Informative References
[COMI] Veillette, M., Stok, P., Pelov, A., Bierman, A., and I.
Petrov, "CoAP Management Interface", Work in Progress,
Internet-Draft, draft-ietf-core-comi-09, 9 March 2020,
<https://tools.ietf.org/html/draft-ietf-core-comi-09>.
[CORE-YANG-CBOR]
Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of
Data Modeled with YANG", Work in Progress, Internet-Draft,
draft-ietf-core-yang-cbor-12, 9 March 2020,
<https://tools.ietf.org/html/draft-ietf-core-yang-cbor-
12>.
[DOTS-ARCH]
Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and
R. Compton, "Distributed-Denial-of-Service Open Threat
Signaling (DOTS) Architecture", Work in Progress,
Internet-Draft, draft-ietf-dots-architecture-18, 6 March
2020, <https://tools.ietf.org/html/draft-ietf-dots-
architecture-18>.
[DOTS-EARLYDATA]
Boucadair, M. and T. Reddy.K, "Using Early Data in DOTS",
Work in Progress, Internet-Draft, draft-boucadair-dots-
earlydata-00, 29 January 2019,
<https://tools.ietf.org/html/draft-boucadair-dots-
earlydata-00>.
[DOTS-MH] Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing
Deployment Considerations for Distributed-Denial-of-
Service Open Threat Signaling (DOTS)", Work in Progress,
Internet-Draft, draft-ietf-dots-multihoming-03, 22 January
2020, <https://tools.ietf.org/html/draft-ietf-dots-
multihoming-03>.
[DOTS-SERVER-DISC]
Boucadair, M. and T. Reddy.K, "Distributed-Denial-of-
Service Open Threat Signaling (DOTS) Agent Discovery",
Work in Progress, Internet-Draft, draft-ietf-dots-server-
discovery-10, 7 February 2020,
<https://tools.ietf.org/html/draft-ietf-dots-server-
discovery-10>.
[DOTS-USE-CASES]
Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
L., and K. Nishizuka, "Use cases for DDoS Open Threat
Signaling", Work in Progress, Internet-Draft, draft-ietf-
dots-use-cases-21, 15 May 2020,
<https://tools.ietf.org/html/draft-ietf-dots-use-cases-
21>.
[DTLS] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-37, 9 March 2020,
<https://tools.ietf.org/html/draft-ietf-tls-dtls13-37>.
[IANA-CBOR-Tags]
IANA, "Concise Binary Object Representation (CBOR) Tags",
<http://www.iana.org/assignments/cbor-tags/cbor-
tags.xhtml>.
[IANA-CoAP-Content-Formats]
IANA, "CoAP Content-Formats",
<http://www.iana.org/assignments/core-parameters/core-
parameters.xhtml#content-formats>.
[IANA-MediaTypes]
IANA, "Media Types",
<http://www.iana.org/assignments/media-types>.
[IANA-Proto]
IANA, "Protocol Numbers", 2011,
<http://www.iana.org/assignments/protocol-numbers>.
[RFC3022] Srisuresh, P. 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] Arends, R., Austein, R., Larson, M., Massey, D., 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] Leach, P., Mealling, M., 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] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>.
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
Denial-of-Service Considerations", RFC 4732,
DOI 10.17487/RFC4732, December 2006,
<https://www.rfc-editor.org/info/rfc4732>.
[RFC4787] Audet, F., Ed. 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] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
<https://www.rfc-editor.org/info/rfc4987>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[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>.
[RFC6234] Eastlake 3rd, D. 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] Wasserman, M. 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] Thaler, D., Ed., Draves, R., Matsumoto, A., 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] Freed, N., Klensin, J., 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] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
DOI 10.17487/RFC6887, April 2013,
<https://www.rfc-editor.org/info/rfc6887>.
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
A., 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] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>.
[RFC7452] Tschofenig, H., Arkko, J., Thaler, D., 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] Badra, M., Luchuk, A., 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] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
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] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
D., Mahy, R., 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] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
Threat Signaling (DOTS) Requirements", RFC 8612,
DOI 10.17487/RFC8612, May 2019,
<https://www.rfc-editor.org/info/rfc8612>.
[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "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>.
Appendix A. CUID Generation
The document recommends the use of SPKI to generate the 'cuid'. This
design choice is motivated by the following reasons:
* 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.
Acknowledgements
Thanks to Christian Jacquenet, Roland Dobbins, Roman Danyliw, Michael
Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang Xia,
Gilbert Clark, Xialiang Frank, Jim Schaad, Klaus Hartke, Nesredien
Suleiman, Stephen Farrell, and Yoshifumi Nishida for the discussion
and comments.
The authors would like to give special thanks to Kaname Nishizuka and
Jon Shallow for their efforts in implementing the protocol and
performing interop testing at IETF Hackathons.
Thanks to the core WG for the recommendations on Hop-Limit and
redirect signaling.
Special thanks to Benjamin Kaduk for the detailed AD review.
Thanks to Alexey Melnikov, Adam Roach, Suresh Krishnan, Mirja
Kühlewind, and Alissa Cooper for the review.
Thanks to Carsten Bormann for his review of the DOTS heartbeat
mechanism.
Contributors
The following individuals have contributed to this document:
Jon Shallow
NCC Group
Email: jon.shallow@nccgroup.trust
Mike Geller
Cisco Systems, Inc.
FL 33309
United States of America
Email: mgeller@cisco.com
Robert Moskowitz
HTT Consulting
Oak Park, MI 42837
United States of America
Email: rgm@htt-consult.com
Dan Wing
Email: dwing-ietf@fuggles.com
Authors' Addresses
Tirumaleswar Reddy.K (editor)
McAfee, Inc.
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
Prashanth Patil
Cisco Systems, Inc.
Email: praspati@cisco.com
Andrew Mortensen
Arbor Networks, Inc.
2727 S. State Street
Ann Arbor, MI 48104
United States of America
Email: andrew@moretension.com
Nik Teague
Iron Mountain Data Centers
United Kingdom
Email: nteague@ironmountain.co.uk