< draft-ietf-dots-signal-channel-23.txt   draft-ietf-dots-signal-channel-24.txt >
DOTS T. Reddy, Ed. DOTS T. Reddy, Ed.
Internet-Draft McAfee Internet-Draft McAfee
Intended status: Standards Track M. Boucadair, Ed. Intended status: Standards Track M. Boucadair, Ed.
Expires: February 18, 2019 Orange Expires: March 3, 2019 Orange
P. Patil P. Patil
Cisco Cisco
A. Mortensen A. Mortensen
Arbor Networks, Inc. Arbor Networks, Inc.
N. Teague N. Teague
Verisign, Inc. Verisign, Inc.
August 17, 2018 August 30, 2018
Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel Specification Channel Specification
draft-ietf-dots-signal-channel-23 draft-ietf-dots-signal-channel-24
Abstract Abstract
This document specifies the DOTS signal channel, a protocol for This document specifies the DOTS signal channel, a protocol for
signaling the need for protection against Distributed Denial-of- signaling the need for protection against Distributed Denial-of-
Service (DDoS) attacks to a server capable of enabling network Service (DDoS) attacks to a server capable of enabling network
traffic mitigation on behalf of the requesting client. traffic mitigation on behalf of the requesting client.
A companion document defines the DOTS data channel, a separate A companion document defines the DOTS data channel, a separate
reliable communication layer for DOTS management and configuration reliable communication layer for DOTS management and configuration
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 18, 2019. This Internet-Draft will expire on March 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 27 skipping to change at page 3, line 27
7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 71 7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 71
7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 72 7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 72
7.3. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 73 7.3. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 73
8. Mutual Authentication of DOTS Agents & Authorization of DOTS 8. Mutual Authentication of DOTS Agents & Authorization of DOTS
Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76
9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 76 9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 76
9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 76 9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 76
9.3. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 76 9.3. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 76
9.3.1. Registration Template . . . . . . . . . . . . . . . . 77 9.3.1. Registration Template . . . . . . . . . . . . . . . . 77
9.3.2. Initial Registry Content . . . . . . . . . . . . . . 77 9.3.2. Initial Registry Content . . . . . . . . . . . . . . 78
9.4. DOTS Signal Channel YANG Module . . . . . . . . . . . . . 78 9.4. DOTS Signal Channel YANG Module . . . . . . . . . . . . . 79
10. Security Considerations . . . . . . . . . . . . . . . . . . . 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 79
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 80 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 80
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 80 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 81
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 81
13.1. Normative References . . . . . . . . . . . . . . . . . . 80 13.1. Normative References . . . . . . . . . . . . . . . . . . 81
13.2. Informative References . . . . . . . . . . . . . . . . . 82 13.2. Informative References . . . . . . . . . . . . . . . . . 83
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87
1. Introduction 1. Introduction
A distributed denial-of-service (DDoS) attack is an attempt to make A distributed denial-of-service (DDoS) attack is an attempt to make
machines or network resources unavailable to their intended users. machines or network resources unavailable to their intended users.
In most cases, sufficient scale can be achieved by compromising In most cases, sufficient scale can be achieved by compromising
enough end-hosts and using those infected hosts to perpetrate and enough end-hosts and using those infected hosts to perpetrate and
amplify the attack. The victim in this attack can be an application amplify the attack. The victim in this attack can be an application
server, a host, a router, a firewall, or an entire network. server, a host, a router, a firewall, or an entire network.
skipping to change at page 7, line 30 skipping to change at page 7, line 30
Likewise, DOTS requests may be sent using IPv4 or IPv6 transfer Likewise, DOTS requests may be sent using IPv4 or IPv6 transfer
capabilities. A Happy Eyeballs procedure for DOTS signal channel is capabilities. A Happy Eyeballs procedure for DOTS signal channel is
specified in Section 4.3. specified in Section 4.3.
Messages exchanged between DOTS agents are serialized using Concise Messages exchanged between DOTS agents are serialized using Concise
Binary Object Representation (CBOR) [RFC7049], a binary encoding Binary Object Representation (CBOR) [RFC7049], a binary encoding
scheme designed for small code and message size. CBOR-encoded scheme designed for small code and message size. CBOR-encoded
payloads are used to carry signal channel-specific payload messages payloads are used to carry signal channel-specific payload messages
which convey request parameters and response information such as which convey request parameters and response information such as
errors. In order to allow the use of the same data models, [RFC7951] errors. In order to allow the use of the same data models, [RFC7951]
specifies the JSON encoding of YANG-modeled data. A similar effort specifies the JavaScript Object Notation (JSON) encoding of YANG-
for CBOR is defined in [I-D.ietf-core-yang-cbor]. modeled data. A similar effort for CBOR is defined in
[I-D.ietf-core-yang-cbor].
From that standpoint, this document specifies a YANG module for From that standpoint, this document specifies a YANG module for
representing DOTS mitigation scopes, DOTS signal channel session representing DOTS mitigation scopes, DOTS signal channel session
configuration data, and DOTS redirected signalling (Section 5). configuration data, and DOTS redirected signalling (Section 5).
Representing these data as CBOR data is assumed to follow the rules Representing these data as CBOR data is assumed to follow the rules
in [I-D.ietf-core-yang-cbor] or those in [RFC7951] combined with in [I-D.ietf-core-yang-cbor] or those in [RFC7951] combined with
JSON/CBOR conversion rules in [RFC7049]. All parameters in the JSON/CBOR conversion rules in [RFC7049]. All parameters in the
payload of the DOTS signal channel are mapped to CBOR types as payload of the DOTS signal channel are mapped to CBOR types as
specified in Section 6. specified in Section 6.
In order to prevent fragmentation, DOTS agents must follow the In order to prevent fragmentation, DOTS agents must follow the
recommendations documented in Section 4.6 of [RFC7252]. Refer to recommendations documented in Section 4.6 of [RFC7252]. Refer to
Section 7.3 for more details. Section 7.3 for more details.
DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The
payload included in CoAP responses with 2.xx and 3.xx Response Codes payload included in CoAP responses with 2.xx Response Codes MUST be
MUST be of content type "application/cbor" (Section 5.5.1 of of content type "application/cbor" (Section 5.5.1 of [RFC7252]).
[RFC7252]). CoAP responses with 4.xx and 5.xx error Response Codes CoAP responses with 4.xx and 5.xx error Response Codes MUST include a
MUST include a diagnostic payload (Section 5.5.2 of [RFC7252]). The diagnostic payload (Section 5.5.2 of [RFC7252]). The Diagnostic
Diagnostic Payload may contain additional information to aid Payload may contain additional information to aid troubleshooting.
troubleshooting.
In deployments where multiple DOTS clients are enabled in a network In deployments where multiple DOTS clients are enabled in a network
(owned and operated by the same entity), the DOTS server may detect (owned and operated by the same entity), the DOTS server may detect
conflicting mitigation requests from these clients. This document conflicting mitigation requests from these clients. This document
does not aim to specify a comprehensive list of conditions under does not aim to specify a comprehensive list of conditions under
which a DOTS server will characterize two mitigation requests from which a DOTS server will characterize two mitigation requests from
distinct DOTS clients as conflicting, nor recommend a DOTS server distinct DOTS clients as conflicting, nor recommend a DOTS server
behavior for processing conflicting mitigation requests. Those behavior for processing conflicting mitigation requests. Those
considerations are implementation- and deployment-specific. considerations are implementation- and deployment-specific.
Nevertheless, the document specifies the mechanisms to notify DOTS Nevertheless, the document specifies the mechanisms to notify DOTS
skipping to change at page 9, line 17 skipping to change at page 9, line 17
The DOTS server MUST support the use of the path-prefix of "/.well- The DOTS server MUST support the use of the path-prefix of "/.well-
known/" as defined in [RFC5785] and the registered name of "dots". known/" as defined in [RFC5785] and the registered name of "dots".
Each DOTS operation is indicated by a path-suffix that indicates the Each DOTS operation is indicated by a path-suffix that indicates the
intended operation. The operation path (Table 1) is appended to the intended operation. The operation path (Table 1) is appended to the
path-prefix to form the URI used with a CoAP request to perform the path-prefix to form the URI used with a CoAP request to perform the
desired DOTS operation. desired DOTS operation.
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
| Operation | Operation Path | Details | | Operation | Operation Path | Details |
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
| Mitigation | /v1/mitigate | Section 4.4 | | Mitigation | /v1.0/mitigate | Section 4.4 |
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
| Session configuration | /v1/config | Section 4.5 | | Session configuration | /v1.0/config | Section 4.5 |
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
Table 1: Operations and their Corresponding URIs Table 1: Operations and their Corresponding URIs
4.3. Happy Eyeballs for DOTS Signal Channel 4.3. Happy Eyeballs for DOTS Signal Channel
[I-D.ietf-dots-requirements] mentions that DOTS agents will have to [I-D.ietf-dots-requirements] mentions that DOTS agents will have to
support both connectionless and connection-oriented protocols. As support both connectionless and connection-oriented protocols. As
such, the DOTS signal channel is designed to operate with DTLS over such, the DOTS signal channel is designed to operate with DTLS over
UDP and TLS over TCP. Further, a DOTS client may acquire a list of UDP and TLS over TCP. Further, a DOTS client may acquire a list of
skipping to change at page 10, line 24 skipping to change at page 10, line 24
this example, it is assumed that the IPv6 path is broken and UDP this example, it is assumed that the IPv6 path is broken and UDP
traffic is dropped by a middlebox but has little impact to the DOTS traffic is dropped by a middlebox but has little impact to the DOTS
client because there is no long delay before using IPv4 and TCP. The client because there is no long delay before using IPv4 and TCP. The
DOTS client repeats the mechanism to discover whether DOTS signal DOTS client repeats the mechanism to discover whether DOTS signal
channel messages with DTLS over UDP becomes available from the DOTS channel messages with DTLS over UDP becomes available from the DOTS
server, so the DOTS client can migrate the DOTS signal channel from server, so the DOTS client can migrate the DOTS signal channel from
TCP to UDP. Such probing SHOULD NOT be done more frequently than 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 every 24 hours and MUST NOT be done more frequently than every 5
minutes. minutes.
A single DOTS signal channel between DOTS agents can be used to
exchange multiple DOTS signal messages. To reduce DOTS client and
DOTS server workload, DOTS clients SHOULD re-use the (D)TLS session.
+-----------+ +-----------+ +-----------+ +-----------+
|DOTS client| |DOTS server| |DOTS client| |DOTS server|
+-----------+ +-----------+ +-----------+ +-----------+
| | | |
|--DTLS ClientHello, IPv6 ---->X | |--DTLS ClientHello, IPv6 ---->X |
|--TCP SYN, IPv6-------------->X | |--TCP SYN, IPv6-------------->X |
|--DTLS ClientHello, IPv4 ---->X | |--DTLS ClientHello, IPv4 ---->X |
|--TCP SYN, IPv4--------------------------------------->| |--TCP SYN, IPv4--------------------------------------->|
|--DTLS ClientHello, IPv6 ---->X | |--DTLS ClientHello, IPv6 ---->X |
|--TCP SYN, IPv6-------------->X | |--TCP SYN, IPv6-------------->X |
skipping to change at page 12, line 6 skipping to change at page 12, line 6
client uses the CoAP PUT method to send a mitigation request to its client uses the CoAP PUT method to send a mitigation request to its
DOTS server(s) (Figure 5, illustrated in JSON diagnostic notation). DOTS server(s) (Figure 5, illustrated in JSON diagnostic notation).
If a DOTS client is entitled to solicit the DOTS service, the DOTS If a DOTS client is entitled to solicit the DOTS service, the DOTS
server can enable mitigation on behalf of the DOTS client by server can enable mitigation on behalf of the DOTS client by
communicating the DOTS client's request to a mitigator and relaying communicating the DOTS client's request to a mitigator and relaying
the feedback of the thus-selected mitigator to the requesting DOTS the feedback of the thus-selected mitigator to the requesting DOTS
client. client.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Host: "host"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "version" Uri-Path: "v1.0"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
Content-Type: "application/cbor" Content-Type: "application/cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"target-prefix": [ "target-prefix": [
"string" "string"
skipping to change at page 12, line 50 skipping to change at page 12, line 49
"trigger-mitigation": boolean "trigger-mitigation": boolean
} }
] ]
} }
} }
Figure 5: PUT to Convey DOTS Mitigation Requests Figure 5: PUT to Convey DOTS Mitigation Requests
The Uri-Path option carries a major and minor version nomenclature to The Uri-Path option carries a major and minor version nomenclature to
manage versioning; DOTS signal channel in this specification uses manage versioning; DOTS signal channel in this specification uses
'v1' major version. 'v1' major version and '0' minor version.
The order of the Uri-Path options is important as it defines the CoAP The order of the Uri-Path options is important as it defines the CoAP
resource. In particular, 'mid' MUST follow 'cuid'. resource. In particular, 'mid' MUST follow 'cuid'.
The additional Uri-Path parameters to those defined in Section 4.2 The additional Uri-Path parameters to those defined in Section 4.2
are as follows: are as follows:
cuid: Stands for Client Unique Identifier. A globally unique cuid: Stands for Client Unique Identifier. A globally unique
identifier that is meant to prevent collisions among DOTS clients, identifier that is meant to prevent collisions among DOTS clients,
especially those from the same domain. It MUST be generated by especially those from the same domain. It MUST be generated by
DOTS clients. DOTS clients.
Implementations SHOULD use the output of a cryptographic hash Implementations SHOULD use the output of a cryptographic hash
algorithm whose input is the DER-encoded ASN.1 representation of algorithm whose input is the Distinguished Encoding Rules (DER)-
the Subject Public Key Info (SPKI) of the DOTS client X.509 encoded Abstract Syntax Notation One (ASN.1) representation of the
Subject Public Key Info (SPKI) of the DOTS client X.509
certificate [RFC5280], the DOTS client raw public key [RFC7250], certificate [RFC5280], the DOTS client raw public key [RFC7250],
or the "PSK identity" used by the DOTS client in the TLS or the "Pre-Shared Key (PSK) identity" used by the DOTS client in
ClientKeyExchange message to set 'cuid'. In this version of the the TLS ClientKeyExchange message to set 'cuid'. In this version
specification, the cryptographic hash algorithm used is SHA-256 of the specification, the cryptographic hash algorithm used is
[RFC6234]. The output of the cryptographic hash algorithm is SHA-256 [RFC6234]. The output of the cryptographic hash algorithm
truncated to 16 bytes; truncation is done by stripping off the is truncated to 16 bytes; truncation is done by stripping off the
final 16 bytes. The truncated output is base64url encoded. final 16 bytes. The truncated output is base64url encoded.
The 'cuid' is intended to be stable when communicating with a The 'cuid' is intended to be stable when communicating with a
given DOTS server, i.e., the 'cuid' used by a DOTS client SHOULD given DOTS server, i.e., the 'cuid' used by a DOTS client SHOULD
NOT change over time. Distinct 'cuid' values MAY be used per DOTS NOT change over time. Distinct 'cuid' values MAY be used per DOTS
server. server.
DOTS servers MUST return 4.09 (Conflict) error code to a DOTS peer 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 to notify that the 'cuid' is already in-use by another DOTS
client. Upon receipt of that error code, a new 'cuid' MUST be client. Upon receipt of that error code, a new 'cuid' MUST be
generated by the DOTS peer. generated by the DOTS peer.
Client-domain DOTS gateways MUST handle 'cuid' collision directly Client-domain DOTS gateways MUST handle 'cuid' collision directly
and it is RECOMMENDED that 'cuid' collision is handled directly by and it is RECOMMENDED that 'cuid' collision is handled directly by
server-domain DOTS gateways. server-domain DOTS gateways.
DOTS gateways MAY rewrite the 'cuid' used by peer DOTS clients. DOTS gateways MAY rewrite the 'cuid' used by peer DOTS clients.
Triggers for such rewriting are out of scope. Triggers for such rewriting are out of scope.
This is a mandatory Uri-Path. This is a mandatory Uri-Path parameter.
mid: Identifier for the mitigation request represented with an mid: Identifier for the mitigation request represented with an
integer. This identifier MUST be unique for each mitigation integer. This identifier MUST be unique for each mitigation
request bound to the DOTS client, i.e., the 'mid' parameter value request bound to the DOTS client, i.e., the 'mid' parameter value
in the mitigation request needs to be unique relative to the 'mid' in the mitigation request needs to be unique relative to the 'mid'
parameter values of active mitigation requests conveyed from the parameter values of active mitigation requests conveyed from the
DOTS client to the DOTS server. DOTS client to the DOTS server.
In order to handle out-of-order delivery of mitigation requests, In order to handle out-of-order delivery of mitigation requests,
'mid' values MUST increase monotonically. 'mid' values MUST increase monotonically.
skipping to change at page 17, line 6 skipping to change at page 17, line 6
DOTS server to enforce some policies such as correlating DOTS clients DOTS server to enforce some policies such as correlating DOTS clients
that belong to the same DOTS domain, limiting the number of DOTS that belong to the same DOTS domain, limiting the number of DOTS
requests, and identifying the mitigation scope. These policies can requests, and identifying the mitigation scope. These policies can
be enforced per-client, per-client domain, or both. Also, the be enforced per-client, per-client domain, or both. Also, the
identity information may be used for auditing and debugging purposes. identity information may be used for auditing and debugging purposes.
Figure 6 shows an example of a request relayed by a server-domain Figure 6 shows an example of a request relayed by a server-domain
DOTS gateway. DOTS gateway.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Host: "host"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1" Uri-Path: "v1.0"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cdid=7eeaf349529eb55ed50113" Uri-Path: "cdid=7eeaf349529eb55ed50113"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
Content-Type: "application/cbor" Content-Type: "application/cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"target-prefix": [ "target-prefix": [
skipping to change at page 18, line 5 skipping to change at page 17, line 51
] ]
} }
} }
Figure 6: PUT to Convey DOTS Mitigation Request as relayed by a Figure 6: PUT to Convey DOTS Mitigation Request as relayed by a
Server-Domain DOTS Gateway Server-Domain DOTS Gateway
A server-domain DOTS gateway SHOULD add the following Uri-Path A server-domain DOTS gateway SHOULD add the following Uri-Path
parameter: parameter:
cdid: Stands for Client Domain IDentifier. The 'cdid' is conveyed cdid: Stands for Client Domain Identifier. The 'cdid' is conveyed
by a server-domain DOTS gateway to propagate the source domain by a server-domain DOTS gateway to propagate the source domain
identity from the gateway's client-facing-side to the gateway's identity from the gateway's client-facing-side to the gateway's
server-facing-side, and from the gateway's server-facing-side to 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 the DOTS server. 'cdid' may be used by the final DOTS server for
policy enforcement purposes (e.g., enforce a quota on filtering policy enforcement purposes (e.g., enforce a quota on filtering
rules). These policies are deployment-specific. rules). These policies are deployment-specific.
Server-domain DOTS gateways SHOULD support a configuration option Server-domain DOTS gateways SHOULD support a configuration option
to instruct whether 'cdid' parameter is to be inserted. to instruct whether 'cdid' parameter is to be inserted.
skipping to change at page 20, line 6 skipping to change at page 20, line 6
present in a request. present in a request.
Figure 7 shows a PUT request example to signal that ports 80, 8080, Figure 7 shows a PUT request example to signal that ports 80, 8080,
and 443 used by 2001:db8:6401::1 and 2001:db8:6401::2 servers are and 443 used by 2001:db8:6401::1 and 2001:db8:6401::2 servers are
under attack (illustrated in JSON diagnostic notation). The presence under attack (illustrated in JSON diagnostic notation). The presence
of 'cdid' indicates that a server-domain DOTS gateway has modified of 'cdid' indicates that a server-domain DOTS gateway has modified
the initial PUT request sent by the DOTS client. Note that 'cdid' the initial PUT request sent by the DOTS client. Note that 'cdid'
MUST NOT appear in the PUT request message body. MUST NOT appear in the PUT request message body.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Host: "www.example.com"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1" Uri-Path: "v1.0"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cdid=7eeaf349529eb55ed50113" Uri-Path: "cdid=7eeaf349529eb55ed50113"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"target-prefix": [ "target-prefix": [
skipping to change at page 22, line 22 skipping to change at page 22, line 22
The DOTS server indicates the result of processing the PUT request The DOTS server indicates the result of processing the PUT request
using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx
codes are some sort of invalid requests (client errors). COAP 5.xx codes are some sort of invalid requests (client errors). COAP 5.xx
codes are returned if the DOTS server has erred or is currently codes are returned if the DOTS server has erred or is currently
unavailable to provide mitigation in response to the mitigation unavailable to provide mitigation in response to the mitigation
request from the DOTS client. request from the DOTS client.
Figure 9 shows an example response to a PUT request that is Figure 9 shows an example response to a PUT request that is
successfully processed by a DOTS server (i.e., CoAP 2.xx response successfully processed by a DOTS server (i.e., CoAP 2.xx response
codes). This version of the specification forbids 'cuid' and 'cdid' codes). This version of the specification forbids 'cuid' and 'cdid'
(if used) to be returned in a response. (if used) to be returned in a response message body.
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"mid": 12332, "mid": 12332,
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
skipping to change at page 26, line 25 skipping to change at page 26, line 25
request. request.
The same considerations for manipulating 'cdid' parameter by server- The same considerations for manipulating 'cdid' parameter by server-
domain DOTS gateways specified in Section 4.4.1 MUST be followed for domain DOTS gateways specified in Section 4.4.1 MUST be followed for
GET requests. GET requests.
The 'c' (content) parameter and its permitted values defined in The 'c' (content) parameter and its permitted values defined in
[I-D.ietf-core-comi] can be used to retrieve non-configuration data [I-D.ietf-core-comi] can be used to retrieve non-configuration data
(attack mitigation status), configuration data, or both. The DOTS (attack mitigation status), configuration data, or both. The DOTS
server MAY support this optional filtering capability. It can safely server MAY support this optional filtering capability. It can safely
ignore it if not supported. ignore it if not supported. If the DOTS client supports the optional
filtering capability, it SHOULD use "c=n" query (to get back only the
dynamically changing data) or "c=c" query (to get back the static
configuration values) when the DDoS attack is active to limit the
size of the response.
The DOTS client can use Block-wise transfer [RFC7959] to get the list
of all its mitigations maintained by a DOTS server, it can send
Block2 Option in a GET request with NUM = 0 to aid in limiting the
size of the response. If the representation of all the active
mitigation requests associated with the DOTS client does not fit
within a single datagram, the DOTS server MUST use the Block2 Option
with NUM = 0 in the GET response. The Size2 Option may be conveyed
in the response to indicate the total size of the resource
representation. The DOTS client retrieves the rest of the
representation by sending additional GET requests with Block2 Options
containing NUM values greater than zero. The DOTS client MUST adhere
to the block size preferences indicated by the DOTS server in the
response. If the DOTS server uses the Block2 Option in the GET
response and the response is for a dynamically changing resource
(e.g. "c=n" or "c=a" query), the DOTS server MUST include the ETag
Option in the response. The DOTS client MUST include the same ETag
value in subsequent GET requests to retrieve the rest of the
representation.
The following examples illustrate how a DOTS client retrieves active The following examples illustrate how a DOTS client retrieves active
mitigation requests from a DOTS server. In particular: mitigation requests from a DOTS server. In particular:
o Figure 10 shows the example of a GET request to retrieve all DOTS o Figure 10 shows the example of a GET request to retrieve all DOTS
mitigation requests signaled by a DOTS client. mitigation requests signaled by a DOTS client.
o Figure 11 shows the example of a GET request to retrieve a o Figure 11 shows the example of a GET request to retrieve a
specific DOTS mitigation request signaled by a DOTS client. The specific DOTS mitigation request signaled by a DOTS client. The
configuration data to be reported in the response is formatted in configuration data to be reported in the response is formatted in
the same order as was processed by the DOTS server in the original the same order as was processed by the DOTS server in the original
mitigation request. mitigation request.
These two examples assume the default of "c=a"; that is, the DOTS These two examples assume the default of "c=a"; that is, the DOTS
client asks for all data to be reported by the DOTS server. client asks for all data to be reported by the DOTS server.
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Host: "host"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1" Uri-Path: "v1.0"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Observe: 0 Observe: 0
Figure 10: GET to Retrieve all DOTS Mitigation Requests Figure 10: GET to Retrieve all DOTS Mitigation Requests
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Host: "host"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1" Uri-Path: "v1.0"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=12332" Uri-Path: "mid=12332"
Observe: 0 Observe: 0
Figure 11: GET to Retrieve a Specific DOTS Mitigation Request Figure 11: GET to Retrieve a Specific DOTS Mitigation Request
If the DOTS server does not find the 'mid' Uri-Path value conveyed in If the DOTS server does not find the 'mid' Uri-Path value conveyed in
the GET request in its configuration data for the requesting DOTS the GET request in its configuration data for the requesting DOTS
client, it MUST respond with a 4.04 (Not Found) error response code. client, it MUST respond with a 4.04 (Not Found) error response code.
skipping to change at page 31, line 10 skipping to change at page 31, line 10
The Observe Option defined in [RFC7641] extends the CoAP core The Observe Option defined in [RFC7641] extends the CoAP core
protocol with a mechanism for a CoAP client to "observe" a resource protocol with a mechanism for a CoAP client to "observe" a resource
on a CoAP server: The client retrieves a representation of the on a CoAP server: The client retrieves a representation of the
resource and requests this representation be updated by the server as resource and requests this representation be updated by the server as
long as the client is interested in the resource. DOTS long as the client is interested in the resource. DOTS
implementations MUST use the Observe Option for both 'mitigate' and implementations MUST use the Observe Option for both 'mitigate' and
'config' (Section 4.2). 'config' (Section 4.2).
A DOTS client conveys the Observe Option set to '0' in the GET A DOTS client conveys the Observe Option set to '0' in the GET
request to receive unsolicited notifications of attack mitigation request to receive asynchronous notifications of attack mitigation
status from the DOTS server. status from the DOTS server.
Unidirectional mitigation notifications within the bidirectional Unidirectional mitigation notifications within the bidirectional
signal channel allows unsolicited message delivery, enabling signal channel enables asynchronous notifications between the agents.
asynchronous notifications between the agents. [RFC7641] indicates [RFC7641] indicates that (1) a notification can be sent in a
that (1) a notification can be sent in a Confirmable (CON) or a Non- Confirmable (CON) or a Non-confirmable (NON) message, and (2) the
confirmable (NON) message, and (2) the message type used is typically message type used is typically application dependent and may be
application dependent and may be determined by the server for each determined by the server for each notification individually. For
notification individually. For DOTS server application, the message DOTS server application, the message type MUST always be set to Non-
type MUST always be set to Non-confirmable even if the underlying confirmable even if the underlying COAP library elects a notification
COAP library elects a notification to be sent in a Confirmable to be sent in a Confirmable message.
message.
Due to the higher likelihood of packet loss during a DDoS attack, the Due to the higher likelihood of packet loss during a DDoS attack, the
DOTS server periodically sends attack mitigation status to the DOTS DOTS server periodically sends attack mitigation status to the DOTS
client and also notifies the DOTS client whenever the status of the client and also notifies the DOTS client whenever the status of the
attack mitigation changes. If the DOTS server cannot maintain an RTT attack mitigation changes. If the DOTS server cannot maintain an RTT
estimate, it SHOULD NOT send more than one unsolicited notification estimate, it SHOULD NOT send more than one asynchronous notification
every 3 seconds, and SHOULD use an even less aggressive rate whenever every 3 seconds, and SHOULD use an even less aggressive rate whenever
possible (case 2 in Section 3.1.3 of [RFC8085]). possible (case 2 in Section 3.1.3 of [RFC8085]).
When conflicting requests are detected, the DOTS server enforces the When conflicting requests are detected, the DOTS server enforces the
corresponding policy (e.g., accept all requests, reject all requests, corresponding policy (e.g., accept all requests, reject all requests,
accept only one request but reject all the others, ...). It is accept only one request but reject all the others, ...). It is
assumed that this policy is supplied by the DOTS server administrator assumed that this policy is supplied by the DOTS server administrator
or it is a default behavior of the DOTS server implementation. Then, or it is a default behavior of the DOTS server implementation. Then,
the DOTS server sends notification message(s) to the DOTS client(s) the DOTS server sends notification message(s) to the DOTS client(s)
at the origin of the conflict (refer to the conflict parameters at the origin of the conflict (refer to the conflict parameters
skipping to change at page 35, line 6 skipping to change at page 35, line 6
PUT request. To handle out-of-order delivery of requests, if an If- PUT request. To handle out-of-order delivery of requests, if an If-
Match Option is present in the PUT request and the 'mid' in the Match Option is present in the PUT request and the 'mid' in the
request matches a mitigation request from that DOTS client, the request matches a mitigation request from that DOTS client, the
request is processed by the DOTS server. If no match is found, the request is processed by the DOTS server. If no match is found, the
PUT request is silently ignored by the DOTS server. PUT request is silently ignored by the DOTS server.
An example of an efficacy update message, which includes an If-Match An example of an efficacy update message, which includes an If-Match
Option with an empty value, is depicted in Figure 14. Option with an empty value, is depicted in Figure 14.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Host: "host"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1" Uri-Path: "v1.0"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
Content-Format: "application/cbor" Content-Format: "application/cbor"
If-Match: If-Match:
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"target-prefix": [ "target-prefix": [
skipping to change at page 36, line 40 skipping to change at page 36, line 40
'cuid' and 'mid' are mandatory Uri-Path parameters for DELETE 'cuid' and 'mid' are mandatory Uri-Path parameters for DELETE
requests. requests.
The same considerations for manipulating 'cdid' parameter by DOTS The same considerations for manipulating 'cdid' parameter by DOTS
gateways, as specified in Section 4.4.1, MUST be followed for DELETE gateways, as specified in Section 4.4.1, MUST be followed for DELETE
requests. Uri-Path parameters with empty values MUST NOT be present requests. Uri-Path parameters with empty values MUST NOT be present
in a request. in a request.
Header: DELETE (Code=0.04) Header: DELETE (Code=0.04)
Uri-Host: "host"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1" Uri-Path: "v1.0"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
Figure 15: Withdraw a DOTS Mitigation Figure 15: Withdraw a DOTS Mitigation
If the DELETE request does not include 'cuid' and 'mid' parameters, If the DELETE request does not include 'cuid' and 'mid' parameters,
the DOTS server MUST reply with a 4.00 (Bad Request). the DOTS server MUST reply with a 4.00 (Bad Request).
Once the request is validated, the DOTS server immediately Once the request is validated, the DOTS server immediately
skipping to change at page 39, line 27 skipping to change at page 39, line 27
A GET request is used to obtain acceptable (e.g., minimum and maximum A GET request is used to obtain acceptable (e.g., minimum and maximum
values) and current configuration parameters on the DOTS server for values) and current configuration parameters on the DOTS server for
DOTS signal channel session configuration. This procedure occurs DOTS signal channel session configuration. This procedure occurs
between a DOTS client and its immediate peer DOTS server. As such, between a DOTS client and its immediate peer DOTS server. As such,
this GET request MUST NOT be relayed by an on-path DOTS gateway. this GET request MUST NOT be relayed by an on-path DOTS gateway.
Figure 16 shows how to obtain acceptable configuration parameters for Figure 16 shows how to obtain acceptable configuration parameters for
the DOTS server. the DOTS server.
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Host: "host"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1" Uri-Path: "v1.0"
Uri-Path: "config" Uri-Path: "config"
Figure 16: GET to Retrieve Configuration Figure 16: GET to Retrieve Configuration
The DOTS server in the 2.05 (Content) response conveys the current, The DOTS server in the 2.05 (Content) response conveys the current,
minimum, and maximum attribute values acceptable by the DOTS server minimum, and maximum attribute values acceptable by the DOTS server
(Figure 17). (Figure 17).
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
skipping to change at page 44, line 31 skipping to change at page 45, line 6
transmission parameters, it SHOULD follow the guidance given in transmission parameters, it SHOULD follow the guidance given in
Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the negotiated Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the negotiated
values for message transmission parameters and default values for values for message transmission parameters and default values for
non-negotiated message transmission parameters. non-negotiated message transmission parameters.
The signal channel session configuration is applicable to a single The signal channel session configuration is applicable to a single
DOTS signal channel session between DOTS agents, so the 'cuid' Uri- DOTS signal channel session between DOTS agents, so the 'cuid' Uri-
Path MUST NOT be used. Path MUST NOT be used.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Host: "host"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1" Uri-Path: "v1.0"
Uri-Path: "config" Uri-Path: "config"
Uri-Path: "sid=123" Uri-Path: "sid=123"
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"ietf-dots-signal-channel:signal-config": { "ietf-dots-signal-channel:signal-config": {
"mitigating-config": { "mitigating-config": {
"heartbeat-interval": { "heartbeat-interval": {
"current-value": integer "current-value": integer
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
skipping to change at page 47, line 6 skipping to change at page 47, line 6
with a lower numeric 'sid' value. To avoid maintaining a long list with a lower numeric 'sid' value. To avoid maintaining a long list
of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be
automatically deleted and no longer available at the DOTS server. automatically deleted and no longer available at the DOTS server.
Figure 20 shows a PUT request example to convey the configuration Figure 20 shows a PUT request example to convey the configuration
parameters for the DOTS signal channel. In this example, the parameters for the DOTS signal channel. In this example, the
heartbeat mechanism is disabled when no mitigation is active, while heartbeat mechanism is disabled when no mitigation is active, while
the heartbeat interval is set to '91' when a mitigation is active. the heartbeat interval is set to '91' when a mitigation is active.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Host: "www.example.com"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1" Uri-Path: "v1.0"
Uri-Path: "config" Uri-Path: "config"
Uri-Path: "sid=123" Uri-Path: "sid=123"
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"ietf-dots-signal-channel:signal-config": { "ietf-dots-signal-channel:signal-config": {
"mitigating-config": { "mitigating-config": {
"heartbeat-interval": { "heartbeat-interval": {
"current-value": 91 "current-value": 91
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
skipping to change at page 49, line 33 skipping to change at page 49, line 33
(D)TLS session. A (D)TLS session is terminated by the receipt of an (D)TLS session. A (D)TLS session is terminated by the receipt of an
authenticated message that closes the connection (e.g., a fatal alert authenticated message that closes the connection (e.g., a fatal alert
(Section 6 of [RFC8446])). (Section 6 of [RFC8446])).
4.5.4. Delete DOTS Signal Channel Session Configuration 4.5.4. Delete DOTS Signal Channel Session Configuration
A DELETE request is used to delete the installed DOTS signal channel A DELETE request is used to delete the installed DOTS signal channel
session configuration data (Figure 21). session configuration data (Figure 21).
Header: DELETE (Code=0.04) Header: DELETE (Code=0.04)
Uri-Host: "host"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1" Uri-Path: "v1.0"
Uri-Path: "config" Uri-Path: "config"
Uri-Path: "sid=123" Uri-Path: "sid=123"
Figure 21: Delete Configuration Figure 21: Delete Configuration
The DOTS server resets the DOTS signal channel session configuration The DOTS server resets the DOTS signal channel session configuration
back to the default values and acknowledges a DOTS client's request back to the default values and acknowledges a DOTS client's request
to remove the DOTS signal channel session configuration using 2.02 to remove the DOTS signal channel session configuration using 2.02
(Deleted) response code. (Deleted) response code.
skipping to change at page 50, line 20 skipping to change at page 50, line 20
If a DOTS server wants to redirect a DOTS client to an alternative If a DOTS server wants to redirect a DOTS client to an alternative
DOTS server for a signal session, then the response code 5.03 DOTS server for a signal session, then the response code 5.03
(Service Unavailable) will be returned in the response to the DOTS (Service Unavailable) will be returned in the response to the DOTS
client. client.
The DOTS server can return the error response code 5.03 in response The DOTS server can return the error response code 5.03 in response
to a request from the DOTS client or convey the error response code to a request from the DOTS client or convey the error response code
5.03 in a unidirectional notification response from the DOTS server. 5.03 in a unidirectional notification response from the DOTS server.
The DOTS server in the error response conveys the alternate DOTS The DOTS server in the error response conveys the alternate DOTS
server's FQDN, and the alternate DOTS server's IP address(es) and server's FQDN, and the alternate DOTS server's IP address(es) values
time to live values in the CBOR body (Figure 22). in the CBOR body (Figure 22).
{ {
"ietf-dots-signal-channel:redirected-signal": { "ietf-dots-signal-channel:redirected-signal": {
"alt-server": "string", "alt-server": "string",
"alt-server-record": [ "alt-server-record": [
"string" "string"
] ]
} }
Figure 22: Redirected Server Error Response Body Figure 22: Redirected Server Error Response Body
skipping to change at page 69, line 13 skipping to change at page 69, line 13
} }
} }
} }
<CODE ENDS> <CODE ENDS>
6. Mapping Parameters to CBOR 6. Mapping Parameters to CBOR
All parameters in the payload of the DOTS signal channel MUST be All parameters in the payload of the DOTS signal channel MUST be
mapped to CBOR types as shown in Table 4 and are assigned an integer mapped to CBOR types as shown in Table 4 and are assigned an integer
key to save space. The recipient of the payload MAY reject the key to save space. The CBOR key values are divided into two types:
information if it is not suitably mapped. comprehension-required and comprehension-optional. DOTS agents can
safely ignore comprehension-optional values they don't understand,
but cannot successfully process a request if it contains
comprehension-required values that are not understood. The 4.00
response SHOULD include a diagnostic payload describing the unknown
comprehension-required CBOR key values. The initial set of CBOR key
values defined in this specification are of type comprehension-
required.
+----------------------+-------------+-----+---------------+--------+ +----------------------+-------------+-----+---------------+--------+
| Parameter Name | YANG | CBOR| CBOR Major | JSON | | Parameter Name | YANG | CBOR| CBOR Major | JSON |
| | Type | Key | Type & | Type | | | Type | Key | Type & | Type |
| | | | Information | | | | | | Information | |
+----------------------+-------------+-----+---------------+--------+ +----------------------+-------------+-----+---------------+--------+
| ietf-dots-signal-cha | | | | | | ietf-dots-signal-cha | | | | |
| nnel:mitigation-scope| container | 1 | 5 map | Object | | nnel:mitigation-scope| container | 1 | 5 map | Object |
| scope | list | 2 | 4 array | Array | | scope | list | 2 | 4 array | Array |
| cdid | string | 3 | 3 text string | String | | cdid | string | 3 | 3 text string | String |
skipping to change at page 72, line 11 skipping to change at page 72, line 17
Implementations compliant with this profile MUST implement all of the Implementations compliant with this profile MUST implement all of the
following items: following items:
o DTLS record replay detection (Section 3.3 of [RFC6347]) to protect o DTLS record replay detection (Section 3.3 of [RFC6347]) to protect
against replay attacks. against replay attacks.
o DTLS session resumption without server-side state to resume o DTLS session resumption without server-side state to resume
session and convey the DOTS signal. session and convey the DOTS signal.
o Raw public keys [RFC7250] or PSK handshake [RFC4279] which reduces o Raw public keys [RFC7250] or PSK handshake [RFC4279] with (EC)DHE
the size of the ServerHello, and can be used by DOTS agents that key exchange which reduces the size of the ServerHello, and can be
cannot obtain certificates. used by DOTS agents that cannot obtain certificates.
Implementations compliant with this profile SHOULD implement all of Implementations compliant with this profile SHOULD implement all of
the following items to reduce the delay required to deliver a DOTS the following items to reduce the delay required to deliver a DOTS
signal channel message: signal channel message:
o TLS False Start [RFC7918] which reduces round-trips by allowing o TLS False Start [RFC7918] which reduces round-trips by allowing
the TLS second flight of messages (ChangeCipherSpec) to also the TLS second flight of messages (ChangeCipherSpec) to also
contain the DOTS signal. contain the DOTS signal.
o Cached Information Extension [RFC7924] which avoids transmitting o Cached Information Extension [RFC7924] which avoids transmitting
skipping to change at page 76, line 41 skipping to change at page 76, line 41
| URI | Change | Specification | Related | | URI | Change | Specification | Related |
| suffix | controller | document(s) | information | | suffix | controller | document(s) | information |
+----------+----------------+---------------------+-----------------+ +----------+----------------+---------------------+-----------------+
| dots | IETF | [RFCXXXX] | None | | dots | IETF | [RFCXXXX] | None |
+----------+----------------+---------------------+-----------------+ +----------+----------------+---------------------+-----------------+
Table 5: 'dots' well-known URI Table 5: 'dots' well-known URI
9.3. DOTS Signal Channel CBOR Mappings Registry 9.3. DOTS Signal Channel CBOR Mappings Registry
The DOTS signal channel protocol is extensible to support new
parameters and instructions for doing it are discussed below:
The document requests IANA to create a new registry, entitled "DOTS The document requests IANA to create a new registry, entitled "DOTS
Signal Channel CBOR Mappings Registry". The structure of this Signal Channel CBOR Mappings Registry". The structure of this
registry is provided in Section 9.3.1. registry is provided in Section 9.3.1. Registration requests are
evaluated using the criteria described in the CBOR Key Value
instructions in the registration template below 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 [RFC8126]. 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. [[ Note to the RFC
Editor: The name of the mailing list should be determined in
consultation with the IESG and IANA. Suggested name: dots-signal-
reg-review@ietf.org. ]]
The registry is initially populated with the values in Table 6. Registration requests sent to the mailing list for review should use
an appropriate subject (e.g., "Request to register parameter:
example"). 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.
Values from that registry MUST be assigned via Expert Review Criteria that should be applied by the Designated Experts includes
[RFC8126]. 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 application, and whether the
registration description is clear.
IANA must only accept registry updates 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 who are
able to represent the perspectives of different applications using
this specification in order to enable broadly informed review of
registration decisions. 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.
The registry is initially populated with the values in Table 6.
9.3.1. Registration Template 9.3.1. Registration Template
Parameter name: Parameter name:
Parameter name as used in the DOTS signal channel. Parameter name as used in the DOTS signal channel.
CBOR Key Value: CBOR Key Value:
Key value for the parameter. The key value MUST be an integer in Key value for the parameter. The key value MUST be an integer in
the 1-65535 range. The key values in the 32768-65535 range are the 1-65535 range. The key values of the comprehension-required
assigned to Vendor-Specific parameters. range (0x0001 - 0x3FFF) and of the comprehension-optional range
(0x8000 - 0xBFFF) are assigned by IETF Review [RFC8126]. The key
values of the comprehension-optional range (0x4000 - 0x7FFF) are
assigned by Designated Expert [RFC8126] and of the comprehension-
optional range (0xC000 - 0xFFFF) are reserved for Private Use
[RFC8126].
CBOR Major Type: CBOR Major Type:
CBOR Major type and optional tag for the claim. CBOR Major type and optional tag for the parameter.
Change Controller: Change Controller:
For Standards Track RFCs, list the "IESG". For others, give the For Standards Track RFCs, list the "IESG". For others, give the
name of the responsible party. Other details (e.g., postal name of the responsible party. Other details (e.g., postal
address, email address, home page URI) may also be included. address, email address, home page URI) may also be included.
Specification Document(s): Specification Document(s):
Reference to the document or documents that specify the parameter, Reference to the document or documents that specify the parameter,
preferably including URIs that can be used to retrieve copies of preferably including URIs that can be used to retrieve copies of
the documents. An indication of the relevant sections may also be the documents. An indication of the relevant sections may also be
skipping to change at page 79, line 23 skipping to change at page 80, line 9
10. Security Considerations 10. Security Considerations
Authenticated encryption MUST be used for data confidentiality and Authenticated encryption MUST be used for data confidentiality and
message integrity. The interaction between the DOTS agents requires message integrity. The interaction between the DOTS agents requires
Datagram Transport Layer Security (DTLS) and Transport Layer Security Datagram Transport Layer Security (DTLS) and Transport Layer Security
(TLS) with a cipher suite offering confidentiality protection and the (TLS) with a cipher suite offering confidentiality protection and the
guidance given in [RFC7525] MUST be followed to avoid attacks on guidance given in [RFC7525] MUST be followed to avoid attacks on
(D)TLS. The (D)TLS protocol profile for DOTS signal channel is (D)TLS. The (D)TLS protocol profile for DOTS signal channel is
specified in Section 7. specified in Section 7.
A single DOTS signal channel between DOTS agents can be used to
exchange multiple DOTS signal messages. To reduce DOTS client and
DOTS server workload, DOTS clients SHOULD re-use the (D)TLS session.
If TCP is used between DOTS agents, an attacker may be able to inject If TCP is used between DOTS agents, an attacker may be able to inject
RST packets, bogus application segments, etc., regardless of whether RST packets, bogus application segments, etc., regardless of whether
TLS authentication is used. Because the application data is TLS TLS authentication is used. Because the application data is TLS
protected, this will not result in the application receiving bogus protected, this will not result in the application receiving bogus
data, but it will constitute a DoS on the connection. This attack data, but it will constitute a DoS on the connection. This attack
can be countered by using TCP-AO [RFC5925]. If TCP-AO is used, then can be countered by using TCP-AO [RFC5925]. If TCP-AO is used, then
any bogus packets injected by an attacker will be rejected by the any bogus packets injected by an attacker will be rejected by the
TCP-AO integrity check and therefore will never reach the TLS layer. TCP-AO integrity check and therefore will never reach the TLS layer.
Rate-limiting DOTS requests, including those with new 'cuid' values, Rate-limiting DOTS requests, including those with new 'cuid' values,
skipping to change at page 80, line 20 skipping to change at page 81, line 4
CoAP-specific security considerations are discussed in Section 11 of CoAP-specific security considerations are discussed in Section 11 of
[RFC7252], while CBOR-related security considerations are discussed [RFC7252], while CBOR-related security considerations are discussed
in Section 8 of [RFC7049]. in Section 8 of [RFC7049].
11. Contributors 11. Contributors
The following individuals have contributed to this document: The following individuals have contributed to this document:
o Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.trust o Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.trust
o Mike Geller, Cisco Systems, Inc. 3250 Florida 33309 USA, Email: o Mike Geller, Cisco Systems, Inc. 3250 Florida 33309 USA, Email:
mgeller@cisco.com mgeller@cisco.com
o Robert Moskowitz, HTT Consulting Oak Park, MI 42837 United States, o Robert Moskowitz, HTT Consulting Oak Park, MI 42837 United States,
Email: rgm@htt-consult.com Email: rgm@htt-consult.com
o Dan Wing, Email: dwing-ietf@fuggles.com o Dan Wing, Email: dwing-ietf@fuggles.com
12. Acknowledgements 12. Acknowledgements
Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw, Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw,
Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang
Xia, Gilbert Clark, and Nesredien Suleiman for the discussion and Xia, Gilbert Clark, Xialiang Frank, Jim Schaad and Nesredien Suleiman
comments. for the discussion and comments.
Thanks to the core WG for the recommendations on Hop-Limit and Thanks to the core WG for the recommendations on Hop-Limit and
redirect signaling. redirect signaling.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 82, line 25 skipping to change at page 83, line 9
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <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 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
skipping to change at page 83, line 33 skipping to change at page 84, line 22
[I-D.ietf-dots-data-channel] [I-D.ietf-dots-data-channel]
Boucadair, M., Reddy, T., Nishizuka, K., Xia, L., Patil, Boucadair, M., Reddy, T., Nishizuka, K., Xia, L., Patil,
P., Mortensen, A., and N. Teague, "Distributed Denial-of- P., Mortensen, A., and N. Teague, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Data Channel Service Open Threat Signaling (DOTS) Data Channel
Specification", draft-ietf-dots-data-channel-18 (work in Specification", draft-ietf-dots-data-channel-18 (work in
progress), July 2018. progress), July 2018.
[I-D.ietf-dots-requirements] [I-D.ietf-dots-requirements]
Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed
Denial of Service (DDoS) Open Threat Signaling Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-14 (work in Requirements", draft-ietf-dots-requirements-15 (work in
progress), February 2018. progress), August 2018.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
Open Threat Signaling", draft-ietf-dots-use-cases-16 (work Open Threat Signaling", draft-ietf-dots-use-cases-16 (work
in progress), July 2018. in progress), July 2018.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
 End of changes. 57 change blocks. 
89 lines changed or deleted 151 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/