< draft-ietf-dots-signal-channel-10.txt   draft-ietf-dots-signal-channel-11.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: June 3, 2018 Orange Expires: June 8, 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.
November 30, 2017 December 5, 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-10 draft-ietf-dots-signal-channel-11
Abstract Abstract
This document specifies the DOTS signal channel, a protocol for This document specifies the DOTS signal channel, a protocol for
signaling the need for protection against Distributed Denial-of- signaling the need for protection against Distributed Denial-of-
Service (DDoS) attacks to a server capable of enabling network Service (DDoS) attacks to a server capable of enabling network
traffic mitigation on behalf of the requesting client. traffic mitigation on behalf of the requesting client.
A companion document defines the DOTS data channel, a separate A companion document defines the DOTS data channel, a separate
reliable communication layer for DOTS management and configuration. reliable communication layer for DOTS management and configuration.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
o "This version of this YANG module is part of RFC XXXX;" o "This version of this YANG module is part of RFC XXXX;"
o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel"; (DOTS) Signal Channel";
o "| 3.00 | Alternate server | [RFCXXXX] |" o "| 3.00 | Alternate server | [RFCXXXX] |"
o reference: RFC XXXX o reference: RFC XXXX
o This RFC
Please update TBD statements with the port number to be assigned to
DOTS Signal Channel Protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 3, 2018. This Internet-Draft will expire on June 8, 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions and Terminology . . . . . . . . . . . 5 2. Notational Conventions and Terminology . . . . . . . . . . . 5
3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 5 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6
4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 7 4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 8
4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 7 4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 8
4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 8 4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 8
4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 9 4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 10
4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 10 4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 10
4.4.2. Withdraw a Mitigation . . . . . . . . . . . . . . . . 18 4.4.2. Retrieve Information Related to a Mitigation . . . . 19
4.4.3. Retrieve Information Related to a Mitigation . . . . 19 4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 27
4.4.4. Efficacy Update from DOTS Clients . . . . . . . . . . 26 4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 29
4.5. DOTS Signal Channel Session Configuration . . . . . . . . 28 4.5. DOTS Signal Channel Session Configuration . . . . . . . . 31
4.5.1. Discover Configuration Parameters . . . . . . . . . . 29 4.5.1. Discover Configuration Parameters . . . . . . . . . . 32
4.5.2. Convey DOTS Signal Channel Session Configuration . . 31 4.5.2. Convey DOTS Signal Channel Session Configuration . . 34
4.5.3. Delete DOTS Signal Channel Session Configuration . . 35 4.5.3. Delete DOTS Signal Channel Session Configuration . . 39
4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 36 4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 39
4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 37 4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 41
5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 38 5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . . . 42
5.1. Mitigation Request YANG Module Tree Structure . . . . . . 38 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 42
5.2. Mitigation Request YANG Module . . . . . . . . . . . . . 39 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 44
5.3. Session Configuration YANG Module Tree Structure . . . . 46 6. Mapping Parameters to CBOR . . . . . . . . . . . . . . . . . 53
5.4. Session Configuration YANG Module . . . . . . . . . . . . 46 7. (D)TLS Protocol Profile and Performance Considerations . . . 55
6. Mapping Parameters to CBOR . . . . . . . . . . . . . . . . . 48 7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 55
7. (D)TLS Protocol Profile and Performance Considerations . . . 50 7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 56
7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 50 7.3. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 57
7.2. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 51 8. Mutual Authentication of DOTS Agents & Authorization of DOTS
8. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . . . 52 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
9. Mutual Authentication of DOTS Agents & Authorization of DOTS 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 59
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 59
10.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . 54 9.3. CoAP Response Code . . . . . . . . . . . . . . . . . . . 59
10.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . 54 9.4. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 60
10.3. CoAP Response Code . . . . . . . . . . . . . . . . . . . 54 9.4.1. Registration Template . . . . . . . . . . . . . . . . 60
10.4. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 55 9.4.2. Initial Registry Contents . . . . . . . . . . . . . . 60
10.4.1. Registration Template . . . . . . . . . . . . . . . 55 9.5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . 66
10.4.2. Initial Registry Contents . . . . . . . . . . . . . 55 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 66
10.5. YANG Modules . . . . . . . . . . . . . . . . . . . . . . 60 10.1. nttdots . . . . . . . . . . . . . . . . . . . . . . . . 66
11. Implementation Status . . . . . . . . . . . . . . . . . . . . 61 11. Security Considerations . . . . . . . . . . . . . . . . . . . 67
11.1. nttdots . . . . . . . . . . . . . . . . . . . . . . . . 61 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 68
12. Security Considerations . . . . . . . . . . . . . . . . . . . 62 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 68
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 63 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 68
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 63 14.1. Normative References . . . . . . . . . . . . . . . . . . 68
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 63 14.2. Informative References . . . . . . . . . . . . . . . . . 70
15.1. Normative References . . . . . . . . . . . . . . . . . . 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74
15.2. Informative References . . . . . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68
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 4, line 4 skipping to change at page 4, line 9
simultaneous connections it can handle, limited resources of the simultaneous connections it can handle, limited resources of the
control plane, etc. When processing network traffic, such control plane, etc. When processing network traffic, such
applications are supposed to use these resources to offer the applications are supposed to use these resources to offer the
intended task in the most efficient fashion. However, a DDoS intended task in the most efficient fashion. However, a DDoS
attacker may be able to prevent an application from performing its attacker may be able to prevent an application from performing its
intended task by causing the application to exhaust the finite supply intended task by causing the application to exhaust the finite supply
of a specific resource. of a specific resource.
TCP DDoS SYN-flood, for example, is a memory-exhaustion attack on the TCP DDoS SYN-flood, for example, is a memory-exhaustion attack on the
victim and ACK-flood is a CPU exhaustion attack on the victim victim and ACK-flood is a CPU exhaustion attack on the victim
[RFC4987]. Attacks on the link are carried out by sending enough [RFC4987]. Attacks on the link are carried out by sending enough
traffic such that the link becomes excessively congested, and traffic such that the link becomes excessively congested, and
legitimate traffic suffers high packet loss. Stateful firewalls can legitimate traffic suffers high packet loss. Stateful firewalls can
also be attacked by sending traffic that causes the firewall to hold also be attacked by sending traffic that causes the firewall to hold
excessive state. The firewall then runs out of memory, and can no excessive state. The firewall then runs out of memory, and can no
longer instantiate the state required to pass legitimate flows. longer instantiate the state required to pass legitimate flows.
Other possible DDoS attacks are discussed in [RFC4732]. Other possible DDoS attacks are discussed in [RFC4732].
In many cases, it may not be possible for network administrators to In many cases, it may not be possible for network administrators to
determine the causes of an attack, but instead just realize that determine the causes of an attack, but instead just realize that
certain resources seem to be under attack. This document defines a certain resources seem to be under attack. This document defines a
lightweight protocol permitting a DOTS client to request mitigation lightweight protocol permitting a DOTS client to request mitigation
from one or more DOTS servers for protection against detected, from one or more DOTS servers for protection against detected,
suspected, or anticipated attacks. This protocol enables cooperation suspected, or anticipated attacks. This protocol enables cooperation
between DOTS agents to permit a highly-automated network defense that between DOTS agents to permit a highly-automated network defense that
is robust, reliable and secure. is robust, reliable, and secure.
An example of network diagram showing a deployment of DOTS agents is An example of network diagram showing a deployment of DOTS agents is
shown in Figure 1. In this example, the DOTS server is operating on shown in Figure 1. In this example, the DOTS server is operating on
the access network. The DOTS client is located on the LAN (Local the access network. The DOTS client is located on the LAN (Local
Area Network), while a DOTS gateway is embedded in the CPE (Customer Area Network), while a DOTS gateway is embedded in the CPE (Customer
Premises Equipment). Premises Equipment).
Network Network
Resource CPE router Access network __________ Resource CPE router Access network __________
+-----------+ +--------------+ +-------------+ / \ +-----------+ +--------------+ +-------------+ / \
| |____| |_______| |___ | Internet | | |____| |_______| |___ | Internet |
|DOTS client| | DOTS gateway | | DOTS server | | | |DOTS client| | DOTS gateway | | DOTS server | | |
| | | | | | | | | | | | | | | |
+-----------+ +--------------+ +-------------+ \__________/ +-----------+ +--------------+ +-------------+ \__________/
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 reachable over the Internet, as depicted
Figure 2. in 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 a client is embedded in a firewall protecting services owned and
domain, while the DOTS server is owned and operated by a different operated by a domain, while the DOTS server is owned and operated by
domain providing DDoS mitigation services. That domain providing a different domain providing DDoS mitigation services. That domain
DDoS mitigation service might, or might not, also provide Internet providing DDoS mitigation service might, or might not, provide
access service to the website operator. connectivity service to the network hosting the DOTS client.
The DOTS server may (not) be co-located with the DOTS mitigator. In The DOTS server may (not) be co-located with the DOTS mitigator. In
typical deployments, the DOTS server belongs to the same typical deployments, the DOTS server belongs to the same
administrative domain as the mitigator. The DOTS client can administrative domain as the mitigator. The DOTS client can
communicate directly with the DOTS server or indirectly via a DOTS communicate directly with a DOTS server or indirectly via a DOTS
gateway. gateway.
The document adheres to the DOTS architecture The document adheres to the DOTS architecture
[I-D.ietf-dots-architecture]. The requirements for DOTS signal [I-D.ietf-dots-architecture]. The requirements for DOTS signal
channel protocol are obtained from [I-D.ietf-dots-requirements]. channel protocol are obtained from [I-D.ietf-dots-requirements].
This document satisfies all the use cases discussed in This document satisfies all the use cases discussed in
[I-D.ietf-dots-use-cases]. [I-D.ietf-dots-use-cases].
This document focuses on the DOTS signal channel. This is a This document focuses on the DOTS signal channel. This is a
companion document to the DOTS data channel specification companion document to the DOTS data channel specification
[I-D.ietf-dots-data-channel] that defines a configuration and bulk [I-D.ietf-dots-data-channel] that defines a configuration and bulk
data exchange mechanism supporting the DOTS signal channel. data exchange mechanism supporting the DOTS signal channel.
2. Notational Conventions and Terminology 2. Notational Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
(D)TLS: For brevity this term is used for statements that apply to (D)TLS is used for statements that apply to both Transport Layer
both Transport Layer Security [RFC5246] and Datagram Transport Layer Security [RFC5246] and Datagram Transport Layer Security [RFC6347].
Security [RFC6347]. Specific terms will be used for any statement Specific terms will be used for any statement that applies to either
that applies to either protocol alone. protocol alone.
The reader should be familiar with the terms defined in The reader should be familiar with the terms defined in
[I-D.ietf-dots-architecture]. [I-D.ietf-dots-architecture].
The meaning of the symbols in YANG tree diagrams is defined in The meaning of the symbols in YANG tree diagrams is defined in
[I-D.ietf-netmod-yang-tree-diagrams]. [I-D.ietf-netmod-yang-tree-diagrams].
3. Design Overview 3. Design Overview
The DOTS signal channel is built on top of the Constrained The DOTS signal channel is built on top of the Constrained
skipping to change at page 6, line 26 skipping to change at page 6, line 40
+--------------+ +--------------+
| TCP | UDP | | TCP | UDP |
+--------------+ +--------------+
| IP | | IP |
+--------------+ +--------------+
Figure 3: Abstract Layering of DOTS signal channel over CoAP over Figure 3: Abstract Layering of DOTS signal channel over CoAP over
(D)TLS (D)TLS
By default, DOTS signal channel MUST run over port number TBD as By default, DOTS signal channel MUST run over port number TBD as
defined in Section 10.1, for both UDP and TCP, unless the DOTS server defined in Section 9.1, for both UDP and TCP, unless the DOTS server
has mutual agreement with its DOTS clients to use a port other than has mutual agreement with its DOTS clients to use a port number other
TBD for DOTS signal channel, or DOTS clients supports means to than TBD for DOTS signal channel, or DOTS clients supports means to
dynamically discover the ports used by their DOTS servers. In order dynamically discover the ports used by their DOTS servers. In order
to use a distinct port number (vs. TBD), DOTS clients and servers to use a distinct port number (vs. TBD), DOTS clients and servers
should support a configurable parameter to supply the port number to should support a configurable parameter to supply the port number to
use. use. The rationale for not using the default port number 5684
((D)TLS CoAP) is to allow for differentiated behaviors in deployment
contexts where both a DOTS gateway and an IoT gateway (e.g., Figure 3
of [RFC7452]) are present.
The signal channel is initiated by the DOTS client (Section 4.4). The signal channel is initiated by the DOTS client (Section 4.4).
Once the signal channel is established, the DOTS agents periodically Once the signal channel is established, the DOTS agents periodically
send heartbeats to keep the channel active (Section 4.7). At any send heartbeats to keep the channel active (Section 4.7). At any
time, the DOTS client may send a mitigation request message to a DOTS time, the DOTS client may send a mitigation request message to a DOTS
server over the active channel. While mitigation is active, due to server over the active channel. While mitigation is active, due to
the higher likelihood of packet loss during a DDoS attack, the DOTS the higher likelihood of packet loss during a DDoS attack, the DOTS
server periodically sends status messages to the client, including server periodically sends status messages to the client, including
basic mitigation feedback details. Mitigation remains active until basic mitigation feedback details. Mitigation remains active until
the DOTS client explicitly terminates mitigation, or the mitigation the DOTS client explicitly terminates mitigation, or the mitigation
lifetime expires. lifetime expires.
DOTS signaling can happen with DTLS [RFC6347] over UDP and TLS DOTS signaling can happen with DTLS [RFC6347] over UDP and TLS
[RFC5246] over TCP. Likewise, requests may be sent using IPv4 or [RFC5246] over TCP. Likewise, DOTS requests may be sent using IPv4
IPv6 transfer capabilities. A Happy Eyeballs procedure for DOTS or IPv6 transfer capabilities. A Happy Eyeballs procedure for DOTS
signal channel is specified in Section 4.3. signal channel is specified in Section 4.3.
Messages exchanged between DOTS clients and servers are serialized Messages exchanged between DOTS agents are serialized using Concise
using Concise Binary Object Representation (CBOR) [RFC7049], CBOR is Binary Object Representation (CBOR) [RFC7049], CBOR is a binary
a binary encoding designed for small code and message size. CBOR encoding designed for small code and message size. CBOR encoded
encoded payloads are used to convey signal channel specific payload payloads are used to convey signal channel specific payload messages
messages that convey request parameters and response information such that convey request parameters and response information such as
as errors. This specification uses the encoding rules defined in errors. This specification uses the encoding rules defined in
[I-D.ietf-core-yang-cbor] for representing mitigation scope and DOTS [I-D.ietf-core-yang-cbor] for representing mitigation scope and DOTS
signal channel session configuration data defined using YANG signal channel session configuration data defined using YANG
(Section 5) as CBOR data. (Section 5) as CBOR data.
In order to prevent fragmentation, DOTS agents must follow the In order to prevent fragmentation, DOTS agents must follow the
recommendations in Section 4.6 of [RFC7252]. Refer to Section 7.2 recommendations in Section 4.6 of [RFC7252]. Refer to Section 7.3
for more details. for more details.
DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The
payload included in CoAP responses with 2.xx and 3.xx Response Codes payload included in CoAP responses with 2.xx and 3.xx Response Codes
MUST be of content type "application/cbor" (Section 5.5.1 of MUST be of content type "application/cbor" (Section 5.5.1 of
[RFC7252]). CoAP responses with 4.xx and 5.xx error Response Codes [RFC7252]). CoAP responses with 4.xx and 5.xx error Response Codes
MUST include a diagnostic payload (Section 5.5.2 of [RFC7252]). The MUST include a diagnostic payload (Section 5.5.2 of [RFC7252]). The
Diagnostic Payload may contain additional information to aid Diagnostic Payload may contain additional information to aid
troubleshooting. troubleshooting.
In deployments where multiple DOTS clients are enabled in a network In deployments where multiple DOTS clients are enabled in a network
(owned by the same entity), the DOTS server may detect conflicting (owned by the same entity), the DOTS server may detect conflicting
mitigation requests from these clients. This document does not aim mitigation requests from these clients. This document does not aim
to specify a comprehensive list of conditions under which a DOTS to specify a comprehensive list of conditions under which a DOTS
server will characterize two mitigation requests from distinct DOTS server will characterize two mitigation requests from distinct DOTS
clients as conflicting, nor recommend a DOTS server behavior for clients as conflicting, nor recommend a DOTS server behavior for
processing conflicting mitigation requests. Those considerations are processing conflicting mitigation requests. Those considerations are
implementation- and deployment-specific. Nevertheless, the document implementation- and deployment-specific. Nevertheless, the document
specifies the mechanisms to notify DOTS clients when conflicts occur, specifies the mechanisms to notify DOTS clients when conflicts occur,
including the conflict cause. including the conflict cause (Section 4.4).
4. DOTS Signal Channel: Messages & Behaviors 4. DOTS Signal Channel: Messages & Behaviors
4.1. DOTS Server(s) Discovery 4.1. DOTS Server(s) Discovery
This document assumes that DOTS clients are provisioned with the This document assumes that DOTS clients are provisioned with the
reachability information of their DOTS server(s) using a variety of reachability information of their DOTS server(s) using a variety of
means (e.g., local configuration, or dynamic means such as DHCP). means (e.g., local configuration, or dynamic means such as DHCP).
These means are out of scope of this document. These means are out of scope of this document.
skipping to change at page 8, line 45 skipping to change at page 9, line 10
UDP and TCP. UDP and TCP.
If an IPv4 path to reach a DOTS server is found, but the DOTS If an IPv4 path to reach a DOTS server is found, but the DOTS
server's IPv6 path is not working, a dual-stack DOTS client can server's IPv6 path is not working, a dual-stack DOTS client can
experience a significant connection delay compared to an IPv4-only experience a significant connection delay compared to an IPv4-only
DOTS client. The other problem is that if a middlebox between the DOTS client. The other problem is that if a middlebox between the
DOTS client and DOTS server is configured to block UDP, the DOTS DOTS client and DOTS server is configured to block UDP, the DOTS
client will fail to establish a DTLS session with the DOTS server and client will fail to establish a DTLS session with the DOTS server and
will, then, have to fall back to TLS over TCP incurring significant will, then, have to fall back to TLS over TCP incurring significant
connection delays. [I-D.ietf-dots-requirements] discusses that DOTS connection delays. [I-D.ietf-dots-requirements] discusses that DOTS
client and server will have to support both connectionless and agents will have to support both connectionless and connection-
connection-oriented protocols. oriented protocols.
To overcome these connection setup problems, the DOTS client can try To overcome these connection setup problems, the DOTS client can try
connecting to the DOTS server using both IPv6 and IPv4, and try both connecting to the DOTS server using both IPv6 and IPv4, and try both
DTLS over UDP and TLS over TCP in a fashion similar to the Happy DTLS over UDP and TLS over TCP in a fashion similar to the Happy
Eyeballs mechanism [RFC6555]. These connection attempts are Eyeballs mechanism [RFC6555]. These connection attempts are
performed by the DOTS client when its initializes, and the client performed by the DOTS client when its initializes, and the client
uses that information for its subsequent alert to the DOTS server. uses that information for its subsequent alert to the DOTS server.
In order of preference (most preferred first), it is UDP over IPv6, In order of preference (most preferred first), it is UDP over IPv6,
UDP over IPv4, TCP over IPv6, and finally TCP over IPv4, which UDP over IPv4, TCP over IPv6, and finally TCP over IPv4, which
adheres to address preference order [RFC6724] and the DOTS preference adheres to address preference order [RFC6724] and the DOTS preference
skipping to change at page 9, line 43 skipping to change at page 10, line 10
over UDP becomes available from the DOTS server, so the DOTS client over UDP becomes available from the DOTS server, so the DOTS client
can migrate the DOTS signal channel from TCP to UDP, but such probing can migrate the DOTS signal channel from TCP to UDP, but such probing
SHOULD NOT be done more frequently than every 24 hours and MUST NOT SHOULD NOT be done more frequently than every 24 hours and MUST NOT
be done more frequently than every 5 minutes. be done more frequently than every 5 minutes.
4.4. DOTS Mitigation Methods 4.4. DOTS Mitigation Methods
The following methods are used by a DOTS client to request, withdraw, The following methods are used by a DOTS client to request, withdraw,
or retrieve the status of mitigation requests: or retrieve the status of mitigation requests:
PUT: DOTS clients use the PUT method to request mitigation from a PUT: DOTS clients use the PUT method to request mitigation from a
DOTS server (Section 4.4.1). During active mitigation, DOTS DOTS server (Section 4.4.1). During active mitigation, DOTS
clients may use PUT requests to convey mitigation efficacy updates clients may use PUT requests to convey mitigation efficacy
to the DOTS server (Section 4.4.4). updates to the DOTS server (Section 4.4.3).
DELETE: DOTS clients use the DELETE method to withdraw a request for GET: DOTS clients may use the GET method to subscribe to DOTS
mitigation from the DOTS server (Section 4.4.2). server status messages, or to retrieve the list of its
mitigations maintained by a DOTS server (Section 4.4.2).
GET: DOTS clients may use the GET method to subscribe to DOTS server DELETE: DOTS clients use the DELETE method to withdraw a request for
status messages, or to retrieve the list of existing mitigations mitigation from a DOTS server (Section 4.4.4).
(Section 4.4.3).
Mitigation request and response messages are marked as Non- Mitigation request and response messages are marked as Non-
confirmable messages. DOTS agents SHOULD follow the data confirmable messages (Section 2.2 of [RFC7252]).
transmission guidelines discussed in Section 3.1.3 of [RFC8085] and
control transmission behavior by not sending on average more than one DOTS agents SHOULD follow the data transmission guidelines discussed
UDP datagram per RTT to the peer DOTS agent. in Section 3.1.3 of [RFC8085] and control transmission behavior by
not sending on average more than one UDP datagram per RTT to the peer
DOTS agent.
Requests marked by the DOTS client as Non-confirmable messages are Requests marked by the DOTS client as Non-confirmable messages are
sent at regular intervals until a response is received from the DOTS sent at regular intervals until a response is received from the DOTS
server. If the DOTS client cannot maintain an RTT estimate, it server. If the DOTS client cannot maintain an RTT estimate, it
SHOULD NOT send more than one Non-confirmable request every 3 SHOULD NOT send more than one Non-confirmable request every 3
seconds, and SHOULD use an even less aggressive rate when possible seconds, and SHOULD use an even less aggressive rate when possible
(case 2 in Section 3.1.3 of [RFC8085]). (case 2 in Section 3.1.3 of [RFC8085]).
4.4.1. Request Mitigation 4.4.1. Request Mitigation
When a DOTS client requires mitigation for any reason, the DOTS When a DOTS client requires mitigation for any reason, the DOTS
client uses CoAP PUT method to send a mitigation request to the DOTS client uses CoAP PUT method to send a mitigation request to its DOTS
server(s) (Figure 5, illustrated in JSON diagnostic notation). If server(s) (Figure 5, illustrated in JSON diagnostic notation). If
this DOTS client is entitled to solicit the DOTS service, the DOTS this DOTS client is entitled to solicit the DOTS service, the DOTS
server can enable mitigation on behalf of the DOTS client by server can enable mitigation on behalf of the DOTS client by
communicating the DOTS client's request to the mitigator and relaying communicating the DOTS client's request to the mitigator and relaying
selected mitigator feedback to the requesting DOTS client. selected mitigator feedback to the requesting DOTS client.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Host: "host" Uri-Host: "host"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
skipping to change at page 12, line 29 skipping to change at page 12, line 29
This is an optional attribute. This is an optional attribute.
mitigation-id: Identifier for the mitigation request represented mitigation-id: Identifier for the mitigation request represented
using an integer. This identifier MUST be unique for each using an integer. This identifier MUST be unique for each
mitigation request bound to the DOTS client, i.e., the mitigation- mitigation request bound to the DOTS client, i.e., the mitigation-
id parameter value in the mitigation request needs to be unique id parameter value in the mitigation request needs to be unique
relative to the mitigation-id parameter values of active relative to the mitigation-id parameter values of active
mitigation requests conveyed from the DOTS client to the DOTS mitigation requests conveyed from the DOTS client to the DOTS
server. This identifier MUST be generated by the DOTS client. server. This identifier MUST be generated by the DOTS client.
This document does not make any assumption about how this This document does not make any assumption about how this
identifier is generated. This is a mandatory attribute. identifier is generated.
target-ip: A list of IP addresses under attack. This is an optional This is a mandatory attribute.
attribute.
target-prefix: A list of prefixes under attack. Prefixes are target-ip: A list of IP addresses identifying resources under
represented using CIDR notation [RFC4632]. This is an optional attack. This is an optional attribute.
attribute.
target-port-range: A list of ports under attack. The port range, target-prefix: A list of prefixes identifying resources under
lower-port for lower port number and upper-port for upper port attack. Prefixes are represented using Classless Inter-domain
number. When only lower-port is present, it represents a single Routing (CIDR) notation [RFC4632].
port. For TCP, UDP, Stream Control Transmission Protocol (SCTP)
[RFC4960], or Datagram Congestion Control Protocol (DCCP)
[RFC4340]: the range of ports (e.g., 1024-65535). This is an
optional attribute.
target-protocol: A list of protocols under attack. Values are taken 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.
target-fqdn: A list of Fully Qualified Domain Names. Fully target-port-range: A list of port numbers bound to resources under
Qualified Domain Name (FQDN) is the full name of a system, rather attack.
than just its hostname. For example, "venera" is a hostname, and
"venera.isi.edu" is an FQDN. This is an optional attribute.
target-uri: A list of Uniform Resource Identifiers (URI). This is The port range is defined by two bounds, a lower port number
an optional attribute. (lower-port) and an upper port number (upper-port). When only
'lower-port' is present, it represents a single port number. For
TCP, UDP, Stream Control Transmission Protocol (SCTP) [RFC4960],
or Datagram Congestion Control Protocol (DCCP) [RFC4340], the
range of ports can be, for example, 1024-65535.
alias-name: A list of aliases. Aliases can be created using the This is an optional attribute.
DOTS data channel (Section 3.1.1 of [I-D.ietf-dots-data-channel])
or direct configuration, or other means and then used in target-protocol: A list of protocols involved in an attack. Values
subsequent signal channel exchanges to refer more efficiently to are taken from the IANA protocol registry [proto_numbers].
the resources under attack. This is an optional attribute.
The value 0 has a special meaning for 'all protocols'.
This is an optional attribute.
target-fqdn: A list of Fully Qualified Domain Names (FQDNs)
identifying resources under attack. An FQDN is the full name of a
resource, rather than just its hostname. For example, "venera" is
a hostname, and "venera.isi.edu" is an FQDN.
This is an optional attribute.
target-uri: A list of Uniform Resource Identifiers (URIs) [RFC3986]
identifying resources under attack.
This is an optional attribute.
alias-name: A list of aliases of resources for which the mitigation
is requested. Aliases can be created using the DOTS data channel
(Section 6.1 of [I-D.ietf-dots-data-channel]), direct
configuration, or other means. An alias is used in subsequent
signal channel exchanges to refer more efficiently to the
resources under attack.
This is an optional attribute.
lifetime: Lifetime of the mitigation request in seconds. The lifetime: Lifetime of the mitigation request in seconds. The
RECOMMENDED lifetime of a mitigation request is 3600 seconds (60 RECOMMENDED lifetime of a mitigation request is 3600 seconds (60
minutes) -- this value was chosen to be long enough so that minutes) -- this value was chosen to be long enough so that
refreshing is not typically a burden on the DOTS client, while refreshing is not typically a burden on the DOTS client, while
expiring the request where the client has unexpectedly quit in a expiring the request where the client has unexpectedly quit in a
timely manner. timely manner. DOTS clients MUST include this parameter in their
mitigation requests. Upon the expiry of this lifetime, and if the
request is not refreshed, the mitigation request is removed. The
request can be refreshed by sending the same request again.
A lifetime of 0 in a mitigation request is an invalid value.
A lifetime of negative one (-1) indicates indefinite lifetime for A lifetime of negative one (-1) indicates indefinite lifetime for
the mitigation request. A lifetime of 0 in the request is an the mitigation request. The DOTS server MAY refuse indefinite
invalid value. lifetime, for policy reasons; the granted lifetime value is
returned in the response. DOTS clients MUST be prepared to not be
granted mitigations with indefinite lifetimes.
DOTS clients MUST include this parameter in their mitigation The DOTS server MUST always indicate the actual lifetime in the
requests. Upon the expiry of this lifetime, and if the request is
not refreshed, the mitigation request is removed. The request can
be refreshed by sending the same request again. The server MAY
refuse indefinite lifetime, for policy reasons; the granted
lifetime value is returned in the response. DOTS clients MUST be
prepared to not be granted mitigations with indefinite lifetimes.
The server MUST always indicate the actual lifetime in the
response and the remaining lifetime in status messages sent to the response and the remaining lifetime in status messages sent to the
client. This is a mandatory attribute. DOTS client.
This is a mandatory attribute.
Because of the complexity to handle partial failure cases, this
specification does not allow for including multiple mitigation
requests in the same PUT request. Concretely, a DOTS client MUST NOT
include multiple 'scope' parameters in the same PUT request.
The CBOR key values for the parameters are defined in Section 6. The CBOR key values for the parameters are defined in Section 6.
Section 10 defines how the CBOR key values can be allocated to Section 9 defines how the CBOR key values can be allocated to
standards bodies and vendors. standards bodies and vendors.
FQDN and URI mitigation scopes may be thought of as a form of scope FQDN and URI mitigation scopes may be thought of as a form of scope
alias, in which the addresses to which the domain name or URI resolve alias, in which the addresses to which the domain name or URI resolve
represent the full scope of the mitigation. represent the full scope of the mitigation.
In the PUT request at least one of the attributes 'target-ip' or In the PUT request at least one of the attributes 'target-ip' or
'target-prefix' or 'target-fqdn' or 'target-uri 'or 'alias-name' MUST 'target-prefix' or 'target-fqdn' or 'target-uri 'or 'alias-name' MUST
be present. If the attribute value is empty, then the attribute MUST be present. If the attribute value is empty, then the attribute MUST
NOT be present in the request. DOTS agents can safely ignore Vendor- NOT be present in the request.
Specific parameters they don't understand.
The relative order of two mitigation requests from a DOTS client is The relative order of two mitigation requests from a DOTS client is
determined by comparing their respective 'mitigation-id' values. If determined by comparing their respective 'mitigation-id' values. If
two mitigation requests have overlapping mitigation scopes, the two mitigation requests have overlapping mitigation scopes, the
mitigation request with higher numeric 'mitigation-id' value will mitigation request with higher numeric 'mitigation-id' value will
override the mitigation request with a lower numeric 'mitigation-id' override the mitigation request with a lower numeric 'mitigation-id'
value. Two mitigation-ids from a DOTS client are overlapping if value. Two mitigation-ids from a DOTS client are overlapping if
there is a common IP address, IP prefix, FQDN, URI, or alias-name. there is a common IP address, IP prefix, FQDN, URI, or alias-name.
To avoid maintaining a long list of overlapping mitigation requests To avoid maintaining a long list of overlapping mitigation requests
from a DOTS client and avoid error-prone provisioning of mitigation from a DOTS client and avoid error-prone provisioning of mitigation
requests from a DOTS client, the overlapped lower numeric requests from a DOTS client, the overlapped lower numeric
'mitigation-id' MUST be automatically deleted and no longer available 'mitigation-id' MUST be automatically deleted and no longer available
at the DOTS server. at the DOTS server.
The Uri-Path option carries a major and minor version nomenclature to The Uri-Path option carries a major and minor version nomenclature to
manage versioning and DOTS signal channel in this specification uses manage versioning and DOTS signal channel in this specification uses
v1 major version. v1 major version.
If the DOTS client is using the certificate provisioned by the
Enrollment over Secure Transport (EST) server [RFC7030] in the DOTS
gateway-domain to authenticate itself to the DOTS gateway, then the
'client-identifier' value can be the output of a cryptographic hash
algorithm whose input is the DER-encoded ASN.1 representation of the
Subject Public Key Info (SPKI) of an X.509 certificate. In this
version of the specification, the cryptographic hash algorithm used
is SHA-256 [RFC6234]. The output of the cryptographic hash algorithm
is truncated to 16 bytes; truncation is done by stripping off the
final 16 bytes. The truncated output is base64url encoded. If the
'client-identifier' value is already present in the mitigation
request received from the DOTS client, the DOTS gateway MAY compute
the 'client-identifier' value, as discussed above, and add the
computed 'client-identifier' value to the end of the 'client-
identifier' list. The DOTS server MUST NOT use the 'client-
identifier' for the DOTS client authentication process.
In both DOTS signal and data channel sessions, the DOTS client MUST
authenticate itself to the DOTS server (Section 9). The DOTS server
may use the algorithm in Section 7 of [RFC7589] to derive the DOTS
client identity or username from the client certificate. The DOTS
client identity allows the DOTS server to accept mitigation requests
with scopes which the DOTS client is authorized to manage. The DOTS
server couples the DOTS signal and data channel sessions using the
DOTS client identity and the 'client-identifier' parameter value, so
the DOTS server can validate whether the aliases conveyed in the
mitigation request were indeed created by the same DOTS client using
the DOTS data channel session. If the aliases were not created by
the DOTS client, the DOTS server returns 4.00 (Bad Request) in the
response.
The DOTS server couples the DOTS signal channel sessions using the
DOTS client identity and the 'client-identifier' parameter value, and
the DOTS server uses 'mitigation-id' parameter value to detect
duplicate mitigation requests. If the mitigation request contains
both alias-name and other parameters identifying the target resources
(such as, 'target-ip', 'target-prefix', 'target-port-range', 'target-
fqdn', or 'target-uri'), then the DOTS server appends the parameter
values in 'alias-name' with the corresponding parameter values in
'target-ip', 'target-prefix', 'target-port-range', 'target-fqdn', or
'target-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: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1" Uri-Path: "v1"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"mitigation-scope": { "mitigation-scope": {
"client-identifier": [ "client-identifier": [
"dz6pHjaADkaFTbjr0JGBpw" "dz6pHjaADkaFTbjr0JGBpw"
], ],
"scope": [ "scope": [
{ {
"mitigation-id": 12332, "mitigation-id": 12332,
"target-ip": [ "target-ip": [
"2001:db8:6401::1", "2001:db8:6401::1",
"2001:db8:6401::2" "2001:db8:6401::2"
], ],
"target-port-range": [ "target-port-range": [
{ {
"lower-port": 80 "lower-port": 80
}, },
{ {
"lower-port": 443 "lower-port": 443
}, },
{ {
"lower-port": 8080 "lower-port": 8080
} }
], ],
"target-protocol": [ "target-protocol": [
6 6
] ]
}
]
}
}
} Figure 6: PUT for DOTS signal
]
}
}
The CBOR encoding format is shown below: The corresponding CBOR encoding format is shown in Figure 7.
A1 # map(1) A1 # map(1)
01 # unsigned(1) 01 # unsigned(1)
A2 # map(2) A2 # map(2)
18 20 # unsigned(32) 18 20 # unsigned(32)
81 # array(1) 81 # array(1)
76 # text(22) 76 # text(22)
647A3670486A6141446B614654626A72304A47427077 # "dz6pHjaADkaFTbjr0JGBpw" 647A3670486A6141446B614654626A72304A47427077 # "dz6pHjaADkaFTbjr0JGBpw"
02 # unsigned(2) 02 # unsigned(2)
81 # array(1) 81 # array(1)
skipping to change at page 16, line 45 skipping to change at page 16, line 38
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: PUT for DOTS signal Figure 7: PUT for DOTS signal (CBOR)
If the DOTS client is using the certificate provisioned by the
Enrollment over Secure Transport (EST) server [RFC7030] in the DOTS
gateway-domain to authenticate itself to the DOTS gateway, then the
'client-identifier' value can be the output of a cryptographic hash
algorithm whose input is the DER-encoded ASN.1 representation of the
Subject Public Key Info (SPKI) of an X.509 certificate. In this
version of the specification, the cryptographic hash algorithm used
is SHA-256 [RFC6234]. The output of the cryptographic hash algorithm
is truncated to 16 bytes; truncation is done by stripping off the
final 16 bytes. The truncated output is base64url encoded. If the
'client-identifier' value is already present in the mitigation
request received from the DOTS client, the DOTS gateway MAY compute
the 'client-identifier' value, as discussed above, and add the
computed 'client-identifier' value to the end of the 'client-
identifier' list. The DOTS server MUST NOT use the 'client-
identifier' for the DOTS client authentication process.
In both DOTS signal and data channel sessions, the DOTS client MUST
authenticate itself to the DOTS server (Section 8). The DOTS server
may use the algorithm in Section 7 of [RFC7589] to derive the DOTS
client identity or username from the client certificate. The DOTS
client identity allows the DOTS server to accept mitigation requests
with scopes which the DOTS client is authorized to manage. The DOTS
server couples the DOTS signal and data channel sessions using the
DOTS client identity and the 'client-identifier' parameter value, so
the DOTS server can validate whether the aliases conveyed in the
mitigation request were indeed created by the same DOTS client using
the DOTS data channel session. If the aliases were not created by
the DOTS client, the DOTS server returns 4.00 (Bad Request) in the
response.
The DOTS server uses 'mitigation-id' parameter value to detect
duplicate mitigation requests. If the mitigation request contains
both alias-name and other parameters identifying the target resources
(such as, 'target-ip', 'target-prefix', 'target-port-range', 'target-
fqdn', or 'target-uri'), then the DOTS server appends the parameter
values in 'alias-name' with the corresponding parameter values in
'target-ip', 'target-prefix', 'target-port-range', 'target-fqdn', or
'target-uri'.
The DOTS server indicates the result of processing the PUT request The DOTS server indicates the result of processing the PUT request
using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx using CoAP response codes. CoAP 2.xx codes are success. CoAP 4.xx
codes are some sort of invalid requests (client errors). COAP 5.xx codes are some sort of invalid requests (client errors). COAP 5.xx
codes are returned if the DOTS server has erred or is currently codes are returned if the DOTS server has erred or is currently
unavailable to provide mitigation in response to the mitigation unavailable to provide mitigation in response to the mitigation
request from the DOTS client. request from the DOTS client.
Figure 7 shows an example of a PUT request that is successfully Figure 8 shows an example of a PUT request that is successfully
processed (i.e., CoAP 2.xx response codes). processed (i.e., CoAP 2.xx response codes).
{ {
"mitigation-scope": { "mitigation-scope": {
"client-identifier": [ "client-identifier": [
"string" "string"
], ],
"scope": [ "scope": [
{ {
"mitigation-id": integer, "mitigation-id": integer,
"lifetime": integer "lifetime": integer
} }
] ]
} }
} }
Figure 7: 2.xx response body Figure 8: 2.xx response body
If the request is missing one or more mandatory attributes, includes
multiple 'scope' parameters, or contains invalid or unknown
parameters, the DOTS server replies with 4.00 (Bad Request). DOTS
agents can safely ignore Vendor-Specific parameters they don't
understand.
A DOTS server that receives a mitigation request with a lifetime set
to 0 MUST reply with a 4.00 (Bad Request).
If the DOTS server does not find the 'mitigation-id' parameter value If the DOTS server does not find the 'mitigation-id' parameter value
conveyed in the PUT request in its configuration data, then the conveyed in the PUT request in its configuration data, it MAY accept
server MAY accept the mitigation request by sending back a 2.01 the mitigation request by sending back a 2.01 (Created) response to
(Created) response to the DOTS client; the DOTS server will the DOTS client; the DOTS server will consequently try to mitigate
consequently try to mitigate the attack. the attack.
If the DOTS server finds the 'mitigation-id' parameter value conveyed If the DOTS server finds the 'mitigation-id' parameter value conveyed
in the PUT request in its configuration data, then the server MAY in the PUT request in its configuration data, it MAY update the
update the mitigation request, and a 2.04 (Changed) response is mitigation request, and a 2.04 (Changed) response is returned to
returned to indicate a successful update of the mitigation request. indicate a successful update of the mitigation request.
If the request is missing one or more mandatory attributes, then 4.00
(Bad Request) will be returned in the response or if the request
contains invalid or unknown parameters then 4.02 (Invalid query) is
returned in the response.
If the request is conflicting with an existing mitigation request If the request is conflicting with an existing mitigation request
from a different DOTS client, and the DOTS server decides to maintain from a different DOTS client, and the DOTS server decides to maintain
the conflicting mitigation request, the DOTS server returns 4.09 the conflicting mitigation request, the DOTS server returns 4.09
(Conflict) [RFC8132] to the requesting DOTS client. (Conflict) [RFC8132] to the requesting DOTS client. The response
includes enough information for a DOTS client to recognize the source
of the conflict (refer to 'conflict-information' specified in
Section 4.4.2).
For a mitigation request to continue beyond the initial negotiated For a mitigation request to continue beyond the initial negotiated
lifetime, the DOTS client need to refresh the current mitigation lifetime, the DOTS client has to refresh the current mitigation
request by sending a new PUT request. The PUT request MUST use the request by sending a new PUT request. This PUT request MUST use the
same 'mitigation-id' value, and MUST repeat all the other parameters same 'mitigation-id' value, and MUST repeat all the other parameters
as sent in the original mitigation request apart from a possible as sent in the original mitigation request apart from a possible
change to the lifetime parameter value. change to the lifetime parameter value.
A DOTS gateway MUST update the 'client-identifier' list in the A DOTS gateway MUST update the 'client-identifier' list in the
response to remove the 'client-identifier' value it had added in the response to remove the 'client-identifier' value it had added in the
corresponding request before forwarding the response to the DOTS corresponding request before forwarding the response to the DOTS
client. client.
4.4.2. Withdraw a Mitigation 4.4.2. Retrieve Information Related to a Mitigation
A DELETE request is used to withdraw a DOTS mitigation request from a
DOTS server (Figure 8).
Header: DELETE (Code=0.04)
Uri-Host: "host"
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "version"
Uri-Path: "mitigate"
Content-Format: "application/cbor"
{
"mitigation-scope": {
"client-identifier": [
"string"
],
"scope": [
{
"mitigation-id": integer
}
]
}
}
Figure 8: Withdraw DOTS signal
The DOTS server immediately acknowledges a DOTS client's request to A GET request is used to retrieve information (including status) of a
withdraw the DOTS signal using 2.02 (Deleted) response code with no DOTS mitigation from a DOTS server. If the DOTS server does not find
response payload. A 2.02 (Deleted) Response Code is returned even if the 'mitigation-id' parameter value conveyed in the GET request in
the 'mitigation-id' parameter value conveyed in the DELETE request its configuration data, it responds with a 4.04 (Not Found) error
does not exist in its configuration data before the request. response code.
If the DOTS server finds the 'mitigation-id' parameter value conveyed The 'c' (content) parameter and its permitted values defined in
in the DELETE request in its configuration data, then to protect [I-D.ietf-core-comi] can be used to retrieve non-configuration data
against route or DNS flapping caused by a client rapidly toggling (attack mitigation status) or configuration data or both. The DOTS
mitigation, and to dampen the effect of oscillating attacks, DOTS server SHOULD support this optional filtering capability but can
servers MAY allow mitigation to continue for a limited period after safely ignore it if not supported.
acknowledging a DOTS client's withdrawal of a mitigation request.
During this period, the DOTS server status messages SHOULD indicate
that mitigation is active but terminating. The initial active-but-
terminating period SHOULD be sufficiently long to absorb latency
incurred by route propagation. The active-but-terminating period
SHOULD be set by default to 120 seconds. If the client requests
mitigation again before the initial active-but-terminating period
elapses, the DOTS server MAY exponentially increase the active-but-
terminating period up to a maximum of 300 seconds (5 minutes). After
the active-but-terminating period elapses, the DOTS 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.
4.4.3. Retrieve Information Related to a Mitigation The following examples illustrate how a DOTS client retrieves active
mitigation requests from a DOTS server. In particular:
A GET request is used to retrieve information (including status) of a o Figure 9 shows the example of a GET request to retrieve all DOTS
DOTS mitigation from a DOTS server (Figure 9). If the DOTS server mitigation requests signaled by a DOTS client.
does not find the 'mitigation-id' parameter value conveyed in the GET
request in its configuration data, then it responds with a 4.04 (Not
Found) error response code. The 'c' (content) parameter and its
permitted values defined in [I-D.ietf-core-comi] can be used to
retrieve non-configuration data (attack mitigation status) or
configuration data or both. The DOTS server SHOULD support this
optional filtering capability but can safely ignore it if not
supported.
The examples depicted in Figure 9 assume the default of "c=a". o Figure 10 shows the example of a GET request to retrieve a
specific DOTS mitigation request signaled by a DOTS client. The
configuration data to be reported in the response is formatted in
the same order it was processed at the DOTS server.
1) To retrieve all DOTS signals signaled by the DOTS client. These two examples assume the default of "c=a"; that is the DOTS
client asks for all data to be reported by the DOTS server.
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Host: "host" Uri-Host: "host"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "version" Uri-Path: "version"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Observe : 0 Observe : 0
{ {
"mitigation-scope": { "mitigation-scope": {
"client-identifier": [ "client-identifier": [
"string" "string"
] ]
} }
} }
2) To retrieve a specific DOTS signal signaled by the DOTS client. Figure 9: GET to retrieve all DOTS mitigation requests
The configuration data in the response will be formatted in the
same order it was processed at the DOTS server.
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Host: "host" Uri-Host: "host"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "version" Uri-Path: "version"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Observe : 0 Observe : 0
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
skipping to change at page 20, line 47 skipping to change at page 20, line 43
"string" "string"
], ],
"scope": [ "scope": [
{ {
"mitigation-id": integer "mitigation-id": integer
} }
] ]
} }
} }
Figure 9: GET to retrieve the rules Figure 10: GET to retrieve a specific DOTS mitigation request
Figure 10 shows a response example of all the active mitigation Figure 11 shows a response example of all active mitigation requests
requests associated with the DOTS client on the DOTS server and the associated with the DOTS client on the DOTS server and the mitigation
mitigation status of each mitigation request. status of each mitigation request.
{ {
"mitigation-scope": { "mitigation-scope": {
"scope": [ "scope": [
{ {
"mitigation-id": 12332, "mitigation-id": 12332,
"mitigation-start": 1507818434.00, "mitigation-start": 1507818434.00,
"target-protocol": [ "target-protocol": [
17 17
], ],
skipping to change at page 21, line 38 skipping to change at page 21, line 38
"status":3 "status":3
"bytes-dropped": 0, "bytes-dropped": 0,
"bps-dropped": 0, "bps-dropped": 0,
"pkts-dropped": 0, "pkts-dropped": 0,
"pps-dropped": 0 "pps-dropped": 0
} }
] ]
} }
} }
Figure 10: Response body Figure 11: Response body
The mitigation status parameters are described below: The mitigation status parameters are described below:
mitigation-start: Mitigation start time is represented in seconds mitigation-start: Mitigation start time is represented in seconds
relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of
[RFC7049]). The encoding is modified so that the leading tag 1 [RFC7049]). The encoding is modified so that the leading tag 1
(epoch-based date/time) MUST be omitted. (epoch-based date/time) MUST be omitted.
lifetime: The remaining lifetime of the mitigation request in lifetime: The remaining lifetime of the mitigation request, in
seconds. seconds.
status: Status of attack mitigation. The 'status' parameter is a status: Status of attack mitigation. The 'status' parameter is a
mandatory attribute. The various possible values of 'status' mandatory attribute. The various possible values of 'status'
parameter are explained in Table 2. parameter are explained in Table 2.
conflict-information: Indicates that a mitigation request is conflict-information: Indicates that a mitigation request is
conflicting with another mitigation request(s) from other DOTS conflicting with another mitigation request(s) from other DOTS
client(s). This optional attribute has the following structure: client(s). This optional attribute has the following structure:
conflict-status: Indicates the status of a conflicting mitigation conflict-status: Indicates the status of a conflicting mitigation
request. The following values are defined: request. The following values are defined:
1: DOTS Server has detected conflicting mitigation requests 1: DOTS server has detected conflicting mitigation requests
from different DOTS clients. This mitigation request is from different DOTS clients. This mitigation request is
currently inactive until the conflicts are resolved. currently inactive until the conflicts are resolved.
Another mitigation request is active. Another mitigation request is active.
2: DOTS Server has detected conflicting mitigation requests 2: DOTS server has detected conflicting mitigation requests
from different DOTS clients. This mitigation request is from different DOTS clients. This mitigation request is
currently active. currently active.
3: DOTS Server has detected conflicting mitigation requests 3: DOTS server has detected conflicting mitigation requests
from different DOTS clients. All conflicting mitigation from different DOTS clients. All conflicting mitigation
requests are inactive. requests are inactive.
conflict-cause: Indicates the cause of the conflict. The conflict-cause: Indicates the cause of the conflict. The
following values are defined: following values are defined:
1: Overlapping target prefixes 1: Overlapping targets. 'conflict-scope' provides more details
about the conflicting target clauses.
2: Conflicts with an existing white list 2: 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.
conflict-scope Indicates the conflict scope. It may include a
list of IP addresses, a list of prefixes, a list of port
numbers, a list of target protocols, a list of FQDNs, a list of
URIs, or a list of alias-names.
retry-timer Indicates, in seconds, the time upon which the DOTS retry-timer Indicates, in seconds, the time upon which the DOTS
client may re-issue the same request. Any retransmission of client may re-issue the same request. The DOTS server returns
the same mitigation request before the expiry of this timer 'retry-timer' only to DOTS client(s) for which a mitigation
will be discarded by the DOTS server. request is deactivated. Any retransmission of the same
mitigation request before the expiry of this timer is likely to
be rejected by the DOTS server for the same reasons.
The retry-timer SHOULD be equal to the lifetime of the active
mitigation request resulting in the deactivation of the
conflicting mitigation request. The lifetime of the
deactivated mitigation request will be updated to (retry-timer
+ 45 seconds), so the DOTS client can refresh the deactivated
mitigation request after retry-timer seconds before expiry of
lifetime and check if the conflict is resolved.
bytes-dropped: The total dropped byte count for the mitigation bytes-dropped: The total dropped byte count for the mitigation
request since the attack mitigation is triggered. The count wraps request since the attack mitigation is triggered. The count wraps
around when it reaches the maximum value of unsigned integer. around when it reaches the maximum value of unsigned integer.
This is an optional attribute. This is an optional attribute.
bps-dropped: The average dropped bytes per second for the mitigation bps-dropped: The average dropped bytes per second for the mitigation
request since the attack mitigation is triggered. This SHOULD be request since the attack mitigation is triggered. This SHOULD be
a five-minute average. This is an optional attribute. a five-minute average. This is an optional attribute.
skipping to change at page 24, line 7 skipping to change at page 25, line 7
packet loss during a DDoS attack, DOTS server periodically sends packet loss during a DDoS attack, DOTS server periodically sends
attack mitigation status to the DOTS client and also notifies the attack mitigation status to the DOTS client and also notifies the
DOTS client whenever the status of the attack mitigation changes. If DOTS client whenever the status of the attack mitigation changes. If
the DOTS server cannot maintain a RTT estimate, it SHOULD NOT send the DOTS server cannot maintain a RTT estimate, it SHOULD NOT send
more than one unsolicited notification every 3 seconds, and SHOULD more than one unsolicited notification every 3 seconds, and SHOULD
use an even less aggressive rate when possible (case 2 in use an even less aggressive rate when possible (case 2 in
Section 3.1.3 of [RFC8085]). Section 3.1.3 of [RFC8085]).
When conflicting requests are detected, the DOTS server enforces the When conflicting requests are detected, the DOTS server enforces the
corresponding policy (e.g. accept all requests, reject all requests, corresponding policy (e.g. accept all requests, reject all requests,
accept only one request but reject all the other, ...). It is accept only one request but reject all the others, ...). It is
assumed that this policy is supplied by the DOTS server administrator assumed that this policy is supplied by the DOTS server administrator
or it is a default behavior of the DOTS server implementation. Then, or it is a default behavior of the DOTS server implementation. Then,
the DOTS server sends notification message(s) to the DOTS client(s) the DOTS server sends notification message(s) to the DOTS client(s)
at the origin of the conflict. A conflict notification message at the origin of the conflict. A conflict notification message
includes information about the conflict cause and the status of the includes information about the conflict cause, scope, and the status
mitigation request(s). For example, of the mitigation request(s). For example,
o A notification message with status code set to '8 (Attack o A notification message with status code set to '8 (Attack
mitigation is rejected)' is sent to a DOTS client to indicate that mitigation is rejected)' and 'conflict-status' set to '1' is sent
this mitigation request is rejected because a conflict is to a DOTS client to indicate that this mitigation request is
detected. rejected because a conflict is detected.
o A notification message with status code set to '7 (Attack o A notification message with status code set to '7 (Attack
mitigation is withdrawn)' is sent to a DOTS client to indicate mitigation is withdrawn)' and 'conflict-status' set to '1' is sent
that an active mitigation request is deactivated because a to a DOTS client to indicate that an active mitigation request is
conflict is detected. deactivated because a conflict is detected.
o A notification message with status code set to '1 (Attack o A notification message with status code set to '1 (Attack
mitigation is in progress)' and 'conflict-status' set to 2 is sent mitigation is in progress)' and 'conflict-status' set to 2 is sent
to a DOTS client to indicate that this mitigation request is in to a DOTS client to indicate that this mitigation request is in
progress, but a conflict is detected. progress, but a conflict is detected.
Upon receipt of a conflict notification message indicating that a Upon receipt of a conflict notification message indicating that a
mitigation request is deactivated because of a conflict, a DOTS mitigation request is deactivated because of a conflict, a DOTS
client MUST NOT resend the same mitigation request before the expiry client MUST NOT resend the same mitigation request before the expiry
of 'retry-timer'. It is also recommended that DOTS clients support of 'retry-timer'. It is also recommended that DOTS clients support
skipping to change at page 24, line 46 skipping to change at page 25, line 46
A DOTS client that is no longer interested in receiving notifications A DOTS client that is no longer interested in receiving notifications
from the DOTS server can simply "forget" the observation. When the from the DOTS server can simply "forget" the observation. When the
DOTS server then sends the next notification, the DOTS client will DOTS server then sends the next notification, the DOTS client will
not recognize the token in the message and thus will return a Reset not recognize the token in the message and thus will return a Reset
message. This causes the DOTS server to remove the associated entry. message. This causes the DOTS server to remove the associated entry.
Alternatively, the DOTS client can explicitly deregister by issuing a Alternatively, the DOTS client can explicitly deregister by issuing a
GET request that has the Token field set to the token of the GET request that has the Token field set to the token of the
observation to be cancelled and includes an Observe Option with the observation to be cancelled and includes an Observe Option with the
value set to '1' (deregister). value set to '1' (deregister).
Figure 11 shows an example of a DOTS client requesting a DOTS server Figure 12 shows an example of a DOTS client requesting a DOTS server
to send notifications related a given mitigation request. to send notifications related a given mitigation request.
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 |
skipping to change at page 25, line 31 skipping to change at page 26, line 31
| status: "mitigation | | status: "mitigation |
| complete" | | complete" |
|<------------------------------+ |<------------------------------+
| 2.05 Content | | 2.05 Content |
| Token: 0x4a | Notification upon | Token: 0x4a | Notification upon
| Observe: 60 | a state change | Observe: 60 | a state change
| status: "attack stopped" | | status: "attack stopped" |
|<------------------------------+ |<------------------------------+
| | | |
Figure 11: Notifications of attack mitigation status Figure 12: Notifications of attack mitigation status
4.4.3.1. Mitigation Status 4.4.2.1. Mitigation Status
The DOTS client can send the GET request at frequent intervals The DOTS client can send the GET request at frequent intervals
without the Observe option to retrieve the configuration data of the without the Observe option to retrieve the configuration data of the
mitigation request and non-configuration data (i.e., the attack mitigation request and non-configuration data (i.e., the attack
status). The frequency of polling the DOTS server to get the status). The frequency of polling the DOTS server to get the
mitigation status should follow the transmission guidelines given in mitigation status should follow the transmission guidelines given in
Section 3.1.3 of [RFC8085]. If the DOTS server has been able to Section 3.1.3 of [RFC8085]. If the DOTS server has been able to
mitigate the attack and the attack has stopped, the DOTS server mitigate the attack and the attack has stopped, the DOTS server
indicates as such in the status, and the DOTS client recalls the indicates as such in the status, and the DOTS client recalls the
mitigation request by issuing a DELETE for the mitigation-id. mitigation request by issuing a DELETE request for the mitigation-id.
A DOTS client should react to the status of the attack from the DOTS A DOTS client SHOULD react to the status of the attack from the DOTS
server and not the fact that it has recognized, using its own means, server and not the fact that it has recognized, using its own means,
that the attack has been mitigated. This ensures that the DOTS that the attack has been mitigated. This ensures that the DOTS
client does not recall a mitigation request in a premature fashion client does not recall a mitigation request in a premature fashion
because it is possible that the DOTS client does not sense the DDOS because it is possible that the DOTS client does not sense the DDOS
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.
4.4.4. Efficacy Update from DOTS Clients 4.4.3. Efficacy Update from DOTS Clients
While DDoS mitigation is active, due to the likelihood of packet While DDoS mitigation is active, due to the likelihood of packet
loss, a DOTS client MAY periodically transmit DOTS mitigation loss, a DOTS client MAY periodically transmit DOTS mitigation
efficacy updates to the relevant DOTS server. A PUT request efficacy updates to the relevant DOTS server. A PUT request is used
(Figure 12) is used to convey the mitigation efficacy update to the to convey the mitigation efficacy update to the DOTS server.
DOTS server.
The PUT request MUST include all the parameters used in the PUT The PUT request MUST include all the parameters used in the PUT
request to convey the DOTS signal (Section 4.4.1) unchanged apart request to convey the DOTS signal (Section 4.4.1) unchanged apart
from the lifetime parameter value. If this is not the case, the DOTS from the lifetime parameter value. If this is not the case, the DOTS
server MUST reject the request with a 4.02 error response code. server MUST reject the request with a 4.00 (Bad Request).
The If-Match Option (Section 5.10.8.1 of [RFC7252]) with an empty 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 value is used to make the PUT request conditional on the current
existence of the mitigation request. If UDP is used as transport, existence of the mitigation request. If UDP is used as transport,
CoAP requests may arrive out-of-order. For example, the DOTS client CoAP requests may arrive out-of-order. For example, the DOTS client
may send a PUT request to convey an efficacy update to the DOTS may send a PUT request to convey an efficacy update to the DOTS
server followed by a DELETE request to withdraw the mitigation server followed by a DELETE request to withdraw the mitigation
request, but the DELETE request arrives at the DOTS server before the request, but the DELETE request arrives at the DOTS server before the
PUT request. To handle out-of-order delivery of requests, if an If- PUT request. To handle out-of-order delivery of requests, if an If-
Match option is present in the PUT request and the 'mitigation-id' in Match option is present in the PUT request and the 'mitigation-id' in
the request matches a mitigation request from that DOTS client, then the request matches a mitigation request from that DOTS client, then
the request is processed. If no match is found, the PUT request is the request is processed. If no match is found, the PUT request is
silently ignored. silently ignored.
An example of an efficacy update message, which includes an If-Match
option with an empty value, is depicted in Figure 13.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Host: "host" Uri-Host: "host"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "version" Uri-Path: "version"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Content-Format: "application/cbor" Content-Format: "application/cbor"
If-Match: If-Match:
{ {
"mitigation-scope": { "mitigation-scope": {
skipping to change at page 27, line 49 skipping to change at page 28, line 49
"alias-name": [ "alias-name": [
"string" "string"
], ],
"lifetime": integer, "lifetime": integer,
"attack-status": integer "attack-status": integer
} }
] ]
} }
} }
Figure 12: Efficacy Update Figure 13: Efficacy Update
The 'attack-status' parameter is a mandatory attribute when doing a The 'attack-status' parameter is a mandatory attribute when doing an
efficacy update. The various possible values contained in the efficacy update. The various possible values contained in the
'attack-status' parameter are described in Table 3. 'attack-status' parameter are described in Table 3.
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Parameter | Description | | Parameter | Description |
| value | | | value | |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 1 | The DOTS client determines that it is still under | | 1 | The DOTS client determines that it is still under |
| | attack. | | | attack. |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
skipping to change at page 28, line 30 skipping to change at page 29, line 30
Table 3: Values of 'attack-status' parameter Table 3: Values of 'attack-status' parameter
The DOTS server indicates the result of processing a PUT request The DOTS server indicates the result of processing a PUT request
using CoAP response codes. The response code 2.04 (Changed) is using CoAP response codes. The response code 2.04 (Changed) is
returned if the DOTS server has accepted the mitigation efficacy returned if the DOTS server has accepted the mitigation efficacy
update. The error response code 5.03 (Service Unavailable) is update. The error response code 5.03 (Service Unavailable) is
returned if the DOTS server has erred or is incapable of performing returned if the DOTS server has erred or is incapable of performing
the mitigation. the mitigation.
4.4.4. Withdraw a Mitigation
A DELETE request is used to withdraw a DOTS mitigation request from a
DOTS server (Figure 14).
Header: DELETE (Code=0.04)
Uri-Host: "host"
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "version"
Uri-Path: "mitigate"
Content-Format: "application/cbor"
{
"mitigation-scope": {
"client-identifier": [
"string"
],
"scope": [
{
"mitigation-id": integer
}
]
}
}
Figure 14: Withdraw DOTS signal
If the request does not include a 'mitigation-id', the DOTS server
MUST reply with a 4.00 (Bad Request).
Once the request is validated, the DOTS server immediately
acknowledges a DOTS client's request to withdraw the DOTS signal
using 2.02 (Deleted) response code with no response payload. A 2.02
(Deleted) Response Code is returned even if the 'mitigation-id'
parameter value conveyed in the DELETE request does not exist in its
configuration data before the request.
If the DOTS server finds the 'mitigation-id' parameter value conveyed
in the DELETE request in its configuration data, then to protect
against route or DNS flapping caused by a DOTS client rapidly
toggling mitigation, and to dampen the effect of oscillating attacks,
the DOTS server MAY allow mitigation to continue for a limited period
after acknowledging a DOTS client's withdrawal of a mitigation
request. During this period, the DOTS server status messages SHOULD
indicate that mitigation is active but terminating (Section 4.4.2).
The initial active-but-terminating period SHOULD be sufficiently long
to absorb latency incurred by route propagation. The active-but-
terminating period SHOULD be set by default to 120 seconds. If the
client requests mitigation again before the initial active-but-
terminating period elapses, the DOTS server MAY exponentially
increase the active-but- terminating period up to a maximum of 300
seconds (5 minutes).
After the active-but-terminating period elapses, the DOTS 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.
4.5. DOTS Signal Channel Session Configuration 4.5. DOTS Signal Channel Session Configuration
The DOTS client can negotiate, configure, and retrieve the DOTS The DOTS client can negotiate, configure, and retrieve the DOTS
signal channel session behavior. The DOTS signal channel can be signal channel session behavior. The DOTS signal channel can be
used, for example, to configure the following: used, for example, to configure the following:
a. Heartbeat interval: DOTS agents regularly send heartbeats (CoAP a. Heartbeat interval: DOTS agents regularly send heartbeats (CoAP
Ping/Pong) to each other after mutual authentication in order to Ping/Pong) to each other after mutual authentication in order to
keep the DOTS signal channel open, heartbeat messages are keep the DOTS signal channel open, heartbeat messages are
exchanged between the DOTS agents every heartbeat-interval exchanged between the DOTS agents every heartbeat-interval
skipping to change at page 29, line 7 skipping to change at page 31, line 35
number of consecutive heartbeat messages for which a DOTS agent number of consecutive heartbeat messages for which a DOTS agent
did not receive a response before concluding that the session is did not receive a response before concluding that the session is
disconnected or defunct. disconnected or defunct.
c. Acceptable signal loss ratio: Maximum retransmissions, c. Acceptable signal loss ratio: Maximum retransmissions,
retransmission timeout value and other message transmission retransmission timeout value and other message transmission
parameters for the DOTS signal channel. parameters for the DOTS signal channel.
Reliability is provided to requests and responses by marking them as Reliability is provided to requests and responses by marking them as
Confirmable (CON) messages. DOTS signal channel session Confirmable (CON) messages. DOTS signal channel session
configuration requests and responses are marked as Confirmable (CON) configuration requests and responses are marked as Confirmable
messages. As explained in Section 2.1 of [RFC7252], a Confirmable messages. As explained in Section 2.1 of [RFC7252], a Confirmable
message is retransmitted using a default timeout and exponential message is retransmitted using a default timeout and exponential
back-off between retransmissions, until the DOTS server sends an back-off between retransmissions, until the DOTS server sends an
Acknowledgement message (ACK) with the same Message ID conveyed from Acknowledgement message (ACK) with the same Message ID conveyed from
the DOTS client. Message transmission parameters are defined in the DOTS client. Message transmission parameters are defined in
Section 4.8 of [RFC7252]. Reliability is provided to the responses Section 4.8 of [RFC7252]. The DOTS server can either piggyback the
by marking them as Confirmable (CON) messages. The DOTS server can response in the acknowledgement message or if the DOTS server is not
either piggyback the response in the acknowledgement message or if able to respond immediately to a request carried in a Confirmable
the DOTS server is not able to respond immediately to a request message, it simply responds with an Empty Acknowledgement message so
carried in a Confirmable message, it simply responds with an Empty that the DOTS client can stop retransmitting the request. Empty
Acknowledgement message so that the DOTS client can stop Acknowledgement message is explained in Section 2.2 of [RFC7252].
retransmitting the request. Empty Acknowledgement message is When the response is ready, the server sends it in a new Confirmable
explained in Section 2.2 of [RFC7252]. When the response is ready, message which then in turn needs to be acknowledged by the DOTS
the server sends it in a new Confirmable message which then in turn client (see Sections 5.2.1 and 5.2.2 of [RFC7252]). Requests and
needs to be acknowledged by the DOTS client (see Sections 5.2.1 and responses exchanged between DOTS agents during peacetime are marked
5.2.2 of [RFC7252]). Requests and responses exchanged between DOTS as Confirmable messages.
agents during peacetime are marked as Confirmable messages.
Implementation Note: A DOTS client that receives a response in a CON Implementation Note: A DOTS client that receives a response in a
message may want to clean up the message state right after sending CON message may want to clean up the message state right after
the ACK. If that ACK is lost and the DOTS server retransmits the sending the ACK. If that ACK is lost and the DOTS server
CON, the DOTS client may no longer have any state to which to retransmits the CON, the DOTS client may no longer have any state
correlate this response, making the retransmission an unexpected to which to correlate this response, making the retransmission an
message; the DOTS client will send a Reset message so it does not unexpected message; the DOTS client will send a Reset message so
receive any more retransmissions. This behavior is normal and not an it does not receive any more retransmissions. This behavior is
indication of an error (see Section 5.3.2 of [RFC7252] for more normal and not an indication of an error (see Section 5.3.2 of
details). [RFC7252] for more details).
4.5.1. Discover Configuration Parameters 4.5.1. Discover Configuration Parameters
A GET request is used to obtain acceptable and current configuration A GET request is used to obtain acceptable and current configuration
parameters on the DOTS server for DOTS signal channel session parameters on the DOTS server for DOTS signal channel session
configuration. Figure 13 shows how to obtain acceptable configuration. Figure 15 shows how to obtain acceptable
configuration parameters for the DOTS server. configuration parameters for the DOTS server.
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Host: "host" Uri-Host: "host"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "version" Uri-Path: "version"
Uri-Path: "config" Uri-Path: "config"
Figure 13: GET to retrieve configuration Figure 15: GET to retrieve configuration
The DOTS server in the 2.05 (Content) response conveys the current, The DOTS server in the 2.05 (Content) response conveys the current,
minimum and maximum attribute values acceptable by the DOTS server. minimum and maximum attribute values acceptable by the DOTS server.
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"heartbeat-interval": { "heartbeat-interval": {
"CurrentValue": integer, "CurrentValue": integer,
"MinValue": integer, "MinValue": integer,
"MaxValue" : integer, "MaxValue" : integer,
skipping to change at page 30, line 40 skipping to change at page 33, line 37
"ack-random-factor": { "ack-random-factor": {
"CurrentValue": number, "CurrentValue": number,
"MinValue": number, "MinValue": number,
"MaxValue" : number, "MaxValue" : number,
}, },
"trigger-mitigation": { "trigger-mitigation": {
"CurrentValue": boolean, "CurrentValue": boolean,
} }
} }
Figure 14: GET response body Figure 16: GET response body
Figure 15 shows an example of acceptable and current configuration Figure 17 shows an example of acceptable and current configuration
parameters on the DOTS server for DOTS signal channel session parameters on the DOTS server for DOTS signal channel session
configuration. configuration.
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"heartbeat-interval": { "heartbeat-interval": {
"CurrentValue": 30, "CurrentValue": 30,
"MinValue": 15, "MinValue": 15,
"MaxValue" : 240, "MaxValue" : 240,
}, },
skipping to change at page 31, line 37 skipping to change at page 34, line 37
"ack-random-factor": { "ack-random-factor": {
"CurrentValue": 1.5, "CurrentValue": 1.5,
"MinValue": 1.1, "MinValue": 1.1,
"MaxValue" : 4.0, "MaxValue" : 4.0,
}, },
"trigger-mitigation": { "trigger-mitigation": {
"CurrentValue": true, "CurrentValue": true,
} }
} }
Figure 15: Configuration response body Figure 17: Configuration response body
4.5.2. Convey DOTS Signal Channel Session Configuration 4.5.2. Convey DOTS Signal Channel Session Configuration
A PUT request is used to convey the configuration parameters for the A PUT request is used to convey the configuration parameters for the
signal channel (e.g., heartbeat interval, maximum retransmissions). signal channel (e.g., heartbeat interval, maximum retransmissions).
Message transmission parameters for CoAP are defined in Section 4.8 Message transmission parameters for CoAP are defined in Section 4.8
of [RFC7252]. The RECOMMENDED values of transmission parameter of [RFC7252]. The RECOMMENDED values of transmission parameter
values are ack_timeout (2 seconds), max-retransmit (3), ack-random- values are ack_timeout (2 seconds), max-retransmit (3), ack-random-
factor (1.5). In addition to those parameters, the RECOMMENDED factor (1.5). In addition to those parameters, the RECOMMENDED
specific DOTS transmission parameter values are heartbeat-interval specific DOTS transmission parameter values are heartbeat-interval
skipping to change at page 32, line 20 skipping to change at page 35, line 20
standpoint, this specification recommends a minimum heartbeat- standpoint, this specification recommends a minimum heartbeat-
interval of 15 seconds and a maximum heartbeat-interval of 240 interval of 15 seconds and a maximum heartbeat-interval of 240
seconds. The recommended value of 30 seconds is selected to seconds. The recommended value of 30 seconds is selected to
anticipate the expiry of NAT state. anticipate the expiry of NAT state.
A heartbeat-interval of 30 second may be seen as too chatty in A heartbeat-interval of 30 second may be seen as too chatty in
some deployments. For such deployments, DOTS agents may negotiate some deployments. For such deployments, DOTS agents may negotiate
longer heartbeat-interval values to avoid overloading the network longer heartbeat-interval values to avoid overloading the network
with too frequent keepalives. with too frequent keepalives.
When a confirmable "CoAP ping" is sent, and if there is no response, When a confirmable "CoAP Ping" is sent, and if there is no response,
the "CoAP ping" will get retransmitted max-retransmit number of times the "CoAP Ping" is retransmitted max-retransmit number of times by
by the CoAP layer using an initial timeout set to a random duration the CoAP layer using an initial timeout set to a random duration
between ack_timeout and (ack-timeout*ack-random-factor) and between ack_timeout and (ack-timeout*ack-random-factor) and
exponential back-off between retransmissions. By choosing the exponential back-off between retransmissions. By choosing the
recommended transmission parameters, the "CoAP ping" will timeout recommended transmission parameters, the "CoAP Ping" will timeout
after 45 seconds. If the DOTS agent does not receive any response after 45 seconds. If the DOTS agent does not receive any response
from the peer DOTS agent for missing-hb-allowed number of consecutive from the peer DOTS agent for missing-hb-allowed number of consecutive
"CoAP ping" confirmable messages, then it concludes that the DOTS "CoAP Ping" confirmable messages, it concludes that the DOTS signal
signal channel session is disconnected. A DOTS client MUST NOT channel session is disconnected. A DOTS client MUST NOT transmit a
transmit a "CoAP ping" while waiting for the previous "CoAP ping" "CoAP Ping" while waiting for the previous "CoAP Ping" response from
response from the same DOTS server. the same DOTS server.
If the DOTS agent wishes to change the default values of message If the DOTS agent wishes to change the default values of message
transmission parameters, then it should follow the guidance given in transmission parameters, then it should follow the guidance given in
Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the negotiated Section 4.8.1 of [RFC7252]. The DOTS agents MUST use the negotiated
values for message transmission parameters and default values for values for message transmission parameters and default values for
non-negotiated message transmission parameters. non-negotiated message transmission parameters.
The signal channel session configuration is applicable to a single The signal channel session configuration is applicable to a single
DOTS signal channel session between the DOTS agents. DOTS signal channel session between the DOTS agents.
skipping to change at page 33, line 24 skipping to change at page 36, line 24
"session-id": integer, "session-id": integer,
"heartbeat-interval": integer, "heartbeat-interval": integer,
"missing-hb-allowed": integer, "missing-hb-allowed": integer,
"max-retransmit": integer, "max-retransmit": integer,
"ack-timeout": integer, "ack-timeout": integer,
"ack-random-factor": number "ack-random-factor": number
"trigger-mitigation": boolean "trigger-mitigation": boolean
} }
} }
Figure 16: PUT to convey the DOTS signal channel session Figure 18: 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.
mandatory attribute.
This is a mandatory attribute.
heartbeat-interval: Time interval in seconds between two heartbeat-interval: Time interval in seconds between two
consecutive heartbeat messages. This is an optional attribute. consecutive heartbeat messages.
This is an optional attribute.
missing-hb-allowed: Maximum number of consecutive heartbeat missing-hb-allowed: Maximum number of consecutive heartbeat
messages for which the DOTS agent did not receive a response messages for which the DOTS agent did not receive a response
before concluding that the session is disconnected. This is an before concluding that the session is disconnected.
optional attribute.
This is an optional attribute.
max-retransmit: Maximum number of retransmissions for a message max-retransmit: Maximum number of retransmissions for a message
(referred to as MAX_RETRANSMIT parameter in CoAP). This is an (referred to as MAX_RETRANSMIT parameter in CoAP).
optional attribute.
This is an 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.
trigger-mitigation: If the parameter value is set to 'false', then trigger-mitigation: If the parameter value is set to 'false', then
DDoS mitigation is triggered only when the DOTS signal channel DDoS mitigation is triggered only when the DOTS signal channel
session is lost. Automated mitigation on loss of signal is session is lost. Automated mitigation on loss of signal is
discussed in Section 3.3.3 of [I-D.ietf-dots-architecture]. If discussed in Section 3.3.3 of [I-D.ietf-dots-architecture].
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.
In the PUT request at least one of the attributes heartbeat-interval, If the DOTS client ceases to respond to heartbeat messages, the
missing-hb-allowed, max-retransmit, ack-timeout, ack-random-factor, DOTS server can detect that the DOTS session is lost.
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 17 shows a PUT request example to convey the configuration The default value of the parameter is 'true'.
This is an optional attribute.
In the PUT request at least one of the attributes 'heartbeat-
interval', 'missing-hb-allowed', '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 19 shows a PUT request example to convey the configuration
parameters for the DOTS signal channel. parameters for the DOTS signal channel.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Host: "www.example.com" Uri-Host: "www.example.com"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1" Uri-Path: "v1"
Uri-Path: "config" Uri-Path: "config"
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
skipping to change at page 34, line 46 skipping to change at page 38, line 24
"session-id": 1234534333242, "session-id": 1234534333242,
"heartbeat-interval": 91, "heartbeat-interval": 91,
"missing-hb-allowed": 3, "missing-hb-allowed": 3,
"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 "trigger-mitigation": false
} }
} }
Figure 17: PUT to convey the configuration parameters Figure 19: PUT to convey the configuration parameters
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: using CoAP response codes:
o If the DOTS server finds the 'session-id' parameter value conveyed o If the DOTS server finds the 'session-id' parameter value conveyed
in the PUT request in its configuration data and if the DOTS in the PUT request in its configuration data and if the DOTS
server has accepted the updated configuration parameters, then server has accepted the updated configuration parameters, then
2.04 (Changed) code is returned in the response. 2.04 (Changed) code is returned in the response.
o If the DOTS server does not find the 'session-id' parameter value o If the DOTS server does not find the 'session-id' parameter value
conveyed in the PUT request in its configuration data and if the conveyed in the PUT request in its configuration data and if the
DOTS server has accepted the configuration parameters, then a DOTS server has accepted the configuration parameters, then a
response code 2.01 (Created) is returned in the response. response code 2.01 (Created) is returned in the response.
o If the request is missing one or more mandatory attributes, then o If the request is missing one or more mandatory attributes or it
4.00 (Bad Request) is returned in the response. contains one or more invalid or unknown parameters, then 4.00 (Bad
Request) is returned in the response.
o If the request contains one or more invalid or unknown parameters,
then 4.02 (Invalid query) code is returned in the response.
o Response code 4.22 (Unprocessable Entity) is returned in the o Response code 4.22 (Unprocessable Entity) is returned in the
response, if any of the heartbeat-interval, missing-hb-allowed, response, if any of the heartbeat-interval, missing-hb-allowed,
max-retransmit, target-protocol, ack-timeout, and ack-random- max-retransmit, target-protocol, ack-timeout, and ack-random-
factor attribute values are not acceptable to the DOTS server. factor attribute values are not acceptable to the DOTS server.
Upon receipt of the 4.22 error response code, the DOTS client Upon receipt of the 4.22 error response code, the DOTS client
should request the maximum and minimum attribute values acceptable should request the maximum and minimum attribute values acceptable
to the DOTS server (Section 4.5.1). The DOTS client may re-try to the DOTS server (Section 4.5.1). The DOTS client may re-try
and send the PUT request with updated attribute values acceptable and send the PUT request with updated attribute values acceptable
to the DOTS server. to the DOTS server.
4.5.3. Delete DOTS Signal Channel Session Configuration 4.5.3. Delete DOTS Signal Channel Session Configuration
A DELETE request is used to delete the installed DOTS signal channel A DELETE request is used to delete the installed DOTS signal channel
session configuration data (Figure 18). session configuration data (Figure 20).
Header: DELETE (Code=0.04) Header: DELETE (Code=0.04)
Uri-Host: "host" Uri-Host: "host"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "version" Uri-Path: "version"
Uri-Path: "config" Uri-Path: "config"
Content-Format: "application/cbor" Content-Format: "application/cbor"
Figure 18: DELETE configuration Figure 20: DELETE configuration
The DOTS server resets the DOTS signal channel session configuration The DOTS server resets the DOTS signal channel session configuration
back to the default values and acknowledges a DOTS client's request back to the default values and acknowledges a DOTS client's request
to remove the DOTS signal channel session configuration using 2.02 to remove the DOTS signal channel session configuration using 2.02
(Deleted) response code. (Deleted) response code.
4.6. Redirected Signaling 4.6. Redirected Signaling
Redirected DOTS signaling is discussed in detail in Section 3.2.2 of Redirected DOTS signaling is discussed in detail in Section 3.2.2 of
[I-D.ietf-dots-architecture]. [I-D.ietf-dots-architecture].
skipping to change at page 36, line 13 skipping to change at page 39, line 33
(Deleted) response code. (Deleted) response code.
4.6. Redirected Signaling 4.6. Redirected Signaling
Redirected DOTS signaling is discussed in detail in Section 3.2.2 of Redirected DOTS signaling is discussed in detail in Section 3.2.2 of
[I-D.ietf-dots-architecture]. [I-D.ietf-dots-architecture].
If a DOTS server wants to redirect a DOTS client to an alternative If a DOTS server wants to redirect a DOTS client to an alternative
DOTS server for a signal session, then the response code 3.00 DOTS server for a signal session, then the response code 3.00
(alternate server) will be returned in the response to the client. (alternate server) will be returned in the response to the client.
The DOTS server can return the error response code 3.00 in response The DOTS server can return the error response code 3.00 in response
to a PUT request from the DOTS client or convey the error response to a PUT request from the DOTS client or convey the error response
code 3.00 in a unidirectional notification response from the DOTS code 3.00 in a unidirectional notification response from the DOTS
server. 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's FQDN, and the alternate DOTS server IP address(es) and time
live values in the CBOR body. to 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 21: Error response body
The parameters are described below: The parameters are described below:
alt-server: FQDN of an alternate DOTS server. alt-server: FQDN of an alternate DOTS server.
addr: IP address of an 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 22 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 'alt-server.example', 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": "alt-server.example",
"alt-server": "www.example-alt.com",
"alt-server-record": [ "alt-server-record": [
{ {
"ttl" : 3600, "ttl" : 3600,
"addr": "2001:db8:6401::1" "addr": "2001:db8:6401::1"
}, },
{ {
"ttl" : 1800, "ttl" : 1800,
"addr": "2001:db8:6401::2" "addr": "2001:db8:6401::2"
} }
] ]
} }
Figure 20: Example of error response body Figure 22: Example of error response body
When the DOTS client receives 3.00 response, it considers the current When the DOTS client receives 3.00 response, it considers the current
request as having failed, but SHOULD try the request with the request as having failed, but SHOULD try the request with the
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.
skipping to change at page 38, line 8 skipping to change at page 41, line 31
to the DOTS server. to the DOTS server.
In case of a volumetric DDoS attack saturating the incoming link to In case of a volumetric DDoS attack saturating the incoming link to
the DOTS client, all traffic from the DOTS server to the DOTS client the DOTS client, all traffic from the DOTS server to the DOTS client
will likely be dropped, although the DOTS server receives heartbeat will likely be dropped, although the DOTS server receives heartbeat
requests and DOTS messages from the DOTS client. In this scenario, requests and DOTS messages from the DOTS client. In this scenario,
the DOTS agents MUST behave differently to handle message the DOTS agents MUST behave differently to handle message
transmission and DOTS session liveliness during link saturation: transmission and DOTS session liveliness during link saturation:
o The DOTS client MUST NOT consider the DOTS session terminated even o The DOTS client MUST NOT consider the DOTS session terminated even
after maximum "missing-hb-allowed" threshold is reached. The DOTS after maximum 'missing-hb-allowed' threshold is reached. The DOTS
client SHOULD continue to use the current DOTS session, and send client SHOULD continue to use the current DOTS session, and send
heartbeat requests over the current DOTS session, so the DOTS heartbeat requests over the current DOTS session, so the DOTS
server knows the DOTS client has not disconnected the DOTS server knows the DOTS client has not disconnected the DOTS
session. After the maximum "missing-hb-allowed" threshold is session.
reached, the DOTS client SHOULD try (D)TLS session resumption.
The DOTS client SHOULD send mitigation requests over the current After the maximum 'missing-hb-allowed' threshold is reached, the
DOTS session, and in parallel, try (D)TLS session resumption or DOTS client SHOULD try (D)TLS session resumption. The DOTS client
0-RTT mode in DTLS 1.3 to piggyback the mitigation request in the SHOULD send mitigation requests over the current DOTS session, and
ClientHello message. Once the link is no longer saturated, if in parallel, try (D)TLS session resumption or 0-RTT mode in DTLS
traffic from the DOTS server reaches the DOTS client over the 1.3 to piggyback the mitigation request in the ClientHello
current DOTS session, the DOTS client can stop (D)TLS session message.
resumption or if (D)TLS session resumption is successful then
disconnect the current DOTS session. Once the link is no longer saturated, if traffic from the DOTS
server reaches the DOTS client over the current DOTS session, the
DOTS client can stop (D)TLS session resumption or if (D)TLS
session resumption is successful then disconnect the current DOTS
session.
o If the DOTS server does not receive any traffic from the peer DOTS o If the DOTS server does not receive any traffic from the peer DOTS
client, then the DOTS server sends heartbeat requests to the DOTS client, then the DOTS server sends heartbeat requests to the DOTS
client and after maximum "missing-hb-allowed" threshold is client and after maximum 'missing-hb-allowed' threshold is
reached, the DOTS server concludes the session is disconnected. reached, the DOTS server concludes the session is disconnected.
In DOTS over UDP, heartbeat messages may be exchanged between the In DOTS over UDP, heartbeat messages may be exchanged between the
DOTS agents using the "COAP ping" mechanism defined in Section 4.2 of DOTS agents using the "COAP Ping" mechanism defined in Section 4.2 of
[RFC7252]. Concretely, the DOTS agent sends an Empty Confirmable [RFC7252]. Concretely, the DOTS agent sends an Empty Confirmable
message and the peer DOTS agent will respond by sending an Reset message and the peer DOTS agent will respond by sending an Reset
message. message.
In DOTS over TCP, heartbeat messages can be exchanged between the In DOTS over TCP, heartbeat messages can be exchanged between the
DOTS agents using the Ping and Pong messages specified in Section 4.4 DOTS agents using the Ping and Pong messages specified in Section 4.4
of [I-D.ietf-core-coap-tcp-tls]. That is, the DOTS agent sends a of [I-D.ietf-core-coap-tcp-tls]. That is, the DOTS agent sends a
Ping message and the peer DOTS agent would respond by sending a Ping message and the peer DOTS agent would respond by sending a
single Pong message. single Pong message.
5. DOTS Signal Channel YANG Modules 5. DOTS Signal Channel YANG Module
This document defines YANG [RFC7950] modules for mitigation scope and This document defines a YANG [RFC7950] module for mitigation scope
DOTS signal channel session configuration data. and DOTS signal channel session configuration data.
5.1. Mitigation Request YANG Module Tree Structure 5.1. Tree Structure
This document defines the YANG module "ietf-dots-signal" This document defines the YANG module "ietf-dots-signal"
(Section 5.2), which has the following tree structure: (Section 5.2), which has the following tree structure. A DOTS signal
message can either be a mitigation or a configuration message.
module: ietf-dots-signal module: ietf-dots-signal
+--rw mitigation-scope +--rw dots-signal
+--rw client-identifier* binary +--rw (message-type)?
+--rw scope* [mitigation-id] +--:(mitigation-scope)
+--rw mitigation-id int32 | +--rw client-identifier* binary
+--rw target-ip* inet:ip-address | +--rw scope* [mitigation-id]
+--rw target-prefix* inet:ip-prefix | +--rw mitigation-id int32
+--rw target-port-range* [lower-port upper-port] | +--rw target-ip* inet:ip-address
| +--rw lower-port inet:port-number | +--rw target-prefix* inet:ip-prefix
| +--rw upper-port inet:port-number | +--rw target-port-range* [lower-port upper-port]
+--rw target-protocol* uint8 | | +--rw lower-port inet:port-number
+--rw target-fqdn* inet:domain-name | | +--rw upper-port inet:port-number
+--rw target-uri* inet:uri | +--rw target-protocol* uint8
+--rw alias-name* string | +--rw target-fqdn* inet:domain-name
+--rw lifetime? int32 | +--rw target-uri* inet:uri
+--rw mitigation-start? int64 | +--rw alias-name* string
+--ro status? enumeration | +--rw lifetime? int32
+--ro conflict-information | +--rw mitigation-start? int64
| +--ro conflict-status? enumeration | +--ro status? enumeration
| +--ro conflict-cause? enumeration | +--ro conflict-information
| +--ro retry-timer? int32 | | +--ro conflict-status? enumeration
+--ro pkts-dropped? yang:zero-based-counter64 | | +--ro conflict-cause? enumeration
+--ro bps-dropped? yang:zero-based-counter64 | | +--ro retry-timer? int32
+--ro bytes-dropped? yang:zero-based-counter64 | | +--ro conflict-scope
+--ro pps-dropped? yang:zero-based-counter64 | | +--ro target-ip* inet:ip-address
| | +--ro target-prefix* inet:ip-prefix
| | +--ro target-port-range* [lower-port upper-port]
| | | +--ro lower-port inet:port-number
| | | +--ro upper-port inet:port-number
| | +--ro target-protocol* uint8
| | +--ro target-fqdn* inet:domain-name
| | +--ro target-uri* inet:uri
| | +--ro alias-name* string
| +--ro pkts-dropped? yang:zero-based-counter64
| +--ro bps-dropped? yang:zero-based-counter64
| +--ro bytes-dropped? yang:zero-based-counter64
| +--ro pps-dropped? yang:zero-based-counter64
+--:(configuration)
+--rw session-id int32
+--rw heartbeat-interval? int16
+--rw missing-hb-allowed? int16
+--rw max-retransmit? int16
+--rw ack-timeout? int16
+--rw ack-random-factor? decimal64
+--rw trigger-mitigation? boolean
5.2. Mitigation Request YANG Module 5.2. YANG Module
<CODE BEGINS> file "ietf-dots-signal@2017-12-01.yang" <CODE BEGINS> file "ietf-dots-signal@2017-12-05.yang"
module ietf-dots-signal { module ietf-dots-signal {
yang-version 1.1; yang-version 1.1;
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 {prefix "inet";} import ietf-inet-types {prefix "inet";}
import ietf-yang-types {prefix yang; } import ietf-yang-types {prefix yang; }
organization "IETF DOTS Working Group"; organization "IETF DOTS Working Group";
contact contact
"Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com> "Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>
Mohamed Boucadair <mohamed.boucadair@orange.com> Mohamed Boucadair <mohamed.boucadair@orange.com>
Prashanth Patil <praspati@cisco.com> Prashanth Patil <praspati@cisco.com>
Andrew Mortensen <amortensen@arbor.net> Andrew Mortensen <amortensen@arbor.net>
Nik Teague <nteague@verisign.com>"; Nik Teague <nteague@verisign.com>";
description description
"This module contains YANG definition for DOTS "This module contains YANG definition for the signaling
signal sent by the DOTS client to the DOTS server. messages exchanegd between the DOTS client to the DOTS server.
Copyright (c) 2017 IETF Trust and the persons identified as Copyright (c) 2017 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2017-12-01 { revision 2017-12-05 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Distributed Denial-of-Service Open Threat "RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel"; Signaling (DOTS) Signal Channel";
} }
container mitigation-scope { grouping target {
description description
"Specifies the scope of the mitigation request."; "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 { leaf-list target-ip {
type int32; type inet:ip-address;
description description
"Mitigation request identifier. "IPv4 or IPv6 address identifying the target.";
}
This identifier must be unique for each mitigation leaf-list target-prefix {
request bound to the DOTS client."; type inet:ip-prefix;
} description
"IPv4 or IPv6 prefix identifying the target.";
}
leaf-list target-ip { list target-port-range {
type inet:ip-address; key "lower-port upper-port";
description
"IPv4 or IPv6 address identifying the target.";
}
leaf-list target-prefix { description
type inet:ip-prefix; "Port range. When only lower-port is
description present, it represents a single port.";
"IPv4 or IPv6 prefix identifying the target.";
}
list target-port-range { leaf lower-port {
key "lower-port upper-port"; type inet:port-number;
mandatory true;
description "Lower port number.";
}
description leaf upper-port {
"Port range. When only lower-port is type inet:port-number;
present, it represents a single port."; must ". >= ../lower-port" {
error-message
"The upper port number must be greater than
or equal to lower port number.";
}
description "Upper port number.";
}
}
leaf lower-port { leaf-list target-protocol {
type inet:port-number; type uint8;
mandatory true; description
description "Lower port number."; "Identifies the target protocol number.
}
leaf upper-port { The value '0' means 'all protocols'.
type inet:port-number;
must ". >= ../lower-port" {
error-message
"The upper port number must be greater than
or equal to lower port number.";
}
description "Upper port number.";
}
}
leaf-list target-protocol { Values are taken from the IANA protocol registry:
type uint8; https://www.iana.org/assignments/protocol-numbers/
description protocol-numbers.xhtml
"Identifies the target protocol number. For example, 6 for a TCP or 17 for UDP.";
}
The value '0' means 'all protocols'. leaf-list target-fqdn {
type inet:domain-name;
description "FQDN identifying the target.";
}
Values are taken from the IANA protocol registry: leaf-list target-uri {
https://www.iana.org/assignments/protocol-numbers/ type inet:uri;
protocol-numbers.xhtml description "URI identifying the target.";
}
For example, 6 for a TCP or 17 for UDP."; leaf-list alias-name {
} type string;
description "alias name";
}
}
leaf-list target-fqdn { grouping mitigation-scope {
type inet:domain-name; description
description "FQDN"; "Specifies the scope of the mitigation request.";
}
leaf-list target-uri { leaf-list client-identifier {
type inet:uri; type binary;
description "URI"; 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.
leaf-list alias-name { It allows the final DOTS server to accept
type string; mitigation requests with scopes which the DOTS
description "alias name"; client is authorized to manage.";
} }
leaf lifetime { list scope {
type int32; key mitigation-id;
units "seconds"; description
default 3600; "The scope of the request.";
description
"Indicates the lifetime of the mitigation request.";
}
leaf mitigation-start { leaf mitigation-id {
type int64; type int32;
units "seconds"; description
description "Mitigation request identifier.
"Mitigation start time is represented in seconds
relative to 1970-01-01T00:00Z in UTC time.";
}
leaf status { This identifier must be unique for each mitigation
type enumeration { request bound to the DOTS client.";
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" { uses target;
description
"Attack has stopped and the DOTS client can
withdraw the mitigation request.";
}
enum "4" { leaf lifetime {
description type int32;
"Attack has exceeded the mitigation provider units "seconds";
capability."; default 3600;
} description
"Indicates the lifetime of the mitigation request.";
reference
"RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel";
}
enum "5" { leaf mitigation-start {
description type int64;
"DOTS client has withdrawn the mitigation units "seconds";
request and the mitigation is active but description
terminating."; "Mitigation start time is represented in seconds
} relative to 1970-01-01T00:00Z in UTC time.";
}
enum "6" { leaf status {
description type enumeration {
"Attack mitigation is now terminated."; enum "1" {
} description
"Attack mitigation is in progress (e.g., changing
the network path to re-route the inbound traffic
to DOTS mitigator).";
}
enum "7" { enum "2" {
description description
"Attack mitigation is withdrawn."; "Attack is successfully mitigated (e.g., traffic
} is redirected to a DDOS mitigator and attack
traffic is dropped).";
}
enum "8" { enum "3" {
description
"Attack mitigation is rejected.";
}
}
config false;
description description
"Indicates the status of a mitigation request. "Attack has stopped and the DOTS client can
It must be included in responses, only."; withdraw the mitigation request.";
} }
container conflict-information { enum "4" {
config false; description
description "Attack has exceeded the mitigation provider
"Indicates that a conflict is detected. capability.";
Must only be used for responses."; }
leaf conflict-status { enum "5" {
type enumeration { description
enum "1" { "DOTS client has withdrawn the mitigation
description request and the mitigation is active but
"DOTS Server has detected conflicting mitigation terminating.";
requests from different DOTS clients. }
This mitigation request is currently inactive
until the conflicts are resolved. Another
mitigation request is active.";
}
enum "2" { enum "6" {
description description
"DOTS Server has detected conflicting mitigation "Attack mitigation is now terminated.";
requests from different DOTS clients. }
This mitigation request is currently active.";
}
enum "3" { enum "7" {
description description
"DOTS Server has detected conflicting mitigation "Attack mitigation is withdrawn.";
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 { enum "8" {
type enumeration { description
enum "1" { "Attack mitigation is rejected.";
description }
"Overlapping target prefixes."; }
} config false;
description
"Indicates the status of a mitigation request.
It must be included in responses, only.";
}
enum "2" { container conflict-information {
description config false;
"Conflicts with an existing white list."; description
} "Indicates that a conflict is detected.
} Must only be used for responses.";
description
"Indicates the cause of the conflict.
It must be included in responses, only.";
}
leaf retry-timer { leaf conflict-status {
type int32; type enumeration {
units "seconds"; enum "1" {
description description
"The DOTS client must not re-send the "DOTS Server has detected conflicting mitigation
same request before the expiry of this timer. requests from different DOTS clients.
It must be included in responses, only."; This mitigation request is currently inactive
} until the conflicts are resolved. Another
} mitigation request is active.";
leaf pkts-dropped { }
type yang:zero-based-counter64;
config false;
description
"Number of dropped packets";
}
leaf bps-dropped { enum "2" {
type yang:zero-based-counter64; description
config false; "DOTS Server has detected conflicting mitigation
description requests from different DOTS clients.
"The average dropped bytes per second for This mitigation request is currently active.";
the mitigation request since the attack }
mitigation is triggered.";
}
leaf bytes-dropped { enum "3" {
type yang:zero-based-counter64; description
units 'bytes'; "DOTS Server has detected conflicting mitigation
config false; requests from different DOTS clients. All
description conflicting mitigation requests are inactive.";
"Counter for dropped pacckets; in bytes."; }
} }
description
"Indicates the conflict status.
It must be included in responses, only.";
}
leaf pps-dropped { leaf conflict-cause {
type yang:zero-based-counter64; type enumeration {
config false; enum "1" {
description description
"The average dropped packets per second "Overlapping targets. conflict-scope provides
for the mitigation request since the attack more details about the exact conflict.";
mitigation is triggered."; }
}
}
}
} enum "2" {
<CODE ENDS> description
"Conflicts with an existing white list.
5.3. Session Configuration YANG Module Tree Structure 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.";
}
This document defines the YANG module "ietf-dots-signal-config" leaf retry-timer {
(Section 5.4), which has the following structure: type int32;
units "seconds";
description
"The DOTS client must not re-send the
same request before the expiry of this timer.
It must be included in responses, only.";
}
module: ietf-dots-signal-config container conflict-scope {
+--rw signal-config description
+--rw session-id? int32 "Provides more information about the conflict scope.";
+--rw heartbeat-interval? int16 uses target;
+--rw missing-hb-allowed? int16 }
+--rw max-retransmit? int16 }
+--rw ack-timeout? int16
+--rw ack-random-factor? decimal64
+--rw trigger-mitigation? boolean
5.4. Session Configuration YANG Module leaf pkts-dropped {
type yang:zero-based-counter64;
config false;
description
"Number of dropped packets";
}
<CODE BEGINS> file "ietf-dots-signal-config@2017-11-27.yang" 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.";
}
module ietf-dots-signal-config { leaf bytes-dropped {
yang-version 1.1; type yang:zero-based-counter64;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-config"; units 'bytes';
prefix "config"; config false;
description
"Counter for dropped pacckets; in bytes.";
}
organization "IETF DOTS Working Group"; 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.";
}
}
}
contact grouping signal-config {
"Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com> description
Mohamed Boucadair <mohamed.boucadair@orange.com> "DOTS signal channel session configuration.";
Prashanth Patil <praspati@cisco.com>
Andrew Mortensen <amortensen@arbor.net>
Nik Teague <nteague@verisign.com>";
description leaf session-id {
"This module contains YANG definition for DOTS type int32;
signal channel session configuration. mandatory true;
description
"An identifier for the DOTS signal channel
session configuration data.";
}
Copyright (c) 2017 IETF Trust and the persons identified as leaf heartbeat-interval {
authors of the code. All rights reserved. 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";
}
Redistribution and use in source and binary forms, with or leaf missing-hb-allowed {
without modification, is permitted pursuant to, and subject type int16;
to the license terms contained in, the Simplified BSD License default 5;
set forth in Section 4.c of the IETF Trust's Legal Provisions description
Relating to IETF Documents "Maximum number of missing heartbeats allowed.";
(http://trustee.ietf.org/license-info). reference
"RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel";
}
This version of this YANG module is part of RFC XXXX; see leaf max-retransmit {
the RFC itself for full legal notices."; 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";
}
revision 2017-11-27 { leaf ack-timeout {
description type int16;
"Initial revision."; units "seconds";
reference default 2;
"RFC XXXX: A Distributed Denial-of-Service Open Threat description
Signaling (DOTS) Signal Channel"; "Initial retransmission timeout value.";
} reference
"Section 4.8 of RFC 7552.";
}
container signal-config { leaf ack-random-factor {
description type decimal64 {
"DOTS signal channel session configuration."; fraction-digits 2;
}
default 1.5;
description
"Random factor used to influence the timing of
retransmissions.";
reference
"Section 4.8 of RFC 7552.";
}
leaf session-id { leaf trigger-mitigation {
type int32; type boolean;
description default true;
"An identifier for the DOTS signal channel description
session configuration data."; "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";
}
}
leaf heartbeat-interval { container dots-signal {
type int16; description
units "seconds"; "Main contaner for DOTS signal message.
default 30; A DOTS signal message can be a mitigation messages or
description a configuration message.";
"DOTS agents regularly send heartbeats to each other
after mutual authentication in order to keep
the DOTS signal channel open.";
}
leaf missing-hb-allowed { choice message-type {
type int16; description
default 5; "Either a mitigation or a configuration message.";
description
"Maximum number of missing heartbeats allowed.";
}
leaf max-retransmit { case mitigation-scope {
type int16; description
default 3; "Mitigation scope of a mitigation message.";
description uses mitigation-scope;
"Maximum number of retransmissions of a }
Confirmable message.";
}
leaf ack-timeout {
type int16;
units "seconds";
default 2;
description
"Initial retransmission timeout value.";
}
leaf ack-random-factor { case configuration {
type decimal64 { description
fraction-digits 2; "Configuration message.";
} uses signal-config;
default 1.5;
description
"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>
6. Mapping Parameters to CBOR 6. Mapping Parameters to CBOR
All parameters in the payload in the DOTS signal channel MUST be 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 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 to save space. The recipient of the payload MAY reject the
information if it is not suitably mapped. information if it is not suitably mapped.
skipping to change at page 51, line 20 skipping to change at page 56, line 20
the TLS second flight of messages (ChangeCipherSpec) to also the TLS second flight of messages (ChangeCipherSpec) to also
contain the DOTS signal. contain the DOTS signal.
o Cached Information Extension [RFC7924] which avoids transmitting o Cached Information Extension [RFC7924] which avoids transmitting
the server's certificate and certificate chain if the client has the server's certificate and certificate chain if the client has
cached that information from a previous TLS handshake. cached that information from a previous TLS handshake.
o TCP Fast Open [RFC7413] can reduce the number of round-trips to o TCP Fast Open [RFC7413] can reduce the number of round-trips to
convey DOTS signal. convey DOTS signal.
7.2. MTU and Fragmentation 7.2. (D)TLS 1.3 Considerations
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.
8. (D)TLS 1.3 Considerations
TLS 1.3 [I-D.ietf-tls-tls13] provides critical latency improvements TLS 1.3 [I-D.ietf-tls-tls13] provides critical latency improvements
for connection establishment over TLS 1.2. The DTLS 1.3 protocol for connection establishment over TLS 1.2. The DTLS 1.3 protocol
[I-D.rescorla-tls-dtls13] is based on the TLS 1.3 protocol and [I-D.ietf-tls-dtls13] is based on the TLS 1.3 protocol and provides
provides equivalent security guarantees. (D)TLS 1.3 provides two equivalent security guarantees. (D)TLS 1.3 provides two basic
basic handshake modes of interest to DOTS signal channel: handshake modes of interest to DOTS signal channel:
o Absent packet loss, a full handshake in which the DOTS client is 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 able to send the DOTS signal message after one round trip and the
DOTS server immediately after receiving the first DOTS signal DOTS server immediately after receiving the first DOTS signal
message from the client. message from the client.
o 0-RTT mode in which the DOTS client can authenticate itself and o 0-RTT mode in which the DOTS client can authenticate itself and
send DOTS signal message on its first flight, thus reducing send DOTS signal message on its first flight, thus reducing
handshake latency. 0-RTT only works if the DOTS client has handshake latency. 0-RTT only works if the DOTS client has
previously communicated with that DOTS server, which is very previously communicated with that DOTS server, which is very
likely with the DOTS signal channel. The DOTS client SHOULD likely with the DOTS signal channel. The DOTS client SHOULD
establish a (D)TLS session with the DOTS server during peacetime establish a (D)TLS session with the DOTS server during peacetime
and share a PSK. During DDOS attack, the DOTS client can use the 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 (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 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 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 simplified TLS 1.3 handshake with 0-RTT DOTS signal message
exchange is shown in Figure 21. exchange is shown in Figure 23.
DOTS Client DOTS Server DOTS Client DOTS Server
ClientHello ClientHello
(Finished) (Finished)
(0-RTT DOTS signal message) (0-RTT DOTS signal message)
(end_of_early_data) --------> (end_of_early_data) -------->
ServerHello ServerHello
{EncryptedExtensions} {EncryptedExtensions}
{ServerConfiguration} {ServerConfiguration}
{Certificate} {Certificate}
{CertificateVerify} {CertificateVerify}
{Finished} {Finished}
<-------- [DOTS signal message] <-------- [DOTS signal message]
{Finished} --------> {Finished} -------->
[DOTS signal message] <-------> [DOTS signal message] [DOTS signal message] <-------> [DOTS signal message]
Figure 21: TLS 1.3 handshake with 0-RTT Figure 23: TLS 1.3 handshake with 0-RTT
9. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients 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.
8. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients
(D)TLS based on client certificate can be used for mutual (D)TLS based on client certificate can be used for mutual
authentication between DOTS agents. If a DOTS gateway is involved, authentication between DOTS agents. If a DOTS gateway is involved,
DOTS clients and DOTS gateway MUST perform mutual authentication; DOTS clients and DOTS gateway MUST perform mutual authentication;
only authorized DOTS clients are allowed to send DOTS signals to a only authorized DOTS clients are allowed to send DOTS signals to a
DOTS gateway. DOTS gateway and DOTS server MUST perform mutual DOTS gateway. DOTS gateway and DOTS server MUST perform mutual
authentication; DOTS server only allows DOTS signals from authorized authentication; DOTS server only allows DOTS signals from authorized
DOTS gateway, creating a two-link chain of transitive authentication DOTS gateway, creating a two-link chain of transitive authentication
between the DOTS client and the DOTS server. between the DOTS client and the DOTS server.
skipping to change at page 53, line 39 skipping to change at page 58, line 39
| +--------------+ | | | | | | +--------------+ | | | | |
| +----+--------+ | +---------------+ | +----+--------+ | +---------------+
| ^ | | ^ |
| | | | | |
| +----------------+ | | | +----------------+ | |
| | DDOS detector | | | | | DDOS detector | | |
| | (DOTS client) +<---------------+ | | | (DOTS client) +<---------------+ |
| +----------------+ | | +----------------+ |
+-----------------------------------------------+ +-----------------------------------------------+
Figure 22: Example of Authentication and Authorization of DOTS Agents Figure 24: Example of Authentication and Authorization of DOTS Agents
In the example depicted in Figure 22, the DOTS gateway and DOTS In the example depicted in Figure 24, the DOTS gateway and DOTS
clients within the 'example.com' domain mutually authenticate with clients within the 'example.com' domain mutually authenticate with
each other. After the DOTS gateway validates the identity of a DOTS each other. After the DOTS gateway validates the identity of a DOTS
client, it communicates with the AAA server in the 'example.com' client, it communicates with the AAA server in the 'example.com'
domain to determine if the DOTS client is authorized to request DDOS domain to determine if the DOTS client is authorized to request DDOS
mitigation. If the DOTS client is not authorized, a 4.01 mitigation. If the DOTS client is not authorized, a 4.01
(Unauthorized) is returned in the response to the DOTS client. In (Unauthorized) is returned in the response to the DOTS client. In
this example, the DOTS gateway only allows the application server and this example, the DOTS gateway only allows the application server and
DDOS detector to request DDOS mitigation, but does not permit the DDOS detector to request DDOS mitigation, but does not permit the
user of type 'guest' to request DDOS mitigation. user of type 'guest' to request DDOS mitigation.
Also, DOTS gateway and DOTS server located in different domains MUST Also, DOTS gateway and DOTS server located in different domains MUST
perform mutual authentication (e.g., using certificates). A DOTS perform mutual authentication (e.g., using certificates). A DOTS
server will only allow a DOTS gateway with a certificate for a server will only allow a DOTS gateway with a certificate for a
particular domain to request mitigation for that domain. In particular domain to request mitigation for that domain. In
reference to Figure 22, the DOTS server only allows the DOTS gateway reference to Figure 24, the DOTS server only allows the DOTS gateway
to request mitigation for 'example.com' domain and not for other to request mitigation for 'example.com' domain and not for other
domains. domains.
10. IANA Considerations 9. IANA Considerations
This specification registers a default port, new URI suffix in the This specification registers a service port (Section 9.1), an URI
Well-Known URIs registry, new CoAP response code, new parameters for suffix in the Well-Known URIs registry (Section 9.2), a CoAP response
DOTS signal channel and establishes registries for mappings to CBOR. code (Section 9.3), a YANG module (Section 9.5). It also creates a
registry for mappings to CBOR (Section 9.4).
10.1. DOTS Signal Channel UDP and TCP Port Number 9.1. DOTS Signal Channel UDP and TCP Port Number
IANA has assigned the port number TBD to the DOTS signal channel IANA is requested to assign the port number TBD to the DOTS signal
protocol, for both UDP and TCP. 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.
10.2. Well-Known 'dots' URI It is strongly suggested that the port number 4646 is to be assigned.
4646 is the ASCII decimal value for ".." (DOTS).
This memo registers the 'dots' well-known URI in the Well-Known URIs 9.2. Well-Known 'dots' URI
registry as defined by [RFC5785].
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 URI suffix: dots
Change controller: IETF Change controller: IETF
Specification document(s): This RFC Specification document(s): This RFC
Related information: None Related information: None
10.3. CoAP Response Code 9.3. CoAP Response Code
The following entry is added to the "CoAP Response Codes" sub- IANA is requested to add the following entry to the "CoAP Response
registry: Codes" sub-registry available at https://www.iana.org/assignments/
core-parameters/core-parameters.xhtml#response-codes:
+------+------------------+-----------+ +------+------------------+-----------+
| Code | Description | Reference | | Code | Description | Reference |
+------+------------------+-----------+ +------+------------------+-----------+
| 3.00 | Alternate server | [RFCXXXX] | | 3.00 | Alternate server | [RFCXXXX] |
+------+------------------+-----------+ +------+------------------+-----------+
Table 4: CoAP Response Code Table 4: CoAP Response Code
10.4. DOTS Signal Channel CBOR Mappings Registry 9.4. DOTS Signal Channel CBOR Mappings Registry
A new registry will be requested from IANA, entitled "DOTS signal The document requests IANA to create a new registry, entitled "DOTS
channel CBOR Mappings Registry". The registry is to be created as Signal Channel CBOR Mappings Registry". The structrue of this
Expert Review Required. registry is provided in Section 9.4.1.
10.4.1. Registration Template 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 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 55, line 35 skipping to change at page 60, line 48
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.4.2. Initial Registry Contents 9.4.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 60, line 36 skipping to change at page 66, line 5
o CBOR Major Type: 2 o CBOR Major Type: 2
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name:ttl o Parameter Name:ttl
o CBOR Key Value: 40 o CBOR Key Value: 40
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
10.5. YANG Modules 9.5. DOTS Signal Channel YANG Module
This document requests IANA to register the following URIs in the This document requests IANA to register the following URI in the
"IETF XML Registry" [RFC3688]: "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-config This document requests IANA to register the following YANG module in
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG modules in
the "YANG Module Names" registry [RFC7950]. the "YANG Module Names" registry [RFC7950].
name: ietf-signal name: ietf-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
reference: RFC XXXX reference: RFC XXXX
name: ietf-dots-signal-config
namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-config
prefix: config
reference: RFC XXXX
11. Implementation Status 10. 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
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
skipping to change at page 61, line 40 skipping to change at page 66, line 47
features. Readers are advised to note that other implementations may features. Readers are advised to note that other implementations may
exist. exist.
According to [RFC7942], "this will allow reviewers and working groups According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see fit". they see fit".
11.1. nttdots 10.1. nttdots
Organization: NTT Communication is developing a DOTS client and Organization: NTT Communication is developing a DOTS client and
DOTS server software based on DOTS signal channel specified in DOTS server software based on DOTS signal channel specified in
this draft. It will be open-sourced. this draft. It will be open-sourced.
Description: Early implementation of DOTS protocol. It is aimed to Description: Early implementation of DOTS protocol. It is aimed to
implement a full DOTS protocol spec in accordance with maturing of implement a full DOTS protocol spec in accordance with maturing of
DOTS protocol itself. DOTS protocol itself.
Implementation: https://github.com/nttdots/go-dots Implementation: https://github.com/nttdots/go-dots
Level of maturity: It is a early implementation of DOTS protocol. Level of maturity: It is a early implementation of DOTS protocol.
Messaging between DOTS clients and DOTS servers has been tested. Messaging between DOTS clients and DOTS servers has been tested.
Level of maturity will increase in accordance with maturing of Level of maturity will increase in accordance with maturing of
DOTS protocol itself. DOTS protocol itself.
Coverage: Capability of DOTS client: sending DOTS messages to the Coverage: Capability of DOTS client: sending DOTS messages to the
DOTS server in CoAP over DTLS as dots-signal. Capability of DOTS DOTS server in CoAP over DTLS as dots-signal. Capability of DOTS
server: receiving dots-signal, validating received dots-signal, server: receiving dots-signal, validating received dots-signal,
starting mitigation by handing over the dots-signal to DDOS starting mitigation by handing over the dots-signal to DDOS
mitigator. mitigator.
Licensing: It will be open-sourced with BSD 3-clause license. Licensing: It will be open-sourced with BSD 3-clause license.
Implementation experience: It is implemented in Go-lang. Core Implementation experience: It is implemented in Go-lang. Core
specification of signaling is mature to be implemented, however, specification of signaling is mature to be implemented, however,
finding good libraries(like DTLS, CoAP) is rather difficult. finding good libraries(like DTLS, CoAP) is rather difficult.
Contact: Kaname Nishizuka <kaname@nttv6.jp> Contact: Kaname Nishizuka <kaname@nttv6.jp>
12. Security Considerations 11. Security Considerations
Authenticated encryption MUST be used for data confidentiality and Authenticated encryption MUST be used for data confidentiality and
message integrity. The interaction between the DOTS agents requires message integrity. The interaction between the DOTS agents requires
Datagram Transport Layer Security (DTLS) and Transport Layer Security Datagram Transport Layer Security (DTLS) and Transport Layer Security
(TLS) with a cipher suite offering confidentiality protection and the (TLS) with a cipher suite offering confidentiality protection and the
guidance given in [RFC7525] MUST be followed to avoid attacks on guidance given in [RFC7525] MUST be followed to avoid attacks on
(D)TLS. (D)TLS.
A single DOTS signal channel between DOTS agents can be used to A single DOTS signal channel between DOTS agents can be used to
exchange multiple DOTS signal messages. To reduce DOTS client and exchange multiple DOTS signal messages. To reduce DOTS client and
skipping to change at page 63, line 7 skipping to change at page 68, line 15
network). network).
Involved functional elements in the cooperation system must establish Involved functional elements in the cooperation system must establish
exchange instructions and notification over a secure and exchange instructions and notification over a secure and
authenticated channel. Adequate filters can be enforced to avoid authenticated channel. Adequate filters can be enforced to avoid
that nodes outside a trusted domain can inject request such as that nodes outside a trusted domain can inject request such as
deleting filtering rules. Nevertheless, attacks can be initiated deleting filtering rules. Nevertheless, attacks can be initiated
from within the trusted domain if an entity has been corrupted. from within the trusted domain if an entity has been corrupted.
Adequate means to monitor trusted nodes should also be enabled. Adequate means to monitor trusted nodes should also be enabled.
13. Contributors 12. Contributors
The following individuals have contributed to this document: The following individuals have contributed to this document:
Mike Geller Cisco Systems, Inc. 3250 Florida 33309 USA Email: Mike Geller Cisco Systems, Inc. 3250 Florida 33309 USA Email:
mgeller@cisco.com mgeller@cisco.com
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 13. Acknowledgements
Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw, Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw,
Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang
Xia, Jon Shallow, Gilbert Clark, and Nesredien Suleiman for the Xia, Jon Shallow, Gilbert Clark, and Nesredien Suleiman for the
discussion and comments. discussion and comments.
15. References 14. References
15.1. Normative References 14.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-10 (work in progress), draft-ietf-core-coap-tcp-tls-10 (work in progress),
October 2017. October 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 65, line 20 skipping to change at page 70, line 31
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[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 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and
FETCH Methods for the Constrained Application Protocol FETCH Methods for the Constrained Application Protocol
(CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
<https://www.rfc-editor.org/info/rfc8132>. <https://www.rfc-editor.org/info/rfc8132>.
15.2. Informative References 14.2. Informative References
[I-D.ietf-core-comi] [I-D.ietf-core-comi]
Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP
Management Interface", draft-ietf-core-comi-01 (work in Management Interface", draft-ietf-core-comi-01 (work in
progress), July 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-05 (work in progress), August draft-ietf-core-yang-cbor-05 (work in progress), August
skipping to change at page 66, line 22 skipping to change at page 71, line 36
Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
Open Threat Signaling", draft-ietf-dots-use-cases-09 (work Open Threat Signaling", draft-ietf-dots-use-cases-09 (work
in progress), November 2017. in progress), November 2017.
[I-D.ietf-netmod-yang-tree-diagrams] [I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-02 (work in progress), ietf-netmod-yang-tree-diagrams-02 (work in progress),
October 2017. 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] [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-21 (work in progress), Version 1.3", draft-ietf-tls-tls13-21 (work in progress),
July 2017. July 2017.
[I-D.rescorla-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-rescorla-tls-dtls13-01 (work in progress),
March 2017.
[proto_numbers] [proto_numbers]
"IANA, "Protocol Numbers"", 2011, "IANA, "Protocol Numbers"", 2011,
<http://www.iana.org/assignments/protocol-numbers>. <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,
<https://www.rfc-editor.org/info/rfc791>. <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 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006, DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>. <https://www.rfc-editor.org/info/rfc4340>.
[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, <https://www.rfc-editor.org/info/rfc4632>. 2006, <https://www.rfc-editor.org/info/rfc4632>.
skipping to change at page 68, line 5 skipping to change at page 73, line 23
<https://www.rfc-editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>. <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 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
NETCONF Protocol over Transport Layer Security (TLS) with NETCONF Protocol over Transport Layer Security (TLS) with
Mutual X.509 Authentication", RFC 7589, Mutual X.509 Authentication", RFC 7589,
DOI 10.17487/RFC7589, June 2015, DOI 10.17487/RFC7589, June 2015,
<https://www.rfc-editor.org/info/rfc7589>. <https://www.rfc-editor.org/info/rfc7589>.
[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start", RFC 7918, Layer Security (TLS) False Start", RFC 7918,
DOI 10.17487/RFC7918, August 2016, DOI 10.17487/RFC7918, August 2016,
<https://www.rfc-editor.org/info/rfc7918>. <https://www.rfc-editor.org/info/rfc7918>.
 End of changes. 230 change blocks. 
884 lines changed or deleted 1015 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/