< draft-ietf-dots-signal-channel-02.txt   draft-ietf-dots-signal-channel-03.txt >
DOTS T. Reddy DOTS T. Reddy
Internet-Draft McAfee Internet-Draft McAfee
Intended status: Standards Track M. Boucadair Intended status: Standards Track M. Boucadair
Expires: December 23, 2017 Orange Expires: February 17, 2018 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.
June 21, 2017 August 16, 2017
Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel Channel
draft-ietf-dots-signal-channel-02 draft-ietf-dots-signal-channel-03
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. A companion traffic mitigation on behalf of the requesting client. A companion
document defines the DOTS data channel, a separate reliable document defines the DOTS data channel, a separate reliable
communication layer for DOTS management and configuration. communication layer for DOTS management and configuration.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 December 23, 2017. This Internet-Draft will expire on February 17, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 2, line 28 skipping to change at page 2, line 28
2. Notational Conventions and Terminology . . . . . . . . . . . 3 2. Notational Conventions and Terminology . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . . . 5 4. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . . . 5
5. DOTS Signal Channel . . . . . . . . . . . . . . . . . . . . . 7 5. DOTS Signal Channel . . . . . . . . . . . . . . . . . . . . . 7
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. DOTS Signal YANG Model . . . . . . . . . . . . . . . . . 8 5.2. DOTS Signal YANG Model . . . . . . . . . . . . . . . . . 8
5.2.1. Mitigation Request Model structure . . . . . . . . . 8 5.2.1. Mitigation Request Model structure . . . . . . . . . 8
5.2.2. Mitigation Request Model . . . . . . . . . . . . . . 8 5.2.2. Mitigation Request Model . . . . . . . . . . . . . . 8
5.2.3. Session Configuration Model structure . . . . . . . . 10 5.2.3. Session Configuration Model structure . . . . . . . . 10
5.2.4. Session Configuration Model . . . . . . . . . . . . . 10 5.2.4. Session Configuration Model . . . . . . . . . . . . . 10
5.3. Mitigation Request . . . . . . . . . . . . . . . . . . . 11 5.3. Mitigation Request . . . . . . . . . . . . . . . . . . . 12
5.3.1. Requesting mitigation . . . . . . . . . . . . . . . . 12 5.3.1. Requesting mitigation . . . . . . . . . . . . . . . . 12
5.3.2. Withdraw a DOTS Signal . . . . . . . . . . . . . . . 17 5.3.2. Withdraw a DOTS Signal . . . . . . . . . . . . . . . 17
5.3.3. Retrieving a DOTS Signal . . . . . . . . . . . . . . 18 5.3.3. Retrieving a DOTS Signal . . . . . . . . . . . . . . 18
5.3.4. Efficacy Update from DOTS Client . . . . . . . . . . 23 5.3.4. Efficacy Update from DOTS Client . . . . . . . . . . 23
5.4. DOTS Signal Channel Session Configuration . . . . . . . . 25 5.4. DOTS Signal Channel Session Configuration . . . . . . . . 25
5.4.1. Discover Acceptable Configuration Parameters . . . . 26 5.4.1. Discover Acceptable Configuration Parameters . . . . 26
5.4.2. Convey DOTS Signal Channel Session Configuration . . 27 5.4.2. Convey DOTS Signal Channel Session Configuration . . 27
5.4.3. Delete DOTS Signal Channel Session Configuration . . 29 5.4.3. Delete DOTS Signal Channel Session Configuration . . 30
5.4.4. Retrieving DOTS Signal Channel Session Configuration 29 5.4.4. Retrieving DOTS Signal Channel Session Configuration 30
5.5. Redirected Signaling . . . . . . . . . . . . . . . . . . 30 5.5. Redirected Signaling . . . . . . . . . . . . . . . . . . 31
5.6. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 31 5.6. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 32
6. Mapping parameters to CBOR . . . . . . . . . . . . . . . . . 32 6. Mapping parameters to CBOR . . . . . . . . . . . . . . . . . 33
7. (D)TLS Protocol Profile and Performance considerations . . . 32 7. (D)TLS Protocol Profile and Performance considerations . . . 34
7.1. MTU and Fragmentation Issues . . . . . . . . . . . . . . 33 7.1. MTU and Fragmentation Issues . . . . . . . . . . . . . . 34
8. (D)TLS 1.3 considerations . . . . . . . . . . . . . . . . . . 34 8. (D)TLS 1.3 considerations . . . . . . . . . . . . . . . . . . 35
9. Mutual Authentication of DOTS Agents & Authorization of DOTS 9. Mutual Authentication of DOTS Agents & Authorization of DOTS
Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
10.1. DOTS signal channel CBOR Mappings Registry . . . . . . . 37 10.1. CoAP Response Code . . . . . . . . . . . . . . . . . . . 38
10.1.1. Registration Template . . . . . . . . . . . . . . . 37 10.2. DOTS signal channel CBOR Mappings Registry . . . . . . . 38
10.1.2. Initial Registry Contents . . . . . . . . . . . . . 37 10.2.1. Registration Template . . . . . . . . . . . . . . . 38
11. Implementation Status . . . . . . . . . . . . . . . . . . . . 41 10.2.2. Initial Registry Contents . . . . . . . . . . . . . 39
11.1. nttdots . . . . . . . . . . . . . . . . . . . . . . . . 41 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 42
12. Security Considerations . . . . . . . . . . . . . . . . . . . 42 11.1. nttdots . . . . . . . . . . . . . . . . . . . . . . . . 43
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 12. Security Considerations . . . . . . . . . . . . . . . . . . . 43
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 44
15.1. Normative References . . . . . . . . . . . . . . . . . . 43 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44
15.2. Informative References . . . . . . . . . . . . . . . . . 44 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 15.1. Normative References . . . . . . . . . . . . . . . . . . 44
15.2. Informative References . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
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 5, line 13 skipping to change at page 5, line 13
Figure 1: Sample DOTS Deployment (1) Figure 1: Sample DOTS Deployment (1)
The DOTS server can also be running on the Internet, as depicted in The DOTS server can also be running on the Internet, as depicted in
Figure 2. Figure 2.
Network DDoS mitigation Network DDoS mitigation
Resource CPE router __________ service Resource CPE router __________ service
+-----------+ +-------------+ / \ +-------------+ +-----------+ +-------------+ / \ +-------------+
| |____| |_______| |___ | | | |____| |_______| |___ | |
|DOTS client| |DOTS gateway | | Internet | | DOTS server | |DOTS client| |DOTS gateway | | Internet | | DOTS server |
| | | | | | | | | | | | | | | | |
+-----------+ +-------------+ \__________/ +-------------+ +-----------+ +-------------+ \__________/ +-------------+
Figure 2: Sample DOTS Deployment (2) Figure 2: Sample DOTS Deployment (2)
In typical deployments, the DOTS client belongs to a different In typical deployments, the DOTS client belongs to a different
administrative domain than the DOTS server. For example, the DOTS administrative domain than the DOTS server. For example, the DOTS
client is a firewall protecting services owned and operated by an client is a firewall protecting services owned and operated by an
domain, while the DOTS server is owned and operated by a different domain, while the DOTS server is owned and operated by a different
domain providing DDoS mitigation services. That domain providing domain providing DDoS mitigation services. That domain providing
DDoS mitigation service might, or might not, also provide Internet DDoS mitigation service might, or might not, also provide Internet
skipping to change at page 8, line 18 skipping to change at page 8, line 18
scope and DOTS signal channel session configuration data. scope and DOTS signal channel session configuration data.
5.2.1. Mitigation Request Model structure 5.2.1. Mitigation Request Model structure
This document defines the YANG module "ietf-dots-signal", which has This document defines the YANG module "ietf-dots-signal", which has
the following structure: the following structure:
module: ietf-dots-signal module: ietf-dots-signal
+--rw mitigation-scope +--rw mitigation-scope
+--rw scope* [mitigation-id] +--rw scope* [mitigation-id]
+--rw mitigation-id int32 +--rw mitigation-id int32
+--rw target-ip* inet:ip-address +--rw target-ip* inet:ip-address
+--rw target-prefix* inet:ip-prefix +--rw target-prefix* inet:ip-prefix
+--rw target-port-range* [lower-port upper-port] +--rw target-port-range* [lower-port upper-port]
| +--rw lower-port inet:port-number | +--rw lower-port inet:port-number
| +--rw upper-port inet:port-number | +--rw upper-port inet:port-number
+--rw target-protocol* uint8 +--rw target-protocol* uint8
+--rw fqdn* inet:domain-name +--rw fqdn* inet:domain-name
+--rw uri* inet:uri +--rw uri* inet:uri
+--rw alias* string +--rw alias* string
+--rw lifetime? int32 +--rw lifetime? int32
5.2.2. Mitigation Request Model 5.2.2. Mitigation Request Model
<CODE BEGINS> file "ietf-dots-signal@2016-11-28.yang" <CODE BEGINS> file "ietf-dots-signal@2017-08-03.yang"
module ietf-dots-signal { module ietf-dots-signal {
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal"; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal";
prefix "signal"; prefix "signal";
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
} }
organization "McAfee, Inc."; organization "McAfee, Inc.";
contact "Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>"; contact "Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>";
description description
"This module contains YANG definition for DOTS "This module contains YANG definition for DOTS
signal sent by the DOTS client to the DOTS server"; signal sent by the DOTS client to the DOTS server.";
revision 2016-11-28 { revision 2017-08-03 {
reference reference
"https://tools.ietf.org/html/draft-reddy-dots-signal-channel"; "https://tools.ietf.org/html/draft-reddy-dots-signal-channel";
} }
container mitigation-scope { container mitigation-scope {
description "top level container for mitigation request"; description
"Top level container for a mitigation request.";
list scope { list scope {
key mitigation-id; key mitigation-id;
description "Identifier for the mitigation request"; description "Identifier for the mitigation request.";
leaf mitigation-id { leaf mitigation-id {
type int32; type int32;
description "mitigation request identifier"; description "Mitigation request identifier.";
} }
leaf-list target-ip { leaf-list target-ip {
type inet:ip-address; type inet:ip-address;
description "IP address"; description
"IPv4 or IPv6 address identifyting the target.";
} }
leaf-list target-prefix { leaf-list target-prefix {
type inet:ip-prefix; type inet:ip-prefix;
description "prefix"; description
"IPv4 or IPv6 prefix identifyting the target.";
} }
list target-port-range { list target-port-range {
key "lower-port upper-port"; key "lower-port upper-port";
description "Port range. When only lower-port is present, description "Port range. When only lower-port is present,
it represents a single port."; it represents a single port.";
leaf lower-port { leaf lower-port {
type inet:port-number; type inet:port-number;
mandatory true; mandatory true;
description "lower port"; description "Lower port number.";
} }
leaf upper-port { leaf upper-port {
type inet:port-number; type inet:port-number;
must ". >= ../lower-port" { must ". >= ../lower-port" {
error-message error-message
"The upper-port must be greater than or "The upper port number must be greater than or
equal to lower-port"; equal to lower port number.";
} }
description "upper port"; description "Upper port number.";
} }
} }
leaf-list target-protocol { leaf-list target-protocol {
type uint8; type uint8;
description "Internet Protocol number"; description "Identifies the target protocol number.";
} }
leaf-list fqdn { leaf-list fqdn {
type inet:domain-name; type inet:domain-name;
description "FQDN"; description "FQDN";
} }
leaf-list uri { leaf-list uri {
type inet:uri; type inet:uri;
description "URI"; description "URI";
} }
leaf-list alias { leaf-list alias {
type string; type string;
description "alias name"; description "alias name";
} }
leaf lifetime { leaf lifetime {
type int32; type int32;
description "lifetime"; description
"Indicates the lifetime of the mitigation request.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
5.2.3. Session Configuration Model structure 5.2.3. Session Configuration Model structure
This document defines the YANG module "ietf-dots-signal-config", This document defines the YANG module "ietf-dots-signal-config",
which has the following structure: which has the following structure:
module: ietf-dots-signal-config module: ietf-dots-signal-config
+--rw signal-config +--rw signal-config
+--rw session-id? int32 +--rw session-id? int32
+--rw heartbeat-timeout? int16 +--rw heartbeat-timeout? int16
+--rw max-retransmit? int16 +--rw max-retransmit? int16
+--rw ack-timeout? int16 +--rw ack-timeout? int16
+--rw ack-random-factor? decimal64 +--rw ack-random-factor? decimal64
+--rw trigger-mitigation? boolean
5.2.4. Session Configuration Model 5.2.4. Session Configuration Model
<CODE BEGINS> file "ietf-dots-signal-config@2016-11-28.yang" <CODE BEGINS> file "ietf-dots-signal-config@2016-11-28.yang"
module ietf-dots-signal-config { module ietf-dots-signal-config {
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-config"; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-config";
prefix "config"; prefix "config";
organization "McAfee, Inc."; organization "McAfee, Inc.";
contact "Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>"; contact "Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>";
description description
"This module contains YANG definition for DOTS "This module contains YANG definition for DOTS
signal channel session configuration"; signal channel session configuration.";
revision 2016-11-28 { revision 2016-11-28 {
reference reference
"https://tools.ietf.org/html/draft-reddy-dots-signal-channel"; "https://tools.ietf.org/html/draft-reddy-dots-signal-channel";
} }
container signal-config { container signal-config {
description "top level container for DOTS signal channel session description "Top level container for DOTS signal channel session
configuration"; configuration.";
leaf session-id { leaf session-id {
type int32; type int32;
description "Identifier for the DOTS signal channel description "An identifier for the DOTS signal channel
session configuration data"; session configuration data.";
} }
leaf heartbeat-timeout { leaf heartbeat-timeout {
type int16; type int16;
description "heartbeat timeout"; description
"DOTS agents regularly send heartbeats to each other
after mutual authentication in order to keep
the DOTS signal channel open.";
} }
leaf max-retransmit { leaf max-retransmit {
type int16; type int16;
description "Maximum number of retransmissions"; description
"Maximum retransmissions of a Confirmable message.";
} }
leaf ack-timeout { leaf ack-timeout {
type int16; type int16;
description "Initial retransmission timeout value"; description
"Initial retransmission timeout value.";
} }
leaf ack-random-factor { leaf ack-random-factor {
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
} }
description "Random factor used to influence the timing of description
retransmissions"; "Random factor used to influence the timing of
retransmissions";
}
leaf trigger-mitigation {
type boolean;
default true;
description
"If false, then mitigation is triggered
only when the DOTS server channel session is lost";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
5.3. Mitigation Request 5.3. Mitigation Request
The following methods are used to request or withdraw mitigation The following methods are used to request or withdraw mitigation
requests: requests:
skipping to change at page 14, line 24 skipping to change at page 14, line 28
target-prefix: A list of prefixes under attack. Prefixes are target-prefix: A list of prefixes under attack. Prefixes are
represented using CIDR notation [RFC4632]. This is an optional represented using CIDR notation [RFC4632]. This is an optional
attribute. attribute.
target-port-range: A list of ports under attack. The port range, target-port-range: A list of ports under attack. The port range,
lower-port for lower port number and upper-port for upper port lower-port for lower port number and upper-port for upper port
number. When only lower-port is present, it represents a single number. When only lower-port is present, it represents a single
port. For TCP, UDP, SCTP, or DCCP: the range of ports (e.g., port. For TCP, UDP, SCTP, or DCCP: the range of ports (e.g.,
1024-65535). This is an optional attribute. 1024-65535). This is an optional attribute.
target-protocol: A list of protocols under attack. Internet target-protocol: A list of protocols under attack. Values are taken
Protocol numbers. This is an optional attribute. from the IANA protocol registry [proto_numbers]. The value 0 has
a special meaning for 'all protocols'. This is an optional
attribute.
fqdn: A list of Fully Qualified Domain Names. Fully Qualified fqdn: A list of Fully Qualified Domain Names. Fully Qualified
Domain Name (FQDN) is the full name of a system, rather than just Domain Name (FQDN) is the full name of a system, rather than just
its hostname. For example, "venera" is a hostname, and its hostname. For example, "venera" is a hostname, and
"venera.isi.edu" is an FQDN. This is an optional attribute. "venera.isi.edu" is an FQDN. This is an optional attribute.
uri: A list of Uniform Resource Identifiers (URI). This is an uri: A list of Uniform Resource Identifiers (URI). This is an
optional attribute. optional attribute.
alias: A list of aliases. Aliases can be created using the DOTS alias: A list of aliases. Aliases can be created using the DOTS
data channel (Section 3.1.1 in [I-D.ietf-dots-data-channel]) or data channel (Section 3.1.1 in [I-D.ietf-dots-data-channel]) or
direct configuration , or other means and then used in subsequent direct configuration, or other means and then used in subsequent
signal channel exchanges to refer more efficiently to the signal channel exchanges to refer more efficiently to the
resources under attack. This is an optional attribute. resources under attack. This is an optional attribute.
lifetime: Lifetime of the mitigation request in seconds. Upon the lifetime: Lifetime of the mitigation request in seconds. Upon the
expiry of this lifetime, and if the request is not refreshed, the expiry of this lifetime, and if the request is not refreshed, the
mitigation request is removed. The request can be refreshed by mitigation request is removed. The request can be refreshed by
sending the same request again. The default lifetime of the sending the same request again. The default lifetime of the
mitigation request is 3600 seconds (60 minutes) -- this value was mitigation request is 3600 seconds (60 minutes) -- this value was
chosen to be long enough so that refreshing is not typically a chosen to be long enough so that refreshing is not typically a
burden on the DOTS client, while expiring the request where the burden on the DOTS client, while expiring the request where the
client has unexpectedly quit in a timely manner. A lifetime of client has unexpectedly quit in a timely manner. A lifetime of
zero indicates indefinite lifetime for the mitigation request. negative one (-1) indicates indefinite lifetime for the mitigation
The server MUST always indicate the actual lifetime in the request. The server MUST always indicate the actual lifetime in
response and the remaining lifetime in status messages sent to the the response and the remaining lifetime in status messages sent to
client. This is an optional attribute in the request. the client. This is an optional attribute in the request.
The CBOR key values for the parameters are defined in Section 6. The The CBOR key values for the parameters are defined in Section 6. The
IANA Considerations section defines how the CBOR key values can be IANA Considerations section defines how the CBOR key values can be
allocated to standards bodies and vendors. In the PUT request at allocated to standards bodies and vendors. FQDN and URI mitigation
least one of the attributes target-ip or target-prefix or fqdn or uri scopes may be thought of as a form of scope alias, in which the
or alias MUST be present. DOTS agents can safely ignore Vendor- addresses to which the domain name or URI resolve represent the full
Specific parameters they don't understand. The relative order of two scope of the mitigation. In the PUT request at least one of the
mitigation requests from a DOTS client is determined by comparing attributes target-ip or target-prefix or fqdn or uri or alias MUST be
their respective mitigation-id values. If two mitigation requests present. DOTS agents can safely ignore Vendor-Specific parameters
have overlapping mitigation scopes the mitigation request with higher they don't understand. The relative order of two mitigation requests
numeric mitigation-id value will override the mitigation request with from a DOTS client is determined by comparing their respective
a lower numeric mitigation-id value. The Uri-Path option carries a mitigation-id values. If two mitigation requests have overlapping
major and minor version nomenclature to manage versioning and DOTS mitigation scopes the mitigation request with higher numeric
signal channel in this specification uses v1 major version. mitigation-id value will override the mitigation request with a lower
numeric mitigation-id value. The Uri-Path option carries a major and
minor version nomenclature to manage versioning and DOTS signal
channel in this specification uses v1 major version.
In both DOTS signal and data channel sessions, the DOTS client MUST In both DOTS signal and data channel sessions, the DOTS client MUST
authenticate itself to the DOTS server (Section 9). The DOTS server authenticate itself to the DOTS server (Section 9). The DOTS server
can use the algorithm discussed in Section 7 of [RFC7589] to derive can use the algorithm discussed in Section 7 of [RFC7589] to derive
the DOTS client identity or username from the client certificate. the DOTS client identity or username from the client certificate.
The DOTS server couples the DOTS signal and data channel sessions The DOTS server couples the DOTS signal and data channel sessions
using the DOTS client identity, so the DOTS server can validate using the DOTS client identity, so the DOTS server can validate
whether the aliases conveyed in the mitigation request were indeed whether the aliases conveyed in the mitigation request were indeed
created by the same DOTS client using the DOTS data channel session. created by the same DOTS client using the DOTS data channel session.
If the aliases were not created by the DOTS client then the DOTS If the aliases were not created by the DOTS client then the DOTS
server returns 4.00 (Bad Request) in the response. The DOTS server server returns 4.00 (Bad Request) in the response. The DOTS server
couples the DOTS signal channel sessions using the DOTS client couples the DOTS signal channel sessions using the DOTS client
identity, and the DOTS server uses mitigation-id parameter value to identity, and the DOTS server uses mitigation-id parameter value to
detect duplicate mitigation requests. detect duplicate mitigation requests. If the mitigation request
contains both alias and other parameters identifying the target
resource (such as, target-ip, target-prefix, target-port-range, fqdn,
or uri) then the DOTS server appends the parameter values in alias
with the corresponding parameter values in target-ip, target-prefix,
target-port-range, fqdn, or uri.
Figure 6 shows a PUT request example to signal that ports 80, 8080, Figure 6 shows a PUT request example to signal that ports 80, 8080,
and 443 on the servers 2001:db8:6401::1 and 2001:db8:6401::2 are and 443 on the servers 2001:db8:6401::1 and 2001:db8:6401::2 are
being attacked (illustrated in JSON diagnostic notation). being attacked (illustrated in JSON diagnostic notation).
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Host: "www.example.com" Uri-Host: "www.example.com"
Uri-Path: "v1" Uri-Path: "v1"
Uri-Path: "dots-signal" Uri-Path: "dots-signal"
Uri-Path: "signal" Uri-Path: "signal"
skipping to change at page 17, line 4 skipping to change at page 17, line 16
83 # array(3) 83 # array(3)
a1 # map(1) a1 # map(1)
06 # unsigned(6) 06 # unsigned(6)
18 50 # unsigned(80) 18 50 # unsigned(80)
a1 # map(1) a1 # map(1)
06 # unsigned(6) 06 # unsigned(6)
19 01bb # unsigned(443) 19 01bb # unsigned(443)
a1 # map(1) a1 # map(1)
06 # unsigned(6) 06 # unsigned(6)
19 1f90 # unsigned(8080) 19 1f90 # unsigned(8080)
08 # unsigned(8) 08 # unsigned(8)
81 # array(1) 81 # array(1)
06 # unsigned(6) 06 # unsigned(6)
Figure 6: POST for DOTS signal Figure 6: PUT for DOTS signal
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. COAP 5.xx codes are codes are some sort of invalid requests. COAP 5.xx codes are
returned if the DOTS server has erred or is currently unavailable to returned if the DOTS server has erred or is currently unavailable to
provide mitigation in response to the mitigation request from the provide mitigation in response to the mitigation request from the
DOTS client. If the DOTS server does not find the mitigation-id DOTS client. If the DOTS server does not find the mitigation-id
parameter value conveyed in the PUT request in its configuration data parameter value conveyed in the PUT request in its configuration data
then the server MAY accept the mitigation request, and a 2.01 then the server MAY accept the mitigation request, and a 2.01
(Created) response is returned to the DOTS client, and the DOTS (Created) response is returned to the DOTS client, and the DOTS
skipping to change at page 18, line 23 skipping to change at page 18, line 23
"scope": [ "scope": [
{ {
"mitigation-id": integer "mitigation-id": integer
} }
] ]
} }
} }
Figure 7: Withdraw DOTS signal Figure 7: Withdraw DOTS signal
If the DOTS server does not find the mitigation-id parameter value The DOTS server immediately acknowledges a DOTS client's request to
conveyed in the DELETE request in its configuration data, then it withdraw the DOTS signal using 2.02 (Deleted) response code. A 2.02
responds with a 4.04 (Not Found) error response code. The DOTS (Deleted) Response Code is returned even if the mitigation-id
server successfully acknowledges a DOTS client's request to withdraw parameter value conveyed in the DELETE request does not exist in its
the DOTS signal using 2.02 (Deleted) response code, and ceases configuration data before the request. If the DOTS server finds the
mitigation activity as quickly as possible. mitigation-id parameter value conveyed in the DELETE request in its
configuration data, then to protect against route or DNS flapping
To protect against route or DNS flapping caused by a client rapidly caused by a client rapidly toggling mitigation, and to dampen the
toggling mitigation, and to dampen the effect of oscillating attacks, effect of oscillating attacks, DOTS servers MAY allow mitigation to
DOTS servers MAY continue mitigation for a period of up to five continue for a limited period after acknowledging a DOTS client's
minutes after acknowledging a DOTS client's withdrawal of a withdrawal of a mitigation request. During this period, DOTS server
mitigation request. During this period, DOTS server status messages status messages SHOULD indicate that mitigation is active but
SHOULD indicate that mitigation is active but terminating. After the terminating. The active-but-terminating period is initially 30
five-minute period elapses, the DOTS server MUST treat the mitigation seconds. If the client requests mitigation again before that 30
as terminated, as the DOTS client is no longer responsible for the second window elapses, the DOTS server MAY exponentially increase the
mitigation. For example, if there is a financial relationship active- but-terminating period up to a maximum of 240 seconds (4
between the DOTS client and server domains, the DOTS client ceases minutes). After the active-but-terminating period elapses, the DOTS
incurring cost at this point. server MUST treat the mitigation as terminated, as the DOTS client is
no longer responsible for the mitigation. For example, if there is a
financial relationship between the DOTS client and server domains,
the DOTS client ceases incurring cost at this point.
5.3.3. Retrieving a DOTS Signal 5.3.3. Retrieving a DOTS Signal
A GET request is used to retrieve information and status of a DOTS A GET request is used to retrieve information and status of a DOTS
signal from a DOTS server (Figure 8). If the DOTS server does not signal from a DOTS server (Figure 8). If the DOTS server does not
find the mitigation-id parameter value conveyed in the GET request in find the mitigation-id parameter value conveyed in the GET request in
its configuration data, then it responds with a 4.04 (Not Found) its configuration data, then it responds with a 4.04 (Not Found)
error response code. The 'c' (content) parameter and its permitted error response code. The 'c' (content) parameter and its permitted
values defined in [I-D.ietf-core-comi] can be used to retrieve non- values defined in [I-D.ietf-core-comi] can be used to retrieve non-
configuration data or configuration data or both. configuration data or configuration data or both.
skipping to change at page 22, line 5 skipping to change at page 22, line 5
long as the client is interested in the resource. A DOTS client long as the client is interested in the resource. A DOTS client
conveys the observe option set to 0 in the GET request to receive conveys the observe option set to 0 in the GET request to receive
unsolicited notifications of attack mitigation status from the DOTS unsolicited notifications of attack mitigation status from the DOTS
server. Unidirectional notifications within the bidirectional signal server. Unidirectional notifications within the bidirectional signal
channel allows unsolicited message delivery, enabling asynchronous channel allows unsolicited message delivery, enabling asynchronous
notifications between the agents. A DOTS client that is no longer notifications between the agents. A DOTS client that is no longer
interested in receiving notifications from the DOTS server can simply interested in receiving notifications from the DOTS server can simply
"forget" the observation. When the DOTS server then sends the next "forget" the observation. When the DOTS server then sends the next
notification, the DOTS client will not recognize the token in the notification, the DOTS client will not recognize the token in the
message and thus will return a Reset message. This causes the DOTS message and thus will return a Reset message. This causes the DOTS
server to remove the associated entry. server to remove the associated entry. Alternatively, the DOTS
client can explicitly deregister by issuing a GET request that has
the Token field set to the token of the observation to be cancelled
and includes an Observe Option with the value set to 1 (deregister).
DOTS Client DOTS Server DOTS Client DOTS Server
| | | |
| GET /<mitigation-id number> | | GET /<mitigation-id number> |
| Token: 0x4a | Registration | Token: 0x4a | Registration
| Observe: 0 | | Observe: 0 |
+------------------------------>| +------------------------------>|
| | | |
| 2.05 Content | | 2.05 Content |
| Token: 0x4a | Notification of | Token: 0x4a | Notification of
skipping to change at page 23, line 12 skipping to change at page 23, line 14
attack on its resources but the DOTS server could be actively attack on its resources but the DOTS server could be actively
mitigating the attack and the attack is not completely averted. mitigating the attack and the attack is not completely averted.
5.3.4. Efficacy Update from DOTS Client 5.3.4. Efficacy Update from DOTS Client
While DDoS mitigation is active, a DOTS client MAY frequently While DDoS mitigation is active, a DOTS client MAY frequently
transmit DOTS mitigation efficacy updates to the relevant DOTS transmit DOTS mitigation efficacy updates to the relevant DOTS
server. An PUT request (Figure 11) is used to convey the mitigation server. An PUT request (Figure 11) is used to convey the mitigation
efficacy update to the DOTS server. The PUT request MUST include all efficacy update to the DOTS server. The PUT request MUST include all
the parameters used in the PUT request to convey the DOTS signal the parameters used in the PUT request to convey the DOTS signal
(Section 5.3.1). (Section 5.3.1). The If-Match Option (Section 5.10.8.1 of [RFC7252])
with an empty value is used to make the PUT request conditional on
the current existence of the mitigation request. If UDP is used as
transport, CoAP requests may arrive out-of-order. For example, the
DOTS client may send a PUT request to convey efficacy update to the
DOTS server followed by a DELETE request to withdraw the mitigation
request, but DELETE request arrives at the DOTS server before the PUT
request. To handle out-of-order delivery of requests, if an If-Match
option is present in the PUT request and the mitigation-id in the
request matches a mitigation request from the DOTS client then the
request is processed, and if no match is found then the PUT request
is silently ignored.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Host: "host" Uri-Host: "host"
Uri-Path: "version" Uri-Path: "version"
Uri-Path: "dots-signal" Uri-Path: "dots-signal"
Uri-Path: "signal" Uri-Path: "signal"
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"mitigation-scope": { "mitigation-scope": {
"scope": [ "scope": [
skipping to change at page 25, line 18 skipping to change at page 25, line 18
| 1 | DOTS client determines that it is still under attack.| | 1 | DOTS client determines that it is still under attack.|
+---------------------------------------------------------------------------+ +---------------------------------------------------------------------------+
| 2 | DOTS client determines that the attack is | | 2 | DOTS client determines that the attack is |
| | successfully mitigated | | | successfully mitigated |
| | (e.g., attack traffic is not seen). | | | (e.g., attack traffic is not seen). |
\--------------------+------------------------------------------------------/ \--------------------+------------------------------------------------------/
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. The response code 2.04 (Changed) will be using CoAP response codes. The response code 2.04 (Changed) will be
returned in the response if the DOTS server has accepted the returned in the response if the DOTS server has accepted the
mitigation efficacy update. If the DOTS server does not find the mitigation efficacy update. The 5.xx response codes are returned if
mitigation-id parameter value conveyed in the PUT request in its the DOTS server has erred or is incapable of performing the
configuration data then the server MAY accept the mitigation request mitigation.
and will try to mitigate the attack, resulting in a 2.01 (Created)
Response Code. The 5.xx response codes are returned if the DOTS
server has erred or is incapable of performing the mitigation.
5.4. DOTS Signal Channel Session Configuration 5.4. DOTS Signal Channel Session Configuration
The DOTS client can negotiate, configure and retrieve the DOTS signal The DOTS client can negotiate, configure and retrieve the DOTS signal
channel session behavior. The DOTS signal channel can be used, for channel session behavior. The DOTS signal channel can be used, for
example, to configure the following: example, to configure the following:
a. Heartbeat timeout: DOTS agents regularly send heartbeats (Ping/ a. Heartbeat timeout: DOTS agents regularly send heartbeats (Ping/
Pong) to each other after mutual authentication in order to keep Pong) to each other after mutual authentication in order to keep
the DOTS signal channel open, heartbeat timeout is the time to the DOTS signal channel open, heartbeat timeout is the time to
skipping to change at page 27, line 7 skipping to change at page 27, line 7
"heartbeat-timeout": {"MinValue": integer, "MaxValue" : integer}, "heartbeat-timeout": {"MinValue": integer, "MaxValue" : integer},
"max-retransmit": {"MinValue": integer, "MaxValue" : integer}, "max-retransmit": {"MinValue": integer, "MaxValue" : integer},
"ack-timeout": {"MinValue": integer, "MaxValue" : integer}, "ack-timeout": {"MinValue": integer, "MaxValue" : integer},
"ack-random-factor": {"MinValue": number, "MaxValue" : number} "ack-random-factor": {"MinValue": number, "MaxValue" : number}
} }
Figure 13: GET response body Figure 13: GET response body
5.4.2. Convey DOTS Signal Channel Session Configuration 5.4.2. Convey DOTS Signal Channel Session Configuration
A POST request is used to convey the configuration parameters for the A PUT request is used to convey the configuration parameters for the
signaling channel (e.g., heartbeat timeout, maximum retransmissions signaling channel (e.g., heartbeat timeout, maximum retransmissions
etc). Message transmission parameters for CoAP are defined in etc). Message transmission parameters for CoAP are defined in
Section 4.8 of [RFC7252]. If the DOTS agent wishes to change the Section 4.8 of [RFC7252]. The RECOMMENDED values of transmission
default values of message transmission parameters then it should parameter values are ack_timeout (2 seconds), max-retransmit (7),
follow the guidance given in Section 4.8.1 of [RFC7252]. The DOTS ack-random-factor (1.5) and heartbeat-timeout (371 seconds). The
agents MUST use the negotiated values for message transmission heartbeat-timeout value is equal to the MAX_TRANSMIT_WAIT counter
parameters and default values for non-negotiated message transmission (Section 4.8.2 in [RFC7252]) whose value is derived from transmission
parameters. The signaling channel session configuration is parameters. If the DOTS agent wishes to change the default values of
applicable to a single DOTS signal channel session between the DOTS message transmission parameters then it should follow the guidance
agents. given in Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the
negotiated values for message transmission parameters and default
values for non-negotiated message transmission parameters. The
signaling channel session configuration is applicable to a single
DOTS signal channel session between the DOTS agents.
Header: POST (Code=0.02) Header: PUT (Code=0.03)
Uri-Host: "host" Uri-Host: "host"
Uri-Path: "version" Uri-Path: "version"
Uri-Path: "dots-signal" Uri-Path: "dots-signal"
Uri-Path: "config" Uri-Path: "config"
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"signal-config": { "signal-config": {
"session-id": integer, "session-id": integer,
"heartbeat-timeout": integer, "heartbeat-timeout": integer,
"max-retransmit": integer, "max-retransmit": integer,
"ack-timeout": integer, "ack-timeout": integer,
"ack-random-factor": number "ack-random-factor": number
"trigger-mitigation": boolean
} }
} }
Figure 14: POST to convey the DOTS signal channel session Figure 14: PUT to convey the DOTS signal channel session
configuration data. configuration data.
The parameters are described below: The parameters are described below:
session-id: Identifier for the DOTS signal channel session session-id: Identifier for the DOTS signal channel session
configuration data represented as an integer. This identifier configuration data represented as an integer. This identifier
MUST be generated by the DOTS client. This document does not make MUST be generated by the DOTS client. This document does not make
any assumption about how this identifier is generated. This is a any assumption about how this identifier is generated. This is a
mandatory attribute. mandatory attribute.
skipping to change at page 28, line 13 skipping to change at page 28, line 21
optional attribute. optional attribute.
ack-timeout: Timeout value in seconds used to calculate the initial ack-timeout: Timeout value in seconds used to calculate the initial
retransmission timeout value (referred to as ACK_TIMEOUT parameter retransmission timeout value (referred to as ACK_TIMEOUT parameter
in CoAP). This is an optional attribute. in CoAP). This is an optional attribute.
ack-random-factor: Random factor used to influence the timing of ack-random-factor: Random factor used to influence the timing of
retransmissions (referred to as ACK_RANDOM_FACTOR parameter in retransmissions (referred to as ACK_RANDOM_FACTOR parameter in
CoAP). This is an optional attribute. CoAP). This is an optional attribute.
In the POST request at least one of the attributes heartbeat-timeout trigger-mitigation: If the parameter value is set to 'false', then
or max-retransmit or ack-timeout or ack-random-factor MUST be DDoS mitigation is triggered only when the DOTS signal channel
present. The POST request with higher numeric session-id value over- session is lost. Automated mtigation on loss of signal is
rides the DOTS signal channel session configuration data installed by discussed in Section 3.3.3 of [I-D.ietf-dots-architecture]. If
a POST request with a lower numeric session-id value. the DOTS client ceases to respond to heartbeat messages, then the
DOTS server can detect that the DOTS session is lost. The default
value of the parameter is 'true'. This is an optional attribute.
Figure 15 shows a POST request example to convey the configuration In the PUT request at least one of the attributes heartbeat-timeout,
max-retransmit, ack-timeout, ack-random-factor, and trigger-
mitigation MUST be present. The PUT request with higher numeric
session-id value over-rides the DOTS signal channel session
configuration data installed by a PUT request with a lower numeric
session-id value.
Figure 15 shows a PUT request example to convey the configuration
parameters for the DOTS signal channel. parameters for the DOTS signal channel.
Header: POST (Code=0.02) Header: PUT (Code=0.03)
Uri-Host: "www.example.com" Uri-Host: "www.example.com"
Uri-Path: "v1" Uri-Path: "v1"
Uri-Path: "dots-signal" Uri-Path: "dots-signal"
Uri-Path: "config" Uri-Path: "config"
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"signal-config": { "signal-config": {
"session-id": 1234534333242, "session-id": 1234534333242,
"heartbeat-timeout": 30, "heartbeat-timeout": 30,
"max-retransmit": 7, "max-retransmit": 7,
"ack-timeout": 5, "ack-timeout": 5,
"ack-random-factor": 1.5 "ack-random-factor": 1.5,
"trigger-mitigation": false
} }
} }
Figure 15: POST to convey the configuration parameters Figure 15: PUT to convey the configuration parameters
The DOTS server indicates the result of processing the POST request The DOTS server indicates the result of processing the PUT request
using CoAP response codes. The CoAP response will include the CBOR using CoAP response codes. The CoAP response will include the CBOR
body received in the request. Response code 2.01 (Created) will be body received in the request. If the DOTS server finds the session-
returned in the response if the DOTS server has accepted the id parameter value conveyed in the PUT request in its configuration
configuration parameters. If the request is missing one or more data and if the DOTS server has accepted the updated configuration
mandatory attributes then 4.00 (Bad Request) will be returned in the parameters then the a 2.04 (Changed) response will be returned in the
response or if the request contains invalid or unknown parameters response. If the DOTS server does not find the session-id parameter
then 4.02 (Invalid query) will be returned in the response. Response value conveyed in the PUT request in its configuration data and if
code 4.22 (Unprocessable Entity) will be returned in the response if the DOTS server has accepted the configuration parameters then a
any of the heartbeat-timeout, max-retransmit, target-protocol, ack- response code 2.01 (Created) will be returned in the response. If
timeout and ack-random-factor attribute values is not acceptable to the request is missing one or more mandatory attributes then 4.00
the DOTS server. The DOTS server in the error response conveys the (Bad Request) will be returned in the response or if the request
minimum and maximum attribute values acceptable by the DOTS server. contains invalid or unknown parameters then 4.02 (Invalid query) will
be returned in the response. Response code 4.22 (Unprocessable
The DOTS client can re-try and send the POST request with updated Entity) will be returned in the response if any of the heartbeat-
attribute values acceptable to the DOTS server. timeout, max-retransmit, target-protocol, ack-timeout and ack-random-
factor attribute values is not acceptable to the DOTS server. The
DOTS server in the error response conveys the minimum and maximum
attribute values acceptable by the DOTS server. The DOTS client can
re-try and send the PUT request with updated attribute values
acceptable to the DOTS server.
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"heartbeat-timeout": {"MinValue": 15, "MaxValue" : 60}, "heartbeat-timeout": {"MinValue": 15, "MaxValue" : 60},
"max-retransmit": {"MinValue": 3, "MaxValue" : 15}, "max-retransmit": {"MinValue": 3, "MaxValue" : 15},
"ack-timeout": {"MinValue": 1, "MaxValue" : 30}, "ack-timeout": {"MinValue": 1, "MaxValue" : 30},
"ack-random-factor": {"MinValue": 1.0, "MaxValue" : 4.0} "ack-random-factor": {"MinValue": 1.0, "MaxValue" : 4.0}
} }
Figure 16: Error response body Figure 16: Error response body
skipping to change at page 30, line 26 skipping to change at page 31, line 26
Figure 18: GET to retrieve configuration Figure 18: GET to retrieve configuration
5.5. Redirected Signaling 5.5. Redirected Signaling
Redirected Signaling is discussed in detail in Section 3.2.2 of Redirected Signaling is discussed in detail in Section 3.2.2 of
[I-D.ietf-dots-architecture]. If the DOTS server wants to redirect [I-D.ietf-dots-architecture]. If the DOTS server wants to redirect
the DOTS client to an alternative DOTS server for a signaling session the DOTS client to an alternative DOTS server for a signaling session
then the response code 3.00 (alternate server) will be returned in then the response code 3.00 (alternate server) will be returned in
the response to the client. The DOTS server can return the error the response to the client. The DOTS server can return the error
response code 3.00 in response to a POST or PUT request from the DOTS response code 3.00 in response to a PUT request from the DOTS client
client or convey the error response code 3.00 in a unidirectional or convey the error response code 3.00 in a unidirectional
notification response from the DOTS server. 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 FQDN, and the alternate DOTS server IP addresses and time to server FQDN, and the alternate DOTS server IP addresses and time to
live values in the CBOR body. live values in the CBOR body.
{ {
"alt-server": "string", "alt-server": "string",
"alt-server-record": [ "alt-server-record": [
{ {
"addr": "string", "addr": "string",
"ttl" : integer, "ttl" : integer,
} }
] ]
} }
Figure 19: Error response body Figure 19: Error response body
The parameters are described below: The parameters are described below:
alt-server: FQDN of alternate DOTS server. alt-server: FQDN of an alternate DOTS server.
addr: IP address of alternate DOTS server. addr: IP address of an alternate DOTS server.
ttl: Time to live (TTL) represented as an integer number of seconds. ttl: Time to live (TTL) represented as an integer number of seconds.
Figure 20 shows a 3.00 response example to convey the DOTS alternate Figure 20 shows a 3.00 response example to convey the DOTS alternate
server www.example-alt.com, its IP addresses 2001:db8:6401::1 and server www.example-alt.com, its IP addresses 2001:db8:6401::1 and
2001:db8:6401::2, and TTL values 3600 and 1800. 2001:db8:6401::2, and TTL values 3600 and 1800.
{ {
"alt-server": "www.example-alt.com", "alt-server": "www.example-alt.com",
skipping to change at page 31, line 38 skipping to change at page 32, line 38
alternate DOTS server. During a DDOS attack, the DNS server may be alternate DOTS server. During a DDOS attack, the DNS server may be
subjected to DDOS attack, alternate DOTS server IP addresses conveyed subjected to DDOS attack, alternate DOTS server IP addresses conveyed
in the 3.00 response help the DOTS client to skip DNS lookup of the in the 3.00 response help the DOTS client to skip DNS lookup of the
alternate DOTS server and can try to establish UDP or TCP session alternate DOTS server and can try to establish UDP or TCP session
with the alternate DOTS server IP addresses. The DOTS client SHOULD with the alternate DOTS server IP addresses. The DOTS client SHOULD
implement DNS64 function to handle the scenario where IPv6-only DOTS implement DNS64 function to handle the scenario where IPv6-only DOTS
client communicates with IPv4-only alternate DOTS server. client communicates with IPv4-only alternate DOTS server.
5.6. Heartbeat Mechanism 5.6. Heartbeat Mechanism
While the communication between the DOTS agents is quiescent, the To provide a metric of signal health and distinguish an 'idle' signal
DOTS client will probe the DOTS server to ensure it has maintained channel from a 'disconnected' or 'defunct' session, the DOTS agent
cryptographic state and vice versa. Such probes can also keep alive sends a heartbeat over the signal channel to maintain its half of the
firewall or NAT bindings. This probing reduces the frequency of channel. The DOTS agent similarly expects a heartbeat from its peer
needing a new handshake when a DOTS signal needs to be conveyed to agent, and may consider a session terminated in the extended absence
the DOTS server. In DOTS over UDP, heartbeat messages can be of a peer agent heartbeat. While the communication between the DOTS
exchanged between the DOTS agents using the "COAP ping" mechanism agents is quiescent, the DOTS client will probe the DOTS server to
(Section 4.2 in [RFC7252]). The DOTS agent sends an Empty ensure it has maintained cryptographic state and vice versa. Such
Confirmable message and the peer DOTS agent will respond by sending probes can also keep alive firewall and/or NAT bindings. This
an Reset message. In DOTS over TCP, heartbeat messages can be probing reduces the frequency of establishing a new handshake when a
exchanged between the DOTS agents using the Ping and Pong messages DOTS signal needs to be conveyed to the DOTS server. In DOTS over
(Section 4.4 in [I-D.ietf-core-coap-tcp-tls]). The DOTS agent sends UDP, heartbeat messages can be exchanged between the DOTS agents
an Ping message and the peer DOTS agent will respond by sending an using the "COAP ping" mechanism (Section 4.2 in [RFC7252]). The DOTS
single Pong message. agent sends an Empty Confirmable message and the peer DOTS agent will
respond by sending an Reset message. In DOTS over TCP, heartbeat
messages can be exchanged between the DOTS agents using the Ping and
Pong messages (Section 4.4 in [I-D.ietf-core-coap-tcp-tls]). The
DOTS agent sends a Ping message and the peer DOTS agent would respond
by sending a single Pong message.
6. Mapping parameters to CBOR 6. Mapping parameters to CBOR
All parameters in DOTS signal channel are mapped to CBOR types as All parameters in DOTS signal channel are mapped to CBOR types as
follows and are given an integer key value to save space. follows and are given an integer key value to save space.
/--------------------+------------------------+--------------------------\ /--------------------+------------------------+--------------------------\
| Parameter name | CBOR key | CBOR major type of value | | Parameter name | CBOR key | CBOR major type of value |
|--------------------+------------------------+--------------------------| |--------------------+------------------------+--------------------------|
| mitigation-scope | 1 | 5 (map) | | mitigation-scope | 1 | 5 (map) |
skipping to change at page 32, line 39 skipping to change at page 33, line 43
| ack-timeout | 17 | 0 | | ack-timeout | 17 | 0 |
| ack-random-factor | 18 | 7 | | ack-random-factor | 18 | 7 |
| MinValue | 19 | 0 | | MinValue | 19 | 0 |
| MaxValue | 20 | 0 | | MaxValue | 20 | 0 |
| status | 21 | 0 | | status | 21 | 0 |
| bytes-dropped | 22 | 0 | | bytes-dropped | 22 | 0 |
| bps-dropped | 23 | 0 | | bps-dropped | 23 | 0 |
| pkts-dropped | 24 | 0 | | pkts-dropped | 24 | 0 |
| pps-dropped | 25 | 0 | | pps-dropped | 25 | 0 |
| session-id | 26 | 0 | | session-id | 26 | 0 |
| trigger-mitigation | 27 | 7 (simple types) |
\--------------------+------------------------+--------------------------/ \--------------------+------------------------+--------------------------/
Figure 21: CBOR mappings used in DOTS signal channel message Figure 21: CBOR mappings used in DOTS signal channel message
7. (D)TLS Protocol Profile and Performance considerations 7. (D)TLS Protocol Profile and Performance considerations
This section defines the (D)TLS protocol profile of DOTS signal This section defines the (D)TLS protocol profile of DOTS signal
channel over (D)TLS and DOTS data channel over TLS. channel over (D)TLS and DOTS data channel over TLS.
There are known attacks on (D)TLS, such as machine-in-the-middle and There are known attacks on (D)TLS, such as machine-in-the-middle and
skipping to change at page 34, line 4 skipping to change at page 35, line 14
be assumed. The length of the URL MUST NOT exceed 256 bytes. If UDP 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 is used to convey the DOTS signal messages then the DOTS client must
consider the amount of record expansion expected by the DTLS consider the amount of record expansion expected by the DTLS
processing when calculating the size of CoAP message that fits within processing when calculating the size of CoAP message that fits within
the path MTU. Path MTU MUST be greater than or equal to [CoAP the path MTU. Path MTU MUST be greater than or equal to [CoAP
message size + DTLS overhead of 13 octets + authentication overhead message size + DTLS overhead of 13 octets + authentication overhead
of the negotiated DTLS cipher suite + block padding (Section 4.1.1.1 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 of [RFC6347]]. If the request size exceeds the Path MTU then the
DOTS client MUST split the DOTS signal into separate messages, for DOTS client MUST split the DOTS signal into separate messages, for
example the list of addresses in the 'target-ip' parameter could be example the list of addresses in the 'target-ip' parameter could be
split into multiple lists and each list conveyed in a new POST split into multiple lists and each list conveyed in a new PUT
request. request.
Implementation Note: DOTS choice of message size parameters works Implementation Note: DOTS choice of message size parameters works
well with IPv6 and with most of today's IPv4 paths. However, with 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 IPv4, it is harder to absolutely ensure that there is no IP
fragmentation. If IPv4 support on unusual networks is a fragmentation. If IPv4 support on unusual networks is a
consideration and path MTU is unknown, implementations may want to consideration and path MTU is unknown, implementations may want to
limit themselves to more conservative IPv4 datagram sizes such as 576 limit themselves to more conservative IPv4 datagram sizes such as 576
bytes, as per [RFC0791] IP packets up to 576 bytes should never need 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 to be fragmented, thus sending a maximum of 500 bytes of DOTS signal
skipping to change at page 37, line 7 skipping to change at page 38, line 7
Also, DOTS gateway and DOTS server MUST perform mutual authentication Also, DOTS gateway and DOTS server MUST perform mutual authentication
using certificates. A DOTS server will only allow a DOTS gateway using certificates. A DOTS server will only allow a DOTS gateway
with a certificate for a particular domain to request mitigation for with a certificate for a particular domain to request mitigation for
that domain. In reference to Figure 23, the DOTS server only allows that domain. In reference to Figure 23, the DOTS server only allows
the DOTS gateway to request mitigation for 'example.com' domain and the DOTS gateway to request mitigation for 'example.com' domain and
not for other domains. not for other domains.
10. IANA Considerations 10. IANA Considerations
This specification registers new parameters for DOTS signal channel This specification registers new CoAP response code, new parameters
and establishes registries for mappings to CBOR. for DOTS signal channel and establishes registries for mappings to
CBOR.
10.1. DOTS signal channel CBOR Mappings Registry 10.1. CoAP Response Code
The following entry is added to the "CoAP Response Codes" sub-
registry:
+------+------------------------------+-----------+
| Code | Description | Reference |
+------+------------------------------+-----------+
| 3.00 | Alternate server | [RFCXXXX] |
+------+------------------------------+-----------+
Figure 24: CoAP Response Code
[Note to RFC Editor: Please replace XXXX with the RFC number of this
specification.]
10.2. DOTS signal channel CBOR Mappings Registry
A new registry will be requested from IANA, entitled "DOTS signal A new registry will be requested from IANA, entitled "DOTS signal
channel CBOR Mappings Registry". The registry is to be created as channel CBOR Mappings Registry". The registry is to be created as
Expert Review Required. Expert Review Required.
10.1.1. Registration Template 10.2.1. Registration Template
Parameter name: Parameter name:
Parameter names (e.g., "target_ip") in the DOTS signal channel. Parameter names (e.g., "target_ip") 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 range of 1 to 65536. The key values in the range of 32768 to the range of 1 to 65536. The key values in the range of 32768 to
65536 are assigned for Vendor-Specific parameters. 65536 are assigned for Vendor-Specific parameters.
CBOR Major Type: CBOR Major Type:
skipping to change at page 37, line 35 skipping to change at page 39, line 4
CBOR Major Type: CBOR Major Type:
CBOR Major type and optional tag for the claim. CBOR Major type and optional tag for the claim.
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
included but is not required. included but is not required.
10.1.2. Initial Registry Contents 10.2.2. Initial Registry Contents
o Parameter Name: "mitigation-scope" o Parameter Name: "mitigation-scope"
o CBOR Key Value: 1 o CBOR Key Value: 1
o CBOR Major Type: 5 o CBOR Major Type: 5
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: "scope" o Parameter Name: "scope"
o CBOR Key Value: 2 o CBOR Key Value: 2
o CBOR Major Type: 5 o CBOR Major Type: 5
skipping to change at page 40, line 33 skipping to change at page 42, line 4
o CBOR Key Value: 22 o CBOR Key Value: 22
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: bps-dropped o Parameter Name: bps-dropped
o CBOR Key Value: 23 o CBOR Key Value: 23
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: pkts-dropped o Parameter Name: pkts-dropped
o CBOR Key Value: 24 o CBOR Key Value: 24
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: pps-dropped o Parameter Name: pps-dropped
o CBOR Key Value: 25 o CBOR Key Value: 25
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: session-id o Parameter Name: session-id
o CBOR Key Value: 26 o CBOR Key Value: 26
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: trigger-mitigation
o CBOR Key Value: 27
o CBOR Major Type: 7
o Change Controller: IESG
o Specification Document(s): this document
11. Implementation Status 11. Implementation Status
[Note to RFC Editor: Please remove this section and reference to [Note to RFC Editor: Please remove this section and reference to
[RFC7942] prior to publication.] [RFC7942] prior to publication.]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
skipping to change at page 43, line 9 skipping to change at page 44, line 34
Robert Moskowitz HTT Consulting Oak Park, MI 42837 United States Robert Moskowitz HTT Consulting Oak Park, MI 42837 United States
Email: rgm@htt-consult.com Email: rgm@htt-consult.com
Dan Wing Email: dwing-ietf@fuggles.com Dan Wing Email: dwing-ietf@fuggles.com
14. Acknowledgements 14. Acknowledgements
Thanks to Christian Jacquenet, Roland Dobbins, Andrew Mortensen, Thanks to Christian Jacquenet, Roland Dobbins, Andrew Mortensen,
Roman D. Danyliw, Michael Richardson, Ehud Doron, Kaname Nishizuka, Roman D. Danyliw, Michael Richardson, Ehud Doron, Kaname Nishizuka,
Dave Dolson, Liang Xia and Gilbert Clark for the discussion and Dave Dolson, Liang Xia, Jon Shallow and Gilbert Clark for the
comments. discussion and comments.
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-core-coap-tcp-tls] [I-D.ietf-core-coap-tcp-tls]
Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, "CoAP (Constrained Silverajan, B., and B. Raymor, "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets", Application Protocol) over TCP, TLS, and WebSockets",
draft-ietf-core-coap-tcp-tls-09 (work in progress), May draft-ietf-core-coap-tcp-tls-09 (work in progress), May
skipping to change at page 44, line 19 skipping to change at page 45, line 43
2015, <http://www.rfc-editor.org/info/rfc7525>. 2015, <http://www.rfc-editor.org/info/rfc7525>.
[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,
<http://www.rfc-editor.org/info/rfc7641>. <http://www.rfc-editor.org/info/rfc7641>.
15.2. Informative References 15.2. Informative References
[I-D.ietf-core-comi] [I-D.ietf-core-comi]
Stok, P., Bierman, A., Veillette, M., and A. Pelov, "CoAP Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP
Management Interface", draft-ietf-core-comi-00 (work in Management Interface", draft-ietf-core-comi-01 (work in
progress), January 2017. progress), July 2017.
[I-D.ietf-core-yang-cbor] [I-D.ietf-core-yang-cbor]
Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A.
Minaburo, "CBOR Encoding of Data Modeled with YANG", Minaburo, "CBOR Encoding of Data Modeled with YANG",
draft-ietf-core-yang-cbor-04 (work in progress), February draft-ietf-core-yang-cbor-05 (work in progress), August
2017. 2017.
[I-D.ietf-dots-architecture] [I-D.ietf-dots-architecture]
Mortensen, A., Andreasen, F., Reddy, T., Mortensen, A., Andreasen, F., Reddy, T.,
christopher_gray3@cable.comcast.com, c., Compton, R., and christopher_gray3@cable.comcast.com, c., Compton, R., and
N. Teague, "Distributed-Denial-of-Service Open Threat N. Teague, "Distributed-Denial-of-Service Open Threat
Signaling (DOTS) Architecture", draft-ietf-dots- Signaling (DOTS) Architecture", draft-ietf-dots-
architecture-03 (work in progress), June 2017. architecture-04 (work in progress), July 2017.
[I-D.ietf-dots-data-channel] [I-D.ietf-dots-data-channel]
Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil, Reddy, T., Boucadair, M., 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", draft- Service Open Threat Signaling (DOTS) Data Channel", draft-
ietf-dots-data-channel-01 (work in progress), June 2017. ietf-dots-data-channel-02 (work in progress), June 2017.
[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-05 (work in Requirements", draft-ietf-dots-requirements-06 (work in
progress), June 2017. progress), July 2017.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Fouant, S., Migault, D., 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 (DDoS) Open Threat Signaling", Open Threat Signaling", draft-ietf-dots-use-cases-07 (work
draft-ietf-dots-use-cases-05 (work in progress), May 2017. in progress), July 2017.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-20 (work in progress), Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
April 2017. July 2017.
[I-D.rescorla-tls-dtls13] [I-D.rescorla-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
1.3", draft-rescorla-tls-dtls13-01 (work in progress), 1.3", draft-rescorla-tls-dtls13-01 (work in progress),
March 2017. March 2017.
[proto_numbers]
"IANA, "Protocol Numbers"", 2011,
<http://www.iana.org/assignments/protocol-numbers>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <http://www.rfc-editor.org/info/rfc791>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <http://www.rfc-editor.org/info/rfc4632>. 2006, <http://www.rfc-editor.org/info/rfc4632>.
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
 End of changes. 90 change blocks. 
183 lines changed or deleted 293 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/