Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
draft-ietf-dots-signal-channel-11
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8782.
|
|
|---|---|---|---|
| Authors | Tirumaleswar Reddy.K , Mohamed Boucadair , Prashanth Patil , Andrew Mortensen , Nik Teague | ||
| Last updated | 2017-12-06 | ||
| Replaces | draft-reddy-dots-signal-channel | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 8782 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-dots-signal-channel-11
#x27;.
Values are taken from the IANA protocol registry:
https://www.iana.org/assignments/protocol-numbers/
protocol-numbers.xhtml
Reddy, et al. Expires June 8, 2018 [Page 45]
Internet-Draft DOTS Signal Channel December 2017
For example, 6 for a TCP or 17 for UDP.";
}
leaf-list target-fqdn {
type inet:domain-name;
description "FQDN identifying the target.";
}
leaf-list target-uri {
type inet:uri;
description "URI identifying the target.";
}
leaf-list alias-name {
type string;
description "alias name";
}
}
grouping mitigation-scope {
description
"Specifies the scope of the mitigation request.";
leaf-list client-identifier {
type binary;
description
"The client identifier may be conveyed by
the DOTS gateway to propagate the DOTS client
identity from the gateway's client-side to the
gateway's server-side, and from the gateway's
server-side to the DOTS server.
It allows the final DOTS server to accept
mitigation requests with scopes which the DOTS
client is authorized to manage.";
}
list scope {
key mitigation-id;
description
"The scope of the request.";
leaf mitigation-id {
type int32;
description
"Mitigation request identifier.
This identifier must be unique for each mitigation
Reddy, et al. Expires June 8, 2018 [Page 46]
Internet-Draft DOTS Signal Channel December 2017
request bound to the DOTS client.";
}
uses target;
leaf lifetime {
type int32;
units "seconds";
default 3600;
description
"Indicates the lifetime of the mitigation request.";
reference
"RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel";
}
leaf mitigation-start {
type int64;
units "seconds";
description
"Mitigation start time is represented in seconds
relative to 1970-01-01T00:00Z in UTC time.";
}
leaf status {
type enumeration {
enum "1" {
description
"Attack mitigation is in progress (e.g., changing
the network path to re-route the inbound traffic
to DOTS mitigator).";
}
enum "2" {
description
"Attack is successfully mitigated (e.g., traffic
is redirected to a DDOS mitigator and attack
traffic is dropped).";
}
enum "3" {
description
"Attack has stopped and the DOTS client can
withdraw the mitigation request.";
}
enum "4" {
Reddy, et al. Expires June 8, 2018 [Page 47]
Internet-Draft DOTS Signal Channel December 2017
description
"Attack has exceeded the mitigation provider
capability.";
}
enum "5" {
description
"DOTS client has withdrawn the mitigation
request and the mitigation is active but
terminating.";
}
enum "6" {
description
"Attack mitigation is now terminated.";
}
enum "7" {
description
"Attack mitigation is withdrawn.";
}
enum "8" {
description
"Attack mitigation is rejected.";
}
}
config false;
description
"Indicates the status of a mitigation request.
It must be included in responses, only.";
}
container conflict-information {
config false;
description
"Indicates that a conflict is detected.
Must only be used for responses.";
leaf conflict-status {
type enumeration {
enum "1" {
description
"DOTS Server has detected conflicting mitigation
requests from different DOTS clients.
This mitigation request is currently inactive
until the conflicts are resolved. Another
mitigation request is active.";
Reddy, et al. Expires June 8, 2018 [Page 48]
Internet-Draft DOTS Signal Channel December 2017
}
enum "2" {
description
"DOTS Server has detected conflicting mitigation
requests from different DOTS clients.
This mitigation request is currently active.";
}
enum "3" {
description
"DOTS Server has detected conflicting mitigation
requests from different DOTS clients. All
conflicting mitigation requests are inactive.";
}
}
description
"Indicates the conflict status.
It must be included in responses, only.";
}
leaf conflict-cause {
type enumeration {
enum "1" {
description
"Overlapping targets. conflict-scope provides
more details about the exact conflict.";
}
enum "2" {
description
"Conflicts with an existing white list.
This code is returned when the DDoS mitigation
detects source addresses/prefixes in the
white-listed ACLs are attacking the target.";
}
}
description
"Indicates the cause of the conflict.
It must be included in responses, only.";
}
leaf retry-timer {
type int32;
units "seconds";
description
"The DOTS client must not re-send the
Reddy, et al. Expires June 8, 2018 [Page 49]
Internet-Draft DOTS Signal Channel December 2017
same request before the expiry of this timer.
It must be included in responses, only.";
}
container conflict-scope {
description
"Provides more information about the conflict scope.";
uses target;
}
}
leaf pkts-dropped {
type yang:zero-based-counter64;
config false;
description
"Number of dropped packets";
}
leaf bps-dropped {
type yang:zero-based-counter64;
config false;
description
"The average dropped bytes per second for
the mitigation request since the attack
mitigation is triggered.";
}
leaf bytes-dropped {
type yang:zero-based-counter64;
units 'bytes';
config false;
description
"Counter for dropped pacckets; in bytes.";
}
leaf pps-dropped {
type yang:zero-based-counter64;
config false;
description
"The average dropped packets per second
for the mitigation request since the attack
mitigation is triggered.";
}
}
}
grouping signal-config {
description
Reddy, et al. Expires June 8, 2018 [Page 50]
Internet-Draft DOTS Signal Channel December 2017
"DOTS signal channel session configuration.";
leaf session-id {
type int32;
mandatory true;
description
"An identifier for the DOTS signal channel
session configuration data.";
}
leaf heartbeat-interval {
type int16;
units "seconds";
default 30;
description
"DOTS agents regularly send heartbeats to each other
after mutual authentication in order to keep
the DOTS signal channel open.";
reference
"RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel";
}
leaf missing-hb-allowed {
type int16;
default 5;
description
"Maximum number of missing heartbeats allowed.";
reference
"RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel";
}
leaf max-retransmit {
type int16;
default 3;
description
"Maximum number of retransmissions of a
Confirmable message.";
reference
"RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel";
}
leaf ack-timeout {
type int16;
units "seconds";
default 2;
Reddy, et al. Expires June 8, 2018 [Page 51]
Internet-Draft DOTS Signal Channel December 2017
description
"Initial retransmission timeout value.";
reference
"Section 4.8 of RFC 7552.";
}
leaf ack-random-factor {
type decimal64 {
fraction-digits 2;
}
default 1.5;
description
"Random factor used to influence the timing of
retransmissions.";
reference
"Section 4.8 of RFC 7552.";
}
leaf trigger-mitigation {
type boolean;
default true;
description
"If false, then mitigation is triggered
only when the DOTS server channel session is lost";
reference
"RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel";
}
}
container dots-signal {
description
"Main contaner for DOTS signal message.
A DOTS signal message can be a mitigation messages or
a configuration message.";
choice message-type {
description
"Either a mitigation or a configuration message.";
case mitigation-scope {
description
"Mitigation scope of a mitigation message.";
uses mitigation-scope;
}
case configuration {
description
Reddy, et al. Expires June 8, 2018 [Page 52]
Internet-Draft DOTS Signal Channel December 2017
"Configuration message.";
uses signal-config;
}
}
}
}
<CODE ENDS>
6. Mapping Parameters to CBOR
All parameters in the payload in the DOTS signal channel MUST be
mapped to CBOR types as shown in Table 4 and are given an integer key
to save space. The recipient of the payload MAY reject the
information if it is not suitably mapped.
Reddy, et al. Expires June 8, 2018 [Page 53]
Internet-Draft DOTS Signal Channel December 2017
/----------------------+----------------+--------------------------\
| Parameter name | CBOR key | CBOR major type of value |
+----------------------+----------------+--------------------------+
| mitigation-scope | 1 | 5 (map) |
| scope | 2 | 5 (map) |
| mitigation-id | 3 | 0 (unsigned) |
| target-ip | 4 | 4 (array) |
| target-port-range | 5 | 4 |
| lower-port | 6 | 0 |
| upper-port | 7 | 0 |
| target-protocol | 8 | 4 |
| target-fqdn | 9 | 4 |
| target-uri | 10 | 4 |
| alias-name | 11 | 4 |
| lifetime | 12 | 0 |
| attack-status | 13 | 0 |
| signal-config | 14 | 5 |
| heartbeat-interval | 15 | 0 |
| max-retransmit | 16 | 0 |
| ack-timeout | 17 | 0 |
| ack-random-factor | 18 | 7 |
| MinValue | 19 | 0 |
| MaxValue | 20 | 0 |
| status | 21 | 0 |
| conflict-information | 22 | 5 (map) |
| conflict-status | 23 | 0 |
| conflict-cause | 24 | 0 |
| retry-timer | 25 | 0 |
| bytes-dropped | 26 | 0 |
| bps-dropped | 27 | 0 |
| pkts-dropped | 28 | 0 |
| pps-dropped | 29 | 0 |
| session-id | 30 | 0 |
| trigger-mitigation | 31 | 7 (simple types) |
| missing-hb-allowed | 32 | 0 |
| CurrentValue | 33 | 0 |
| mitigation-start | 34 | 7 (floating-point) |
| target-prefix | 35 | 4 (array) |
| client-identifier | 36 | 2 (byte string) |
| alt-server | 37 | 2 |
| alt-server-record | 38 | 4 |
| addr | 39 | 2 |
| ttl | 40 | 0 |
\----------------------+----------------+--------------------------/
Table 4: CBOR mappings used in DOTS signal channel message
Reddy, et al. Expires June 8, 2018 [Page 54]
Internet-Draft DOTS Signal Channel December 2017
7. (D)TLS Protocol Profile and Performance Considerations
7.1. (D)TLS Protocol Profile
This section defines the (D)TLS protocol profile of DOTS signal
channel over (D)TLS and DOTS data channel over TLS.
There are known attacks on (D)TLS, such as machine-in-the-middle and
protocol downgrade. These are general attacks on (D)TLS and not
specific to DOTS over (D)TLS; please refer to the (D)TLS RFCs for
discussion of these security issues. DOTS agents MUST adhere to the
(D)TLS implementation recommendations and security considerations of
[RFC7525] except with respect to (D)TLS version. Since encryption of
DOTS using (D)TLS is virtually a green-field deployment DOTS agents
MUST implement only (D)TLS 1.2 or later.
When a DOTS client is configured with a domain name of the DOTS
server, and connects to its configured DOTS server, the server may
present it with a PKIX certificate. In order to ensure proper
authentication, DOTS client MUST verify the entire certification path
per [RFC5280]. The DOTS client additionaly uses [RFC6125] validation
techniques to compare the domain name to the certificate provided.
A key challenge to deploying DOTS is provisioning DOTS clients,
including the distribution of keying material to DOTS clients to make
possible the required mutual authentication of DOTS agents. EST
defines a method of certificate enrollment by which domains operating
DOTS servers may provision DOTS clients with all necessary
cryptographic keying material, including a private key and
certificate with which to authenticate itself. One deployment option
is DOTS clients to behave as EST clients for certificate enrollment
from an EST server provisioned by the mitigation provider. This
document does not specify which EST mechanism the DOTS client uses to
achieve initial enrollment.
Implementations compliant with this profile MUST implement all of the
following items:
o DTLS record replay detection (Section 3.3 of [RFC6347]) to protect
against replay attacks.
o (D)TLS session resumption without server-side state [RFC5077] to
resume session and convey the DOTS signal.
o Raw public keys [RFC7250] or PSK handshake [RFC4279] which reduce
the size of the ServerHello, and can be used by DOTS agents that
cannot obtain certificates (e.g., DOTS clients and DOTS gateways
on private networks).
Reddy, et al. Expires June 8, 2018 [Page 55]
Internet-Draft DOTS Signal Channel December 2017
Implementations compliant with this profile SHOULD implement all of
the following items to reduce the delay required to deliver a DOTS
signal:
o TLS False Start [RFC7918] which reduces round-trips by allowing
the TLS second flight of messages (ChangeCipherSpec) to also
contain the DOTS signal.
o Cached Information Extension [RFC7924] which avoids transmitting
the server's certificate and certificate chain if the client has
cached that information from a previous TLS handshake.
o TCP Fast Open [RFC7413] can reduce the number of round-trips to
convey DOTS signal.
7.2. (D)TLS 1.3 Considerations
TLS 1.3 [I-D.ietf-tls-tls13] provides critical latency improvements
for connection establishment over TLS 1.2. The DTLS 1.3 protocol
[I-D.ietf-tls-dtls13] is based on the TLS 1.3 protocol and provides
equivalent security guarantees. (D)TLS 1.3 provides two basic
handshake modes of interest to DOTS signal channel:
o Absent packet loss, a full handshake in which the DOTS client is
able to send the DOTS signal message after one round trip and the
DOTS server immediately after receiving the first DOTS signal
message from the client.
o 0-RTT mode in which the DOTS client can authenticate itself and
send DOTS signal message on its first flight, thus reducing
handshake latency. 0-RTT only works if the DOTS client has
previously communicated with that DOTS server, which is very
likely with the DOTS signal channel. The DOTS client SHOULD
establish a (D)TLS session with the DOTS server during peacetime
and share a PSK. During DDOS attack, the DOTS client can use the
(D)TLS session to convey the DOTS signal message and if there is
no response from the server after multiple re-tries then the DOTS
client can resume the (D)TLS session in 0-RTT mode using PSK. A
simplified TLS 1.3 handshake with 0-RTT DOTS signal message
exchange is shown in Figure 23.
Reddy, et al. Expires June 8, 2018 [Page 56]
Internet-Draft DOTS Signal Channel December 2017
DOTS Client DOTS Server
ClientHello
(Finished)
(0-RTT DOTS signal message)
(end_of_early_data) -------->
ServerHello
{EncryptedExtensions}
{ServerConfiguration}
{Certificate}
{CertificateVerify}
{Finished}
<-------- [DOTS signal message]
{Finished} -------->
[DOTS signal message] <-------> [DOTS signal message]
Figure 23: TLS 1.3 handshake with 0-RTT
7.3. MTU and Fragmentation
To avoid DOTS signal message fragmentation and the consequently
decreased probability of message delivery, DOTS agents MUST ensure
that the DTLS record MUST fit within a single datagram. If the path
MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD
be assumed. The length of the URL MUST NOT exceed 256 bytes. If UDP
is used to convey the DOTS signal messages then the DOTS client must
consider the amount of record expansion expected by the DTLS
processing when calculating the size of CoAP message that fits within
the path MTU. Path MTU MUST be greater than or equal to [CoAP
message size + DTLS overhead of 13 octets + authentication overhead
of the negotiated DTLS cipher suite + block padding (Section 4.1.1.1
of [RFC6347]). If the request size exceeds the path MTU then the
DOTS client MUST split the DOTS signal into separate messages, for
example the list of addresses in the 'target-ip' parameter could be
split into multiple lists and each list conveyed in a new PUT
request.
Implementation Note: DOTS choice of message size parameters works
well with IPv6 and with most of today's IPv4 paths. However, with
IPv4, it is harder to absolutely ensure that there is no IP
fragmentation. If IPv4 support on unusual networks is a
consideration and path MTU is unknown, implementations may want to
limit themselves to more conservative IPv4 datagram sizes such as 576
bytes, as per [RFC0791] IP packets up to 576 bytes should never need
to be fragmented, thus sending a maximum of 500 bytes of DOTS signal
over a UDP datagram will generally avoid IP fragmentation.
Reddy, et al. Expires June 8, 2018 [Page 57]
Internet-Draft DOTS Signal Channel December 2017
8. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients
(D)TLS based on client certificate can be used for mutual
authentication between DOTS agents. If a DOTS gateway is involved,
DOTS clients and DOTS gateway MUST perform mutual authentication;
only authorized DOTS clients are allowed to send DOTS signals to a
DOTS gateway. DOTS gateway and DOTS server MUST perform mutual
authentication; DOTS server only allows DOTS signals from authorized
DOTS gateway, creating a two-link chain of transitive authentication
between the DOTS client and the DOTS server.
+-----------------------------------------------+
| example.com domain +---------+ |
| | AAA | |
| +---------------+ | Server | |
| | Application | +------+--+ |
| | server +<-----------------+ ^ |
| | (DOTS client) | | | |
| +---------------+ | | |
| V V | example.net domain
| +-----+----+--+ | +---------------+
| +--------------+ | | | | |
| | Guest +<-----x----->+ DOTS +<------>+ DOTS |
| | (DOTS client)| | Gateway | | | Server |
| +--------------+ | | | | |
| +----+--------+ | +---------------+
| ^ |
| | |
| +----------------+ | |
| | DDOS detector | | |
| | (DOTS client) +<---------------+ |
| +----------------+ |
+-----------------------------------------------+
Figure 24: Example of Authentication and Authorization of DOTS Agents
In the example depicted in Figure 24, the DOTS gateway and DOTS
clients within the 'example.com' domain mutually authenticate with
each other. After the DOTS gateway validates the identity of a DOTS
client, it communicates with the AAA server in the 'example.com'
domain to determine if the DOTS client is authorized to request DDOS
mitigation. If the DOTS client is not authorized, a 4.01
(Unauthorized) is returned in the response to the DOTS client. In
this example, the DOTS gateway only allows the application server and
DDOS detector to request DDOS mitigation, but does not permit the
user of type 'guest' to request DDOS mitigation.
Reddy, et al. Expires June 8, 2018 [Page 58]
Internet-Draft DOTS Signal Channel December 2017
Also, DOTS gateway and DOTS server located in different domains MUST
perform mutual authentication (e.g., using certificates). A DOTS
server will only allow a DOTS gateway with a certificate for a
particular domain to request mitigation for that domain. In
reference to Figure 24, the DOTS server only allows the DOTS gateway
to request mitigation for 'example.com' domain and not for other
domains.
9. IANA Considerations
This specification registers a service port (Section 9.1), an URI
suffix in the Well-Known URIs registry (Section 9.2), a CoAP response
code (Section 9.3), a YANG module (Section 9.5). It also creates a
registry for mappings to CBOR (Section 9.4).
9.1. DOTS Signal Channel UDP and TCP Port Number
IANA is requested to assign the port number TBD to the DOTS signal
channel protocol for both UDP and TCP from the "Service Name and
Transport Protocol Port Number Registry" available at
https://www.iana.org/assignments/service-names-port-numbers/service-
names-port-numbers.xhtml.
It is strongly suggested that the port number 4646 is to be assigned.
4646 is the ASCII decimal value for ".." (DOTS).
9.2. Well-Known 'dots' URI
This document requests IANA to register the 'dots' well-known URI in
the Well-Known URIs registry (https://www.iana.org/assignments/well-
known-uris/well-known-uris.xhtml) as defined by [RFC5785].
URI suffix: dots
Change controller: IETF
Specification document(s): This RFC
Related information: None
9.3. CoAP Response Code
IANA is requested to add the following entry to the "CoAP Response
Codes" sub-registry available at https://www.iana.org/assignments/
core-parameters/core-parameters.xhtml#response-codes:
Reddy, et al. Expires June 8, 2018 [Page 59]
Internet-Draft DOTS Signal Channel December 2017
+------+------------------+-----------+
| Code | Description | Reference |
+------+------------------+-----------+
| 3.00 | Alternate server | [RFCXXXX] |
+------+------------------+-----------+
Table 4: CoAP Response Code
9.4. DOTS Signal Channel CBOR Mappings Registry
The document requests IANA to create a new registry, entitled "DOTS
Signal Channel CBOR Mappings Registry". The structrue of this
registry is provided in Section 9.4.1.
The registry is initially populated with the values in Section 9.4.2.
Values from that registry MUST be assigned via Expert Review
[RFC8126].
9.4.1. Registration Template
Parameter name:
Parameter names (e.g., "target_ip") in the DOTS signal channel.
CBOR Key Value:
Key value for the parameter. The key value MUST be an integer in
the range of 1 to 65536. The key values in the range of 32768 to
65536 are assigned for Vendor-Specific parameters.
CBOR Major Type:
CBOR Major type and optional tag for the claim.
Change Controller:
For Standards Track RFCs, list the "IESG". For others, give the
name of the responsible party. Other details (e.g., postal
address, email address, home page URI) 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.4.2. Initial Registry Contents
o Parameter Name: "mitigation-scope"
o CBOR Key Value: 1
o CBOR Major Type: 5
Reddy, et al. Expires June 8, 2018 [Page 60]
Internet-Draft DOTS Signal Channel December 2017
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: "scope"
o CBOR Key Value: 2
o CBOR Major Type: 5
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: "mitigation-id"
o CBOR Key Value: 3
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name:target-ip
o CBOR Key Value: 4
o CBOR Major Type: 4
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: target-port-range
o CBOR Key Value: 5
o CBOR Major Type: 4
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: "lower-port"
o CBOR Key Value: 6
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: "upper-port"
o CBOR Key Value: 7
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: target-protocol
o CBOR Key Value: 8
o CBOR Major Type: 4
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: "target-fqdn"
o CBOR Key Value: 9
o CBOR Major Type: 4
Reddy, et al. Expires June 8, 2018 [Page 61]
Internet-Draft DOTS Signal Channel December 2017
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: "target-uri"
o CBOR Key Value: 10
o CBOR Major Type: 4
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: alias-name
o CBOR Key Value: 11
o CBOR Major Type: 4
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: "lifetime"
o CBOR Key Value: 12
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: attack-status
o CBOR Key Value: 13
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: signal-config
o CBOR Key Value: 14
o CBOR Major Type: 5
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: heartbeat-interval
o CBOR Key Value: 15
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: max-retransmit
o CBOR Key Value: 16
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: ack-timeout
o CBOR Key Value: 17
o CBOR Major Type: 0
Reddy, et al. Expires June 8, 2018 [Page 62]
Internet-Draft DOTS Signal Channel December 2017
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: ack-random-factor
o CBOR Key Value: 18
o CBOR Major Type: 7
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: MinValue
o CBOR Key Value: 19
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: MaxValue
o CBOR Key Value: 20
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: status
o CBOR Key Value: 21
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: conflict-information
o CBOR Key Value: 22
o CBOR Major Type: 5
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: conflict-status
o CBOR Key Value: 23
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: conflict-cause
o CBOR Key Value: 24
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: retry-timer
o CBOR Key Value: 25
o CBOR Major Type: 0
Reddy, et al. Expires June 8, 2018 [Page 63]
Internet-Draft DOTS Signal Channel December 2017
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: bytes-dropped
o CBOR Key Value: 26
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: bps-dropped
o CBOR Key Value: 27
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: pkts-dropped
o CBOR Key Value: 28
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: pps-dropped
o CBOR Key Value: 29
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: session-id
o CBOR Key Value: 30
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: trigger-mitigation
o CBOR Key Value: 31
o CBOR Major Type: 7
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: missing-hb-allowed
o CBOR Key Value: 32
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: CurrentValue
o CBOR Key Value: 33
o CBOR Major Type: 0
Reddy, et al. Expires June 8, 2018 [Page 64]
Internet-Draft DOTS Signal Channel December 2017
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name:mitigation-start
o CBOR Key Value: 34
o CBOR Major Type: 7
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name:target-prefix
o CBOR Key Value: 35
o CBOR Major Type: 4
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name:client-identifier
o CBOR Key Value: 36
o CBOR Major Type: 2
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name:alt-server
o CBOR Key Value: 37
o CBOR Major Type: 2
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name:alt-server-record
o CBOR Key Value: 38
o CBOR Major Type: 4
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name:addr
o CBOR Key Value: 39
o CBOR Major Type: 2
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name:ttl
o CBOR Key Value: 40
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
Reddy, et al. Expires June 8, 2018 [Page 65]
Internet-Draft DOTS Signal Channel December 2017
9.5. DOTS Signal Channel YANG Module
This document requests IANA to register the following URI in the
"IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG module in
the "YANG Module Names" registry [RFC7950].
name: ietf-signal
namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal
prefix: signal
reference: RFC XXXX
10. Implementation Status
[Note to RFC Editor: Please remove this section and reference to
[RFC7942] prior to publication.]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
10.1. nttdots
Organization: NTT Communication is developing a DOTS client and
DOTS server software based on DOTS signal channel specified in
this draft. It will be open-sourced.
Reddy, et al. Expires June 8, 2018 [Page 66]
Internet-Draft DOTS Signal Channel December 2017
Description: Early implementation of DOTS protocol. It is aimed to
implement a full DOTS protocol spec in accordance with maturing of
DOTS protocol itself.
Implementation: https://github.com/nttdots/go-dots
Level of maturity: It is a early implementation of DOTS protocol.
Messaging between DOTS clients and DOTS servers has been tested.
Level of maturity will increase in accordance with maturing of
DOTS protocol itself.
Coverage: Capability of DOTS client: sending DOTS messages to the
DOTS server in CoAP over DTLS as dots-signal. Capability of DOTS
server: receiving dots-signal, validating received dots-signal,
starting mitigation by handing over the dots-signal to DDOS
mitigator.
Licensing: It will be open-sourced with BSD 3-clause license.
Implementation experience: It is implemented in Go-lang. Core
specification of signaling is mature to be implemented, however,
finding good libraries(like DTLS, CoAP) is rather difficult.
Contact: Kaname Nishizuka <kaname@nttv6.jp>
11. Security Considerations
Authenticated encryption MUST be used for data confidentiality and
message integrity. The interaction between the DOTS agents requires
Datagram Transport Layer Security (DTLS) and 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.
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 client SHOULD re-use the (D)TLS session.
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-AO [RFC5925]. 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.
In order to prevent leaking internal information outside a client-
domain, DOTS gateways located in the client-domain SHOULD NOT reveal
the identity of internal DOTS clients (client-identifier) unless
explicitly configured to do so.
Special care should be taken in order to ensure that the activation
of the proposed mechanism won't have an impact on the stability of
Reddy, et al. Expires June 8, 2018 [Page 67]
Internet-Draft DOTS Signal Channel December 2017
the network (including connectivity and services delivered over that
network).
Involved functional elements in the cooperation system must establish
exchange instructions and notification over a secure and
authenticated channel. Adequate filters can be enforced to avoid
that nodes outside a trusted domain can inject request such as
deleting filtering rules. Nevertheless, attacks can be initiated
from within the trusted domain if an entity has been corrupted.
Adequate means to monitor trusted nodes should also be enabled.
12. Contributors
The following individuals have contributed to this document:
Mike Geller Cisco Systems, Inc. 3250 Florida 33309 USA Email:
mgeller@cisco.com
Robert Moskowitz HTT Consulting Oak Park, MI 42837 United States
Email: rgm@htt-consult.com
Dan Wing Email: dwing-ietf@fuggles.com
13. Acknowledgements
Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw,
Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang
Xia, Jon Shallow, Gilbert Clark, and Nesredien Suleiman for the
discussion and comments.
14. References
14.1. Normative References
[I-D.ietf-core-coap-tcp-tls]
Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
draft-ietf-core-coap-tcp-tls-10 (work in progress),
October 2017.
[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>.
Reddy, et al. Expires June 8, 2018 [Page 68]
Internet-Draft DOTS Signal Channel December 2017
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[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>.
[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>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010,
<https://www.rfc-editor.org/info/rfc5785>.
[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>.
[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>.
[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>.
[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>.
Reddy, et al. Expires June 8, 2018 [Page 69]
Internet-Draft DOTS Signal Channel December 2017
[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>.
[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>.
[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>.
[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and
FETCH Methods for the Constrained Application Protocol
(CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
<https://www.rfc-editor.org/info/rfc8132>.
14.2. Informative References
[I-D.ietf-core-comi]
Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP
Management Interface", draft-ietf-core-comi-01 (work in
progress), July 2017.
[I-D.ietf-core-yang-cbor]
Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A.
Minaburo, "CBOR Encoding of Data Modeled with YANG",
draft-ietf-core-yang-cbor-05 (work in progress), August
2017.
Reddy, et al. Expires June 8, 2018 [Page 70]
Internet-Draft DOTS Signal Channel December 2017
[I-D.ietf-dots-architecture]
Mortensen, A., Andreasen, F., Reddy, T.,
christopher_gray3@cable.comcast.com, c., Compton, R., and
N. Teague, "Distributed-Denial-of-Service Open Threat
Signaling (DOTS) Architecture", draft-ietf-dots-
architecture-05 (work in progress), October 2017.
[I-D.ietf-dots-data-channel]
Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil,
P., Mortensen, A., and N. Teague, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Data Channel", draft-
ietf-dots-data-channel-08 (work in progress), November
2017.
[I-D.ietf-dots-requirements]
Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed
Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-07 (work in
progress), October 2017.
[I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
Open Threat Signaling", draft-ietf-dots-use-cases-09 (work
in progress), November 2017.
[I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-02 (work in progress),
October 2017.
[I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-22 (work in progress),
November 2017.
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
July 2017.
[proto_numbers]
"IANA, "Protocol Numbers"", 2011,
<http://www.iana.org/assignments/protocol-numbers>.
Reddy, et al. Expires June 8, 2018 [Page 71]
Internet-Draft DOTS Signal Channel December 2017
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[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>.
[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>.
[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>.
[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>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <https://www.rfc-editor.org/info/rfc6555>.
Reddy, et al. Expires June 8, 2018 [Page 72]
Internet-Draft DOTS Signal Channel December 2017
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[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>.
Reddy, et al. Expires June 8, 2018 [Page 73]
Internet-Draft DOTS Signal Channel December 2017
Authors' Addresses
Tirumaleswar Reddy
McAfee, Inc.
Embassy Golf Link Business Park
Bangalore, Karnataka 560071
India
Email: kondtir@gmail.com
Mohamed Boucadair
Orange
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Prashanth Patil
Cisco Systems, Inc.
Email: praspati@cisco.com
Andrew Mortensen
Arbor Networks, Inc.
2727 S. State St
Ann Arbor, MI 48104
United States
Email: amortensen@arbor.net
Nik Teague
Verisign, Inc.
United States
Email: nteague@verisign.com
Reddy, et al. Expires June 8, 2018 [Page 74]