< draft-ietf-dots-signal-channel-17.txt   draft-ietf-dots-signal-channel-18.txt >
DOTS T. Reddy, Ed. DOTS T. Reddy, Ed.
Internet-Draft McAfee Internet-Draft McAfee
Intended status: Standards Track M. Boucadair, Ed. Intended status: Standards Track M. Boucadair, Ed.
Expires: July 26, 2018 Orange Expires: September 21, 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.
January 22, 2018 March 20, 2018
Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel Specification Channel Specification
draft-ietf-dots-signal-channel-17 draft-ietf-dots-signal-channel-18
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
purposes. purposes.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Please update these statements with the RFC number to be assigned to Please update these statements with the RFC number to be assigned to
this document: this document:
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 Specification";
o "| 3.00 | Alternate server | [RFCXXXX] |" o "| [RFCXXXX] |"
o reference: RFC XXXX o reference: RFC XXXX
Please update TBD statements with the port number to be assigned to Please update TBD statements with the port number to be assigned to
DOTS Signal Channel Protocol. DOTS Signal Channel Protocol.
Also, please update the "revision" date of the YANG module.
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 July 26, 2018. This Internet-Draft will expire on September 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 48 skipping to change at page 2, line 48
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions and Terminology . . . . . . . . . . . 5 2. Notational Conventions and Terminology . . . . . . . . . . . 5
3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6
4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 8 4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 8
4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . 9 4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 9
4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 10 4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 10
4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 11 4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 11
4.4.2. Retrieve Information Related to a Mitigation . . . . 24 4.4.2. Retrieve Information Related to a Mitigation . . . . 25
4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 31 4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 33
4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 33 4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 35
4.5. DOTS Signal Channel Session Configuration . . . . . . . . 34 4.5. DOTS Signal Channel Session Configuration . . . . . . . . 36
4.5.1. Discover Configuration Parameters . . . . . . . . . . 36 4.5.1. Discover Configuration Parameters . . . . . . . . . . 38
4.5.2. Convey DOTS Signal Channel Session Configuration . . 41 4.5.2. Convey DOTS Signal Channel Session Configuration . . 42
4.5.3. Delete DOTS Signal Channel Session Configuration . . 45 4.5.3. Configuration Freshness and Notifications . . . . . . 47
4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 46 4.5.4. Delete DOTS Signal Channel Session Configuration . . 48
4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 47 4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 49
5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . . . 49 4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 50
5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 49 5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . . . 52
5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 51 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 52
6. Mapping Parameters to CBOR . . . . . . . . . . . . . . . . . 65 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 54
7. (D)TLS Protocol Profile and Performance Considerations . . . 67 6. Mapping Parameters to CBOR . . . . . . . . . . . . . . . . . 67
7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 67 7. (D)TLS Protocol Profile and Performance Considerations . . . 69
7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 68 7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 69
7.3. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 69 7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 71
7.3. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 72
8. Mutual Authentication of DOTS Agents & Authorization of DOTS 8. Mutual Authentication of DOTS Agents & Authorization of DOTS
Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74
9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 72 9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 74
9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 72 9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 74
9.3. CoAP Response Code . . . . . . . . . . . . . . . . . . . 72 9.3. CoAP Response Code . . . . . . . . . . . . . . . . . . . 75
9.4. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 73 9.4. CoAP Option Number . . . . . . . . . . . . . . . . . . . 75
9.4.1. Registration Template . . . . . . . . . . . . . . . . 73 9.5. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 75
9.4.2. Initial Registry Content . . . . . . . . . . . . . . 73 9.5.1. Registration Template . . . . . . . . . . . . . . . . 76
9.5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . 75 9.5.2. Initial Registry Content . . . . . . . . . . . . . . 76
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 75 9.6. DOTS Signal Channel YANG Module . . . . . . . . . . . . . 77
10.1. nttdots . . . . . . . . . . . . . . . . . . . . . . . . 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 78
11. Security Considerations . . . . . . . . . . . . . . . . . . . 76 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 79
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 77 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 79
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 77 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 79
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 78 13.1. Normative References . . . . . . . . . . . . . . . . . . 79
14.1. Normative References . . . . . . . . . . . . . . . . . . 78 13.2. Informative References . . . . . . . . . . . . . . . . . 81
14.2. Informative References . . . . . . . . . . . . . . . . . 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 85
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 84
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 13 skipping to change at page 4, line 13
DDoS attacker may be able to prevent an application from performing DDoS attacker may be able to prevent an application from performing
its intended task by making the application exhaust its finite its intended task by making the application exhaust its finite
resources. resources.
TCP DDoS SYN-flood, for example, is a memory-exhausting attack while TCP DDoS SYN-flood, for example, is a memory-exhausting attack while
ACK-flood is a CPU-exhausting attack [RFC4987]. Attacks on the link ACK-flood is a CPU-exhausting attack [RFC4987]. Attacks on the link
are carried out by sending enough traffic so that the link becomes are carried out by sending enough traffic so that the link becomes
congested, thereby likely causing packet loss for legitimate traffic. congested, thereby likely causing packet loss for legitimate traffic.
Stateful firewalls can also be attacked by sending traffic that Stateful firewalls can also be attacked by sending traffic that
causes the firewall to maintain an excessive number of states that causes the firewall to maintain an excessive number of states that
may jeopardize the firewall's operation overall, besides like may jeopardize the firewall's operation overall, besides likely
performance impacts. The firewall then runs out of memory, and can performance impacts. The firewall then runs out of memory, and can
no longer instantiate the states required to process legitimate no longer instantiate the states required to process legitimate
flows. Other possible DDoS attacks are discussed in [RFC4732]. flows. 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 cause(s) of an attack. They may instead just realize determine the cause(s) of an attack. They may instead just realize
that certain resources seem to be under attack. This document that certain resources seem to be under attack. This document
defines a lightweight protocol that allows a DOTS client to request defines a lightweight protocol that allows a DOTS client to request
mitigation from one or more DOTS servers for protection against mitigation from one or more DOTS servers for protection against
detected, suspected, or anticipated attacks. This protocol enables detected, suspected, or anticipated attacks. This protocol enables
skipping to change at page 6, line 6 skipping to change at page 6, line 6
"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 is used for statements that apply to both Transport Layer (D)TLS is used for statements that apply to both Transport Layer
Security [RFC5246] and Datagram Transport Layer Security [RFC6347]. Security [RFC5246] and Datagram Transport Layer Security [RFC6347].
Specific terms are used for any statement that applies to either Specific terms are used for any statement 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-requirements].
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]. [RFC8340].
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
Application Protocol (CoAP) [RFC7252], a lightweight protocol Application Protocol (CoAP) [RFC7252], a lightweight protocol
originally designed for constrained devices and networks. The many originally designed for constrained devices and networks. The many
features of CoAP (expectation of packet loss, support for features of CoAP (expectation of packet loss, support for
asynchronous non-confirmable messaging, congestion control, small asynchronous non-confirmable messaging, congestion control, small
message overhead limiting the need for fragmentation, use of minimal message overhead limiting the need for fragmentation, use of minimal
resources, and support for (D)TLS) makes it a good candidate to build resources, and support for (D)TLS) makes it a good candidate to build
skipping to change at page 8, line 38 skipping to change at page 8, line 38
gateway will need to update the DOTS messages, based upon the gateway will need to update the DOTS messages, based upon the
local translator's binding table. local translator's binding table.
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. The description of such means is out of scope of this document.
Likewise, it is out of scope of this document to specify the behavior Likewise, it is out of scope of this document to specify the behavior
of a DOTS client when it sends requests (e.g., contact all servers, of a DOTS client when it sends requests (e.g., contact all servers,
select one server among the list) when multiple DOTS servers are select one server among the list) when multiple DOTS servers are
provisioned. provisioned.
4.2. CoAP URIs 4.2. CoAP URIs
The DOTS server MUST support the use of the path-prefix of "/.well- The DOTS server MUST support the use of the path-prefix of "/.well-
known/" as defined in [RFC5785] and the registered name of "dots". known/" as defined in [RFC5785] and the registered name of "dots".
skipping to change at page 9, line 46 skipping to change at page 9, line 46
over TCP, thereby incurring significant connection delays. over TCP, thereby incurring significant connection delays.
To overcome these connection setup problems, the DOTS client attempts To overcome these connection setup problems, the DOTS client attempts
to connect to its DOTS server(s) using both IPv6 and IPv4, and tries to connect to its DOTS server(s) using both IPv6 and IPv4, and tries
both DTLS over UDP and TLS over TCP in a manner similar to the Happy both DTLS over UDP and TLS over TCP in a manner similar to the Happy
Eyeballs mechanism [RFC8305]. These connection attempts are Eyeballs mechanism [RFC8305]. These connection attempts are
performed by the DOTS client when it initializes. The results of the performed by the DOTS client when it initializes. The results of the
Happy Eyeballs procedure are used by the DOTS client for sending its Happy Eyeballs procedure are used by the DOTS client for sending its
subsequent messages to the DOTS server. subsequent messages to the DOTS server.
The order of preference of DOTS signal channel address family and The order of preference of the DOTS signal channel address family and
transport protocol (most preferred first) is: UDP over IPv6, UDP over transport protocol (most preferred first) is: UDP over IPv6, UDP over
IPv4, TCP over IPv6, and finally TCP over IPv4. This order adheres IPv4, TCP over IPv6, and finally TCP over IPv4. This order adheres
to the address preference order specified in [RFC6724] and the DOTS to the address preference order specified in [RFC6724] and the DOTS
signal channel preference which privileges the use of UDP over TCP signal channel preference which privileges the use of UDP over TCP
(to avoid TCP's head of line blocking). (to avoid TCP's head of line blocking).
In reference to Figure 4, the DOTS client sends two TCP SYNs and two In reference to Figure 4, the DOTS client sends two TCP SYNs and two
DTLS ClientHello messages at the same time over IPv6 and IPv4. In DTLS ClientHello messages at the same time over IPv6 and IPv4. In
this example, it is assumed that the IPv6 path is broken and UDP this example, it is assumed that the IPv6 path is broken and UDP
traffic is dropped by a middlebox but has little impact to the DOTS traffic is dropped by a middlebox but has little impact to the DOTS
skipping to change at page 11, line 28 skipping to change at page 11, line 28
possible (case 2 in Section 3.1.3 of [RFC8085]). possible (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 some reason, the DOTS When a DOTS client requires mitigation for some reason, the DOTS
client uses the CoAP PUT method to send a mitigation request to its client uses the CoAP PUT method to send a mitigation request to its
DOTS server(s) (Figure 5, illustrated in JSON diagnostic notation). DOTS server(s) (Figure 5, illustrated in JSON diagnostic notation).
If this DOTS client is entitled to solicit the DOTS service, the DOTS If 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 a mitigator and relaying
selected mitigator feedback to the requesting DOTS client. the feedback of the thus-selected mitigator 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"
Uri-Path: "version" Uri-Path: "version"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
Content-Type: "application/cbor" Content-Type: "application/cbor"
skipping to change at page 13, line 48 skipping to change at page 13, line 48
DOTS gateways MAY rewrite the 'cuid' used by peer DOTS clients. DOTS gateways MAY rewrite the 'cuid' used by peer DOTS clients.
Triggers for such rewriting are out of scope. Triggers for such rewriting are out of scope.
This is a mandatory Uri-Path. This is a mandatory Uri-Path.
mid: Identifier for the mitigation request represented with an mid: Identifier for the mitigation request represented with an
integer. This identifier MUST be unique for each mitigation integer. This identifier MUST be unique for each mitigation
request bound to the DOTS client, i.e., the 'mid' parameter value request bound to the DOTS client, i.e., the 'mid' parameter value
in the mitigation request needs to be unique relative to the 'mid' in the mitigation request needs to be unique relative to the 'mid'
parameter values of active mitigation requests conveyed from the parameter values of active mitigation requests conveyed from the
DOTS client to the DOTS server. DOTS client to the DOTS server. In order to handle out-of-order
delivery of mitigation requests, 'mid' values MUST increase
monotonically.
This identifier MUST be generated by the DOTS client. This This identifier MUST be generated by the DOTS client.
document does not make any assumption about how this identifier is
generated.
This is a mandatory Uri-Path parameter. This is a mandatory Uri-Path parameter.
'cuid' and 'mid' MUST NOT appear in the PUT request message body.
The parameters in the CBOR body of the PUT request are described The parameters in the CBOR body of the PUT request are described
below: below:
target-prefix: A list of prefixes identifying resources under target-prefix: A list of prefixes identifying resources under
attack. Prefixes are represented using Classless Inter-Domain attack. Prefixes are represented using Classless Inter-Domain
Routing (CIDR) notation [RFC4632]. Routing (CIDR) notation [RFC4632].
As a reminder, the prefix length must be less than or equal to 32 As a reminder, the prefix length must be less than or equal to 32
(resp. 128) for IPv4 (resp. IPv6). (resp. 128) for IPv4 (resp. IPv6).
The prefix list MUST NOT include broadcast, loopback, or multicast
addresses. These addresses are considered as invalid values. In
addition, the DOTS server MUST validate that target prefixes are
within the scope of the DOTS client's domain. Other validation
checks may be supported by DOTS servers.
This is an optional attribute. This is an optional attribute.
target-port-range: A list of port numbers bound to resources under target-port-range: A list of port numbers bound to resources under
attack. attack.
A port range is defined by two bounds, a lower port number (lower- A port range is defined by two bounds, a lower port number (lower-
port) and an upper port number (upper-port). When only 'lower- port) and an upper port number (upper-port). When only 'lower-
port' is present, it represents a single port number. port' is present, it represents a single port number.
For TCP, UDP, Stream Control Transmission Protocol (SCTP) For TCP, UDP, Stream Control Transmission Protocol (SCTP)
skipping to change at page 14, line 44 skipping to change at page 15, line 5
The value '0' has a special meaning for 'all protocols'. The value '0' has a special meaning for 'all protocols'.
This is an optional attribute. This is an optional attribute.
target-fqdn: A list of Fully Qualified Domain Names (FQDNs) target-fqdn: A list of Fully Qualified Domain Names (FQDNs)
identifying resources under attack. An FQDN is the full name of a identifying resources under attack. An FQDN is the full name of a
resource, rather than just its hostname. For example, "venera" is resource, rather than just its hostname. For example, "venera" is
a hostname, and "venera.isi.edu" is an FQDN [RFC1983]. a hostname, and "venera.isi.edu" is an FQDN [RFC1983].
How a name is passed to an underlying name resolution library is
implementation- and deployment-specific. Nevertheless, once the
name is resolved into one or multiple IP addresses, DOTS servers
MUST apply the same validation checks as those for 'target-
prefix'.
This is an optional attribute. This is an optional attribute.
target-uri: A list of Uniform Resource Identifiers (URIs) [RFC3986] target-uri: A list of Uniform Resource Identifiers (URIs) [RFC3986]
identifying resources under attack. identifying resources under attack.
The same validation checks used for 'target-fqdn' MUST be followed
by DOTS servers to validate a target URI.
This is an optional attribute. This is an optional attribute.
alias-name: A list of aliases of resources for which the mitigation alias-name: A list of aliases of resources for which the mitigation
is requested. Aliases can be created using the DOTS data channel is requested. Aliases can be created using the DOTS data channel
(Section 6.1 of [I-D.ietf-dots-data-channel]), direct (Section 6.1 of [I-D.ietf-dots-data-channel]), direct
configuration, or other means. configuration, or other means.
An alias is used in subsequent signal channel exchanges to refer An alias is used in subsequent signal channel exchanges to refer
more efficiently to the resources under attack. more efficiently to the resources under attack.
This is an optional attribute. 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 --
minutes) -- this value was chosen to be long enough so that this value was chosen to be long enough so that refreshing is not
refreshing is not typically a burden on the DOTS client, while typically a burden on the DOTS client, while expiring the request
expiring the request where the client has unexpectedly quit in a where the client has unexpectedly quit in a timely manner. DOTS
timely manner. DOTS clients MUST include this parameter in their clients MUST include this parameter in their mitigation requests.
mitigation requests. Upon the expiry of this lifetime, and if the Upon the expiry of this lifetime, and if the request is not
request is not refreshed, the mitigation request is removed. The refreshed, the mitigation request is removed. The request can be
request can be refreshed by sending the same request again. refreshed by sending the same request again.
A lifetime of '0' in a mitigation request is an invalid value. 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. The DOTS server MAY refuse indefinite the mitigation request. The DOTS server MAY refuse indefinite
lifetime, for policy reasons; the granted lifetime value is lifetime, for policy reasons; the granted lifetime value is
returned in the response. DOTS clients MUST be prepared to not be returned in the response. DOTS clients MUST be prepared to not be
granted mitigations with indefinite lifetimes. granted mitigations with indefinite lifetimes.
The DOTS server MUST always indicate the actual lifetime in the The DOTS 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
DOTS client. DOTS client.
This is a mandatory attribute. This is a mandatory attribute.
In deployments where server-domain DOTS gateways are enabled, In deployments where server-domain DOTS gateways are enabled,
identity information about the origin source client domain SHOULD be identity information about the origin source client domain SHOULD be
supplied to the DOTS server. That information is meant to assist the supplied to the DOTS server. That information is meant to assist the
DOTS server to enforce some policies. These policies can be enforced DOTS server to enforce some policies such as correlating DOTS clients
per-client, per-client domain, or both. Figure 6 shows an example of that belong to the same DOTS domain, limiting the number of DOTS
a request relayed by a server-domain DOTS gateway. requests, and identifying the mitigation scope. These policies can
be enforced per-client, per-client domain, or both. Also, the
identity information may be used for auditing and debugging purposes.
Figure 6 shows an example of a request relayed by a server-domain
DOTS gateway.
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: "v1" Uri-Path: "v1"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cdid=7eeaf349529eb55ed50113" Uri-Path: "cdid=7eeaf349529eb55ed50113"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
skipping to change at page 17, line 23 skipping to change at page 18, line 23
Server-domain DOTS gateways SHOULD support a configuration option Server-domain DOTS gateways SHOULD support a configuration option
to instruct whether 'cdid' parameter is to be inserted. to instruct whether 'cdid' parameter is to be inserted.
In order to accommodate deployments that require enforcing per- In order to accommodate deployments that require enforcing per-
client policies, per-client domain policies, or a combination client policies, per-client domain policies, or a combination
thereof, server-domain DOTS gateways MUST supply the SPKI hash of thereof, server-domain DOTS gateways MUST supply the SPKI hash of
the DOTS client X.509 certificate, the DOTS client raw public key, the DOTS client X.509 certificate, the DOTS client raw public key,
or the hash of the "PSK identity" in the 'cdid', following the or the hash of the "PSK identity" in the 'cdid', following the
same rules for generating the hash conveyed in 'cuid', which is same rules for generating the hash conveyed in 'cuid', which is
then used by the ultimate DOTS server to determine the then used by the ultimate DOTS server to determine the
corresponding client's domain. corresponding client's domain. The 'cdid' generated by a server-
domain gateway is likely to be the same as the 'cuid' except if
the DOTS message was relayed by a DOTS gateway or was generated
from a rogue DOTS client.
If a DOTS client is provisioned, for example, with distinct If a DOTS client is provisioned, for example, with distinct
certificates as a function of the peer server-domain DOTS gateway, certificates as a function of the peer server-domain DOTS gateway,
distinct 'cdid' values may be supplied by a server-domain DOTS distinct 'cdid' values may be supplied by a server-domain DOTS
gateway. The ultimate DOTS server MUST treat those 'cdid' values gateway. The ultimate DOTS server MUST treat those 'cdid' values
as equivalent. as equivalent.
The 'cdid' attribute MUST NOT be generated and included by DOTS The 'cdid' attribute MUST NOT be generated and included by DOTS
clients. clients.
DOTS servers MUST ignore 'cdid' attributes that are directly DOTS servers MUST ignore 'cdid' attributes that are directly
supplied by source DOTS clients or client-domain DOTS gateways. supplied by source DOTS clients or client-domain DOTS gateways.
This implies that first server-domain DOTS gateways MUST strip This implies that first server-domain DOTS gateways MUST strip
'cdid' attributes supplied by DOTS clients. DOTS servers SHOULD 'cdid' attributes supplied by DOTS clients. DOTS servers SHOULD
support a configuration parameter to identify DOTS gateways that support a configuration parameter to identify DOTS gateways that
are trusted to supply 'cdid' attributes. are trusted to supply 'cdid' attributes.
Only single-valued 'cdid' are defined in this document. Only single-valued 'cdid' are defined in this document.
This is an optional Uri-Path. This is an optional Uri-Path. When present, 'cdid' MUST be
positioned before 'cuid'.
The CBOR key values for the parameters are defined in Section 6. A DOTS gateway may add the following CoAP option:
Section 9 defines how the CBOR key values can be allocated for future
uses. hop-limit: This option (see Section 9.4) is used to detect and
prevent infinite loops. This option is typically inserted by a
DOTS gateway.
The length of the hop-limit option is 1 byte.
The value of the hop-limit option is encoded as an unsigned
integer (see Section 3.2 of [RFC7252]).
Each intermediate DOTS agent involved in the handling of a DOTS
message MUST decrement the hop-limit option value by 1 prior to
forwarding upstream if this parameter exists. DOTS messages MUST
NOT be forwarded if the hop-limit option is set to '0' after
decrement. Messages that cannot be forwarded because of exhausted
hop-limit SHOULD be logged with a 5.06 (Hop Limit Reached) error
message sent back to the DOTS peer. It is RECOMMENDED that DOTS
clients and gateways support means to alert administrators about
loop errors so that appropriate actions are undertaken.
The initial hop-limit value SHOULD be configurable. If no initial
value is explicitly provided, the default initial hop-limit value
of 16 MUST be used.
Because forwarding errors may occur if inadequate hop-limit values
are used, DOTS agents at the boundaries of an administrative
domain MAY be instructed to rewrite the value of hop-limit carried
in received messages (that is, ignore the value of hop-limit
received in a message).
This is an optional option.
Because of the complexity to handle partial failure cases, this Because of the complexity to handle partial failure cases, this
specification does not allow for including multiple mitigation specification does not allow for including multiple mitigation
requests in the same PUT request. Concretely, a DOTS client MUST NOT requests in the same PUT request. Concretely, a DOTS client MUST NOT
include multiple 'scope' parameters in the same PUT request. include multiple 'scope' parameters in the same PUT request.
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 associated with the domain name or URI
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-prefix', In the PUT request at least one of the attributes 'target-prefix',
'target-fqdn','target-uri', or 'alias-name' MUST be present. 'target-fqdn','target-uri', or 'alias-name' MUST be present.
Attributes and Uri-Path parameters with empty values MUST NOT be Attributes and Uri-Path parameters with empty values MUST NOT be
present in a request. present in a request.
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 'mid' values. If two determined by comparing their respective 'mid' values. If two
skipping to change at page 18, line 31 skipping to change at page 20, line 18
FQDN, URI, or alias-name. To avoid maintaining a long list of FQDN, URI, or alias-name. To avoid maintaining a long list of
overlapping mitigation requests from a DOTS client and avoid error- overlapping mitigation requests from a DOTS client and avoid error-
prone provisioning of mitigation requests from a DOTS client, the prone provisioning of mitigation requests from a DOTS client, the
overlapped lower numeric 'mid' MUST be automatically deleted and no overlapped lower numeric 'mid' MUST be automatically deleted and no
longer available at the DOTS server. longer available at the DOTS server.
Figure 7 shows a PUT request example to signal that ports 80, 8080, Figure 7 shows a PUT request example to signal that ports 80, 8080,
and 443 used by 2001:db8:6401::1 and 2001:db8:6401::2 servers are and 443 used by 2001:db8:6401::1 and 2001:db8:6401::2 servers are
under attack (illustrated in JSON diagnostic notation). The presence under attack (illustrated in JSON diagnostic notation). The presence
of 'cdid' indicates that a server-domain DOTS gateway has modified of 'cdid' indicates that a server-domain DOTS gateway has modified
the initial PUT request sent by the DOTS client. the initial PUT request sent by the DOTS client. Note that 'cdid'
MUST NOT appear in the PUT request message body.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Host: "www.example.com" Uri-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"
Uri-Path: "cdid=7eeaf349529eb55ed50113" Uri-Path: "cdid=7eeaf349529eb55ed50113"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
skipping to change at page 20, line 42 skipping to change at page 22, line 42
Figure 8: PUT for DOTS Mitigation Request (CBOR) Figure 8: PUT for DOTS Mitigation Request (CBOR)
In both DOTS signal and data channel sessions, the DOTS client MUST In both DOTS signal and data channel sessions, the DOTS client MUST
authenticate itself to the DOTS server (Section 8). The DOTS server authenticate itself to the DOTS server (Section 8). The DOTS server
may use the algorithm presented in Section 7 of [RFC7589] to derive may use the algorithm presented in Section 7 of [RFC7589] to derive
the DOTS client identity or username from the client certificate. the DOTS client identity or username from the client certificate.
The DOTS client identity allows the DOTS server to accept mitigation The DOTS client identity allows the DOTS server to accept mitigation
requests with scopes that the DOTS client is authorized to manage. requests with scopes that the DOTS client is authorized to manage.
The DOTS server couples the DOTS signal and data channel sessions The DOTS server couples the DOTS signal and data channel sessions
using the DOTS client identity (e.g., client certificate, 'cuid') and using the DOTS client identity and optionally the 'cdid' parameter
optionally the 'cdid' parameter value, so the DOTS server can value, so the DOTS server can validate whether the aliases conveyed
validate whether the aliases conveyed in the mitigation request were in the mitigation request were indeed created by the same DOTS client
indeed created by the same DOTS client using the DOTS data channel using the DOTS data channel session. If the aliases were not created
session. If the aliases were not created by the DOTS client, the by the DOTS client, the DOTS server MUST return 4.00 (Bad Request) in
DOTS server MUST return 4.00 (Bad Request) in the response. the response.
The DOTS server couples the DOTS signal channel sessions using the The DOTS server couples the DOTS signal channel sessions using the
DOTS client identity and optionally the 'cdid' parameter value, and DOTS client identity and optionally the 'cdid' parameter value, and
the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values to the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values to
detect duplicate mitigation requests. If the mitigation request detect duplicate mitigation requests. If the mitigation request
contains the 'alias-name' and other parameters identifying the target contains the 'alias-name' and other parameters identifying the target
resources (such as 'target-prefix', 'target-port-range', 'target- resources (such as 'target-prefix', 'target-port-range', 'target-
fqdn', or 'target-uri'), the DOTS server appends the parameter values fqdn', or 'target-uri'), the DOTS server appends the parameter values
in 'alias-name' with the corresponding parameter values in 'target- in 'alias-name' with the corresponding parameter values in 'target-
prefix', 'target-port-range', 'target-fqdn', or 'target-uri'. 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 9 shows an example response to a PUT request that is Figure 9 shows an example response to a PUT request that is
successfully processed by a DOTS server (i.e., CoAP 2.xx response successfully processed by a DOTS server (i.e., CoAP 2.xx response
codes). This PUT request is assumed to be relayed by a server-domain codes). This version of the specification forbids 'cuid' and 'cdid'
DOTS gateway. (if used) to be returned in a response.
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"cdid": "7eeaf349529eb55ed50113",
"scope": [ "scope": [
{ {
"mid": 12332, "mid": 12332,
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
Figure 9: 2.xx Response Body Figure 9: 2.xx Response Body
skipping to change at page 23, line 27 skipping to change at page 25, line 25
be rejected by the DOTS server for the same reasons. be rejected by the DOTS server for the same reasons.
The retry-timer SHOULD be equal to the lifetime of the active The retry-timer SHOULD be equal to the lifetime of the active
mitigation request resulting in the deactivation of the mitigation request resulting in the deactivation of the
conflicting mitigation request. The lifetime of the conflicting mitigation request. The lifetime of the
deactivated mitigation request will be updated to (retry-timer deactivated mitigation request will be updated to (retry-timer
+ 45 seconds), so the DOTS client can refresh the deactivated + 45 seconds), so the DOTS client can refresh the deactivated
mitigation request after retry-timer seconds before expiry of mitigation request after retry-timer seconds before expiry of
lifetime and check if the conflict is resolved. lifetime and check if the conflict is resolved.
As an active attack evolves, DOTS clients can adjust the scope of
requested mitigation as necessary, by refining the scope of resources
requiring mitigation. This can be achieved, for example, by (1)
sending a PUT request with a new 'mid' value that will override the
existing one with overlapping mitigation scopes or (2) by re- using
the same 'mid' with updated mitigation scopes.
For a mitigation request to continue beyond the initial negotiated For a mitigation request to continue beyond the initial negotiated
lifetime, the DOTS client has to refresh the current mitigation lifetime, the DOTS client has to refresh the current mitigation
request by sending a new PUT request. This PUT request MUST use the request by sending a new PUT request. This PUT request MUST use the
same 'mid' value, and MUST repeat all the other parameters as sent in same 'mid' value, and MUST repeat all the other parameters as sent in
the original mitigation request apart from a possible change to the the original mitigation request apart from a possible change to the
lifetime parameter value. lifetime parameter value.
The DOTS gateway that inserted a 'cdid' in a request, MUST strip the
'cdid' parameter in the corresponding response before forwarding the
response to the DOTS client. If we consider the example depicted in
Figure 9, the message that will be relayed by the DOTS gateway is
shown in Figure 10.
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"mid": 12332,
"lifetime": 3600
}
]
}
}
Figure 10: 2.xx Response Body Relayed by a DOTS Gateway
4.4.2. Retrieve Information Related to a Mitigation 4.4.2. Retrieve Information Related to a Mitigation
A GET request is used by a DOTS client to retrieve information A GET request is used by a DOTS client to retrieve information
(including status) of DOTS mitigations from a DOTS server. (including status) of DOTS mitigations from a DOTS server.
'cuid' is a mandatory Uri-Query parameter for GET requests. 'cuid' is a mandatory Uri-Path parameter for GET requests.
Uri-Query parameters with empty values MUST NOT be present in a Uri-Path parameters with empty values MUST NOT be present in a
request. request.
The same considerations for manipulating 'cdid' parameter by server- The same considerations for manipulating 'cdid' parameter by server-
domain DOTS gateways specified in Section 4.4.1 MUST be followed for domain DOTS gateways specified in Section 4.4.1 MUST be followed for
GET requests. GET requests.
If the DOTS server does not find the 'mid' Uri-Query value conveyed If the DOTS server does not find the 'mid' Uri-Path value conveyed in
in the GET request in its configuration data for the requesting DOTS the GET request in its configuration data for the requesting DOTS
client, it MUST respond with a 4.04 (Not Found) error response code. client, it MUST respond with a 4.04 (Not Found) error response code.
Likewise, the same error MUST be returned as a response to a request Likewise, the same error MUST be returned as a response to a request
to retrieve all mitigation records (i.e., 'mid' Uri-Query is not to retrieve all mitigation records (i.e., 'mid' Uri-Path is not
defined) of a given DOTS client if the DOTS server does not find any defined) of a given DOTS client if the DOTS server does not find any
mitigation record for that DOTS client. As a reminder, a DOTS client mitigation record for that DOTS client. As a reminder, a DOTS client
is identified by its identity (e.g., client certificate, 'cuid') and is identified by its identity (e.g., client certificate, 'cuid') and
optionally the 'cdid'. optionally the 'cdid'.
The 'c' (content) parameter and its permitted values defined in The 'c' (content) parameter and its permitted values defined in
[I-D.ietf-core-comi] can be used to retrieve non-configuration data [I-D.ietf-core-comi] can be used to retrieve non-configuration data
(attack mitigation status), configuration data, or both. The DOTS (attack mitigation status), configuration data, or both. The DOTS
server may support this optional filtering capability. It can safely server may support this optional filtering capability. It can safely
ignore it if not supported. ignore it if not supported.
The following examples illustrate how a DOTS client retrieves active The following examples illustrate how a DOTS client retrieves active
mitigation requests from a DOTS server. In particular: mitigation requests from a DOTS server. In particular:
o Figure 11 shows the example of a GET request to retrieve all DOTS o Figure 10 shows the example of a GET request to retrieve all DOTS
mitigation requests signaled by a DOTS client. mitigation requests signaled by a DOTS client.
o Figure 12 shows the example of a GET request to retrieve a o Figure 11 shows the example of a GET request to retrieve a
specific DOTS mitigation request signaled by a DOTS client. The specific DOTS mitigation request signaled by a DOTS client. The
configuration data to be reported in the response is formatted in configuration data to be reported in the response is formatted in
the same order as was processed by the DOTS server in the original the same order as was processed by the DOTS server in the original
mitigation request. mitigation request.
These two examples assume the default of "c=a"; that is, the DOTS These two examples assume the default of "c=a"; that is, the DOTS
client asks for all data to be reported by the DOTS server. client asks for all data to be reported by the DOTS server.
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Host: "host" Uri-Host: "host"
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"
Uri-Query: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Observe: 0 Observe: 0
Figure 11: GET to Retrieve all DOTS Mitigation Requests Figure 10: GET to Retrieve all DOTS Mitigation Requests
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Host: "host" Uri-Host: "host"
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"
Uri-Query: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Query: "mid=12332" Uri-Path: "mid=12332"
Observe: 0 Observe: 0
Figure 12: GET to Retrieve a Specific DOTS Mitigation Request Figure 11: GET to Retrieve a Specific DOTS Mitigation Request
Figure 13 shows a response example of all active mitigation requests Figure 12 shows a response example of all active mitigation requests
associated with the DOTS client as maintained by the DOTS server. associated with the DOTS client as maintained by the DOTS server.
The response indicates the mitigation status of each mitigation The response indicates the mitigation status of each mitigation
request. request.
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"mid": 12332, "mid": 12332,
"mitigation-start": 1507818434, "mitigation-start": 1507818434,
skipping to change at page 26, line 46 skipping to change at page 28, line 46
"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 13: Response Body to a Get Request Figure 12: Response Body to a Get Request
The mitigation status parameters are described below: The mitigation status parameters are described below:
mitigation-start: Mitigation start time is expressed in seconds mitigation-start: Mitigation start time is expressed 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 CBOR encoding is modified so that the leading tag [RFC7049]). The CBOR encoding is modified so that the leading tag
1 (epoch-based date/time) MUST be omitted. 1 (epoch-based date/time) MUST be omitted.
This is a mandatory attribute. This is a mandatory attribute.
skipping to change at page 28, line 10 skipping to change at page 30, line 10
the mitigation request since the attack mitigation is triggered. the mitigation request since the attack mitigation is triggered.
This SHOULD be a five-minute average. This SHOULD be a five-minute average.
This is an optional attribute. This is an optional attribute.
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Parameter | Description | | Parameter | Description |
| Value | | | Value | |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 1 | Attack mitigation is in progress (e.g., changing the | | 1 | Attack mitigation is in progress (e.g., changing the |
| | network path to re-route the inbound traffic to DOTS | | | network path to redirect the inbound traffic to a |
| | mitigator). | | | DOTS mitigator). |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 2 | Attack is successfully mitigated (e.g., traffic is | | 2 | Attack is successfully mitigated (e.g., traffic is |
| | redirected to a DDoS mitigator and attack traffic is | | | redirected to a DDoS mitigator and attack traffic is |
| | dropped). | | | dropped). |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 3 | Attack has stopped and the DOTS client can withdraw | | 3 | Attack has stopped and the DOTS client can withdraw |
| | the mitigation request. | | | the mitigation request. |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 4 | Attack has exceeded the mitigation provider | | 4 | Attack has exceeded the mitigation provider |
| | capability. | | | capability. |
skipping to change at page 29, line 49 skipping to change at page 31, line 49
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 sends the next notification, the DOTS client will not DOTS server sends the next notification, the DOTS client will not
recognize the token in the message and thus will return a Reset 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 itself by Alternatively, the DOTS client can explicitly deregister itself by
issuing a GET request that has the Token field set to the token of issuing a GET request that has the Token field set to the token of
the observation to be cancelled and includes an Observe Option with the observation to be cancelled and includes an Observe Option with
the value set to '1' (deregister). the value set to '1' (deregister).
Figure 14 shows an example of a DOTS client requesting a DOTS server Figure 13 shows an example of a DOTS client requesting a DOTS server
to send notifications related to a given mitigation request. to send notifications related to a given mitigation request.
+-----------+ +-----------+ +-----------+ +-----------+
|DOTS client| |DOTS server| |DOTS client| |DOTS server|
+-----------+ +-----------+ +-----------+ +-----------+
| | | |
| GET /<mid> | | GET /<mid> |
| Token: 0x4a | Registration | Token: 0x4a | Registration
| Observe: 0 | | Observe: 0 |
+---------------------------------->| +---------------------------------->|
skipping to change at page 30, line 33 skipping to change at page 32, line 33
| status: "mitigation complete" | | status: "mitigation 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 14: Notifications of Attack Mitigation Status Figure 13: Notifications of Attack Mitigation Status
4.4.2.1. DOTS Clients Polling for Mitigation Status 4.4.2.1. DOTS Clients Polling for 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 in mitigation status SHOULD follow the transmission guidelines in
Section 3.1.3 of [RFC8085]. Section 3.1.3 of [RFC8085].
skipping to change at page 31, line 11 skipping to change at page 33, line 11
information sent by the DOTS server rather than acknowledging by information sent by the DOTS server rather than acknowledging by
itself, using its own means, that the attack has been mitigated. itself, using its own means, that the attack has been mitigated.
This ensures that the DOTS client does not recall a mitigation This ensures that the DOTS client does not recall a mitigation
request prematurely because it is possible that the DOTS client does request prematurely because it is possible that the DOTS client does
not sense the DDoS attack on its resources, but the DOTS server could not sense the DDoS attack on its resources, but the DOTS server could
be actively mitigating the attack because the attack is not be actively mitigating the attack because the attack is not
completely averted. completely averted.
4.4.3. 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 in progress, 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 is used efficacy updates to the relevant DOTS server. A PUT request is used
to convey the mitigation efficacy update to the DOTS server. to convey the mitigation efficacy update to the DOTS server.
The PUT request used for efficacy update MUST include all the The PUT request used for efficacy update MUST include all the
parameters used in the PUT request to carry the DOTS mitigation parameters used in the PUT request to carry the DOTS mitigation
request (Section 4.4.1) unchanged apart from the 'lifetime' parameter request (Section 4.4.1) unchanged apart from the 'lifetime' parameter
value. If this is not the case, the DOTS server MUST reject the value. If this is not the case, the DOTS server MUST reject the
request with a 4.00 (Bad Request). request with a 4.00 (Bad Request).
skipping to change at page 31, line 36 skipping to change at page 33, line 36
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 'mid' in the Match Option is present in the PUT request and the 'mid' in the
request matches a mitigation request from that DOTS client, the request matches a mitigation request from that DOTS client, the
request is processed by the DOTS server. If no match is found, the request is processed by the DOTS server. If no match is found, the
PUT request is silently ignored by the DOTS server. PUT request is silently ignored by the DOTS server.
An example of an efficacy update message, which includes an If-Match An example of an efficacy update message, which includes an If-Match
Option with an empty value, is depicted in Figure 15. Option with an empty value, is depicted in Figure 14.
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: "v1" Uri-Path: "v1"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
Content-Format: "application/cbor" Content-Format: "application/cbor"
skipping to change at page 32, line 47 skipping to change at page 34, line 47
"alias-name": [ "alias-name": [
"string" "string"
], ],
"lifetime": integer, "lifetime": integer,
"attack-status": integer "attack-status": integer
} }
] ]
} }
} }
Figure 15: Efficacy Update Figure 14: Efficacy Update
The 'attack-status' parameter is a mandatory attribute when The 'attack-status' parameter is a mandatory attribute when
performing an efficacy update. The various possible values contained performing an efficacy update. The various possible values contained
in the 'attack-status' parameter are described in Table 3. in the '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 |
skipping to change at page 33, line 29 skipping to change at page 35, line 29
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 4.4.4. Withdraw a Mitigation
DELETE requests are used to withdraw DOTS mitigation requests from DELETE requests are used to withdraw DOTS mitigation requests from
DOTS servers (Figure 16). DOTS servers (Figure 15).
'cuid' and 'mid' are mandatory Uri-Query parameters for DELETE 'cuid' and 'mid' are mandatory Uri-Path parameters for DELETE
requests. requests.
The same considerations for manipulating 'cdid' parameter by DOTS The same considerations for manipulating 'cdid' parameter by DOTS
gateways, as specified in Section 4.4.1, MUST be followed for DELETE gateways, as specified in Section 4.4.1, MUST be followed for DELETE
requests. Uri-Query parameters with empty values MUST NOT be present requests. Uri-Path parameters with empty values MUST NOT be present
in a request. in a request.
Header: DELETE (Code=0.04) Header: DELETE (Code=0.04)
Uri-Host: "host" Uri-Host: "host"
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"
Uri-Query: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Query: "mid=123" Uri-Path: "mid=123"
Figure 16: Withdraw a DOTS Mitigation Figure 15: Withdraw a DOTS Mitigation
If the DELETE request does not include 'cuid' and 'mid' parameters, If the DELETE request does not include 'cuid' and 'mid' parameters,
the DOTS server MUST reply with a 4.00 (Bad Request). the DOTS server MUST reply with a 4.00 (Bad Request).
Once the request is validated, the DOTS server immediately Once the request is validated, the DOTS server immediately
acknowledges a DOTS client's request to withdraw the DOTS signal acknowledges a DOTS client's request to withdraw the DOTS signal
using 2.02 (Deleted) response code with no response payload. A 2.02 using 2.02 (Deleted) response code with no response payload. A 2.02
(Deleted) Response Code is returned even if the 'mid' parameter value (Deleted) Response Code is returned even if the 'mid' parameter value
conveyed in the DELETE request does not exist in its configuration conveyed in the DELETE request does not exist in its configuration
data before the request. data before the request.
skipping to change at page 34, line 30 skipping to change at page 36, line 30
(Section 4.4.2). (Section 4.4.2).
The initial active-but-terminating period SHOULD be sufficiently long The initial active-but-terminating period SHOULD be sufficiently long
to absorb latency incurred by route propagation. The active-but- to absorb latency incurred by route propagation. The active-but-
terminating period SHOULD be set by default to 120 seconds. If the terminating period SHOULD be set by default to 120 seconds. If the
client requests mitigation again before the initial active-but- client requests mitigation again before the initial active-but-
terminating period elapses, the DOTS server MAY exponentially terminating period elapses, the DOTS server MAY exponentially
increase the active-but-terminating period up to a maximum of 300 increase the active-but-terminating period up to a maximum of 300
seconds (5 minutes). seconds (5 minutes).
After the active-but-terminating period elapses, the DOTS server MUST Once the active-but-terminating period elapses, the DOTS server MUST
treat the mitigation as terminated, as the DOTS client is no longer treat the mitigation as terminated, as the DOTS client is no longer
responsible for the mitigation. For example, if there is a financial responsible for the mitigation. For example, if there is a financial
relationship between the DOTS client and server domains, the DOTS relationship between the DOTS client and server domains, the DOTS
client stops incurring cost at this point. client stops incurring cost at this point.
4.5. DOTS Signal Channel Session Configuration 4.5. DOTS Signal Channel Session Configuration
A DOTS client can negotiate, configure, and retrieve the DOTS signal A DOTS client can negotiate, configure, and retrieve the DOTS signal
channel session behavior with its DOTS peers. The DOTS signal channel session behavior with its DOTS peers. The DOTS signal
channel can be used, for example, to configure the following: channel can be used, for example, to configure the following:
skipping to change at page 35, line 48 skipping to change at page 37, line 48
message is explained in Section 2.2 of [RFC7252]. When the response message is explained in Section 2.2 of [RFC7252]. When the response
is ready, the server sends it in a new Confirmable message which in is ready, the server sends it in a new Confirmable message which in
turn needs to be acknowledged by the DOTS client (see Sections 5.2.1 turn needs to be acknowledged by the DOTS client (see Sections 5.2.1
and 5.2.2 of [RFC7252]). Requests and responses exchanged between and 5.2.2 of [RFC7252]). Requests and responses exchanged between
DOTS agents during peacetime are marked as Confirmable messages. DOTS agents during peacetime are marked as Confirmable messages.
Implementation Note: A DOTS client that receives a response in a Implementation Note: A DOTS client that receives a response in a
CON message may want to clean up the message state right after CON message may want to clean up the message state right after
sending the ACK. If that ACK is lost and the DOTS server sending the ACK. If that ACK is lost and the DOTS server
retransmits the CON, the DOTS client may no longer have any state retransmits the CON, the DOTS client may no longer have any state
that would help it correlate this response, thereby unexpecting that would help it correlate this response: from the DOTS client's
the retransmission message. The DOTS client will send a Reset standpoint, the retransmission message is unexpected. The DOTS
message so it does not receive any more retransmissions. This client will send a Reset message so it does not receive any more
behavior is normal and not an indication of an error (see retransmissions. This behavior is normal and not an indication of
Section 5.3.2 of [RFC7252] for more details). an error (see Section 5.3.2 of [RFC7252] for more details).
4.5.1. Discover Configuration Parameters 4.5.1. Discover Configuration Parameters
A GET request is used to obtain acceptable (e.g., minimum and maximum A GET request is used to obtain acceptable (e.g., minimum and maximum
values) and current configuration parameters on the DOTS server for values) and current configuration parameters on the DOTS server for
DOTS signal channel session configuration. This procedure occurs DOTS signal channel session configuration. This procedure occurs
between a DOTS client and its immediate peer DOTS server. As such, between a DOTS client and its immediate peer DOTS server. As such,
this GET request MUST NOT be relayed by an on-path DOTS gateway. this GET request MUST NOT be relayed by an on-path DOTS gateway.
Figure 17 shows how to obtain acceptable configuration parameters for Figure 16 shows how to obtain acceptable configuration parameters for
the DOTS server. the DOTS server.
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Host: "host" Uri-Host: "host"
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"
Figure 17: GET to Retrieve Configuration Figure 16: GET to Retrieve Configuration
The DOTS server in the 2.05 (Content) response conveys the current, The DOTS server in the 2.05 (Content) response conveys the current,
minimum, and maximum attribute values acceptable by the DOTS server minimum, and maximum attribute values acceptable by the DOTS server
(Figure 18). (Figure 17).
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"ietf-dots-signal-channel:signal-config": { "ietf-dots-signal-channel:signal-config": {
"mitigating-config": { "mitigating-config": {
"heartbeat-interval": { "heartbeat-interval": {
"max-value": integer, "max-value": integer,
"min-value": integer, "min-value": integer,
"current-value": integer "current-value": integer
}, },
skipping to change at page 36, line 49 skipping to change at page 38, line 49
"max-value": integer, "max-value": integer,
"min-value": integer, "min-value": integer,
"current-value": integer "current-value": integer
}, },
"max-retransmit": { "max-retransmit": {
"max-value": integer, "max-value": integer,
"min-value": integer, "min-value": integer,
"current-value": integer "current-value": integer
}, },
"ack-timeout": { "ack-timeout": {
"max-value": integer, "max-value-decimal": number,
"min-value": integer, "min-value-decimal": number,
"current-value": integer "current-value-decimal": number
}, },
"ack-random-factor": { "ack-random-factor": {
"max-value-decimal": number, "max-value-decimal": number,
"min-value-decimal": number, "min-value-decimal": number,
"current-value-decimal": number "current-value-decimal": number
} }
}, },
"idle-config": { "idle-config": {
"heartbeat-interval": { "heartbeat-interval": {
"max-value": integer, "max-value": integer,
skipping to change at page 37, line 27 skipping to change at page 39, line 27
"max-value": integer, "max-value": integer,
"min-value": integer, "min-value": integer,
"current-value": integer "current-value": integer
}, },
"max-retransmit": { "max-retransmit": {
"max-value": integer, "max-value": integer,
"min-value": integer, "min-value": integer,
"current-value": integer "current-value": integer
}, },
"ack-timeout": { "ack-timeout": {
"max-value": integer, "max-value-decimal": number,
"min-value": integer, "min-value-decimal": number,
"current-value": integer "current-value-decimal": number
}, },
"ack-random-factor": { "ack-random-factor": {
"max-value-decimal": number, "max-value-decimal": number,
"min-value-decimal": number, "min-value-decimal": number,
"current-value-decimal": number "current-value-decimal": number
} }
}, },
"trigger-mitigation": boolean, "trigger-mitigation": boolean
"config-interval": integer
} }
} }
Figure 18: GET Configuration Response Body Figure 17: GET Configuration Response Body
The parameters in Figure 18 are described below: The parameters in Figure 17 are described below:
mitigation-config: Set of configuration parameters to use when a mitigating-config: Set of configuration parameters to use when a
mitigation is active. The following parameters may be included: mitigation is active. The following parameters may be included:
heartbeat-interval: Time interval in seconds between two heartbeat-interval: Time interval in seconds between two
consecutive heartbeat messages. consecutive heartbeat messages.
'0' is used to disable the heartbeat mechanism. '0' is used to disable the heartbeat mechanism.
This is an optional attribute. This is an optional attribute.
missing-hb-allowed: Maximum number of consecutive heartbeat missing-hb-allowed: Maximum number of consecutive heartbeat
skipping to change at page 38, line 48 skipping to change at page 40, line 46
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]. discussed in Section 3.3.3 of [I-D.ietf-dots-architecture].
If the DOTS client ceases to respond to heartbeat messages, the If the DOTS client ceases to respond to heartbeat messages, the
DOTS server can detect that the DOTS session is lost. DOTS server can detect that the DOTS session is lost.
The default value of the parameter is 'true'. The default value of the parameter is 'true'.
This is an optional attribute. This is an optional attribute.
config-interval: This parameter is returned to indicate the time Figure 18 shows an example of acceptable and current configuration
interval expressed in seconds, which a DOTS agent must wait for
before re-contacting its peer in order to retrieve the signal
channel configuration data. This parameter is only valid for a
GET response. It MUST NOT be used in a PUT request.
'0' is used to disable this configuration refresh mechanism.
If a non-zero value of 'config-interval' is received by a DOTS
client, it has to issue a PUT request to refresh the configuration
parameters for the signal channel before the expiry of 'config-
interval'. When a DDoS attack is active, refresh requests MUST
NOT be sent by DOTS clients and the DOTS server MUST NOT terminate
the (D)TLS session after the expiry of 'config-interval'.
This mechanism allows updating the configuration data if a change
occurs at the DOTS server side. For example, the new
configuration may instruct a DOTS client to cease heartbeats or
reduce heartbeat frequency.
If this parameter is not returned, this is equivalent to receiving
a 'config-interval' value set to '0'.
If a DOTS server detects that a misbehaving DOTS client does not
contact the DOTS server after the expiry of 'config-interval', in
order to retrieve the signal channel configuration data, it MAY
terminate the (D)TLS session. A (D)TLS session is terminated by
the receipt of an authenticated message that closes the connection
(e.g., a fatal alert (Section 7.2 of [RFC5246])).
This is an optional attribute.
Figure 19 shows an example of acceptable and current configuration
parameters on a DOTS server for DOTS signal channel session parameters on a DOTS server for DOTS signal channel session
configuration. The same acceptable configuration is used during configuration. The same acceptable configuration is used during
attack and peace times. attack and peace times.
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
"ietf-dots-signal-channel:signal-config": { "ietf-dots-signal-channel:signal-config": {
"mitigating-config": { "mitigating-config": {
"heartbeat-interval": { "heartbeat-interval": {
"max-value": 240, "max-value": 240,
skipping to change at page 40, line 7 skipping to change at page 41, line 22
"max-value": 9, "max-value": 9,
"min-value": 3, "min-value": 3,
"current-value": 5 "current-value": 5
}, },
"max-retransmit": { "max-retransmit": {
"max-value": 15, "max-value": 15,
"min-value": 2, "min-value": 2,
"current-value": 3 "current-value": 3
}, },
"ack-timeout": { "ack-timeout": {
"max-value": 30, "max-value-decimal": 30,
"min-value": 1, "min-value-decimal": 1,
"current-value": 2 "current-value-decimal": 2
}, },
"ack-random-factor": { "ack-random-factor": {
"max-value-decimal": 4.0, "max-value-decimal": 4.0,
"min-value-decimal": 1.1, "min-value-decimal": 1.1,
"current-value-decimal": 1.5 "current-value-decimal": 1.5
} }
}, },
"idle-config": { "idle-config": {
"heartbeat-interval": { "heartbeat-interval": {
"max-value": 240, "max-value": 240,
skipping to change at page 40, line 34 skipping to change at page 41, line 49
"max-value": 9, "max-value": 9,
"min-value": 3, "min-value": 3,
"current-value": 5 "current-value": 5
}, },
"max-retransmit": { "max-retransmit": {
"max-value": 15, "max-value": 15,
"min-value": 2, "min-value": 2,
"current-value": 3 "current-value": 3
}, },
"ack-timeout": { "ack-timeout": {
"max-value": 30, "max-value-decimal": 30,
"min-value": 1, "min-value-decimal": 1,
"current-value": 2 "current-value-decimal": 2
}, },
"ack-random-factor": { "ack-random-factor": {
"max-value-decimal": 4.0, "max-value-decimal": 4.0,
"min-value-decimal": 1.1, "min-value-decimal": 1.1,
"current-value-decimal": 1.5 "current-value-decimal": 1.5
} }
}, },
"trigger-mitigation": true, "trigger-mitigation": true
"config-interval": 3600
} }
} }
Figure 19: Example of a Configuration Response Body Figure 18: Example of a 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 41, line 30 skipping to change at page 42, line 43
seconds and should use longer intervals when possible. seconds and should use longer intervals when possible.
Furthermore, [RFC4787] recommends NATs to use a state timeout of 2 Furthermore, [RFC4787] recommends NATs to use a state timeout of 2
minutes or longer, but experience shows that sending packets every minutes or longer, but experience shows that sending packets every
15 to 30 seconds is necessary to prevent the majority of 15 to 30 seconds is necessary to prevent the majority of
middleboxes from losing state for UDP flows. From that middleboxes from losing state for UDP flows. From that
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 seconds may be seen as too chatty in A heartbeat-interval of 30 seconds may be considered as too chatty
some deployments. For such deployments, DOTS agents may negotiate in some deployments. For such deployments, DOTS agents may
longer heartbeat-interval values to prevent any network overload negotiate longer heartbeat-interval values to prevent any network
with too frequent keepalives. overload with too frequent keepalives.
Different heartbeat intervals can be defined for 'mitigation- Different heartbeat intervals can be defined for 'mitigating-
config' and 'idle-config' to reduce being too chatty during idle config' and 'idle-config' to reduce being too chatty during idle
times. If there is an on-path translator between the DOTS client times. If there is an on-path translator between the DOTS client
(standalone or part of a DOTS gateway) and the DOTS server, the (standalone or part of a DOTS gateway) and the DOTS server, the
'mitigation-config' heartbeat-interval has to be smaller than the 'mitigating-config' heartbeat-interval has to be smaller than the
translator session timeout. It is recommended that the 'idle- translator session timeout. It is recommended that the 'idle-
config' heartbeat-interval is also smaller than the translator config' heartbeat-interval is also smaller than the translator
session timeout to prevent translator transversal issues, or set session timeout to prevent translator transversal issues, or set
to '0'. Means to discover the lifetime assigned by a translator to '0'. Means to discover the lifetime assigned by a translator
are out of scope. are out of scope.
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" is retransmitted max-retransmit number of times by the "CoAP Ping" is retransmitted max-retransmit number of times 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
skipping to change at page 42, line 39 skipping to change at page 44, line 4
"ietf-dots-signal-channel:signal-config": { "ietf-dots-signal-channel:signal-config": {
"mitigating-config": { "mitigating-config": {
"heartbeat-interval": { "heartbeat-interval": {
"current-value": integer "current-value": integer
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
"current-value": integer "current-value": integer
}, },
"max-retransmit": { "max-retransmit": {
"current-value": integer "current-value": integer
}, },
"ack-timeout": { "ack-timeout": {
"current-value": integer "current-value-decimal": number
}, },
"ack-random-factor": { "ack-random-factor": {
"current-value-decimal": number "current-value-decimal": number
} }
}, },
"idle-config": { "idle-config": {
"heartbeat-interval": { "heartbeat-interval": {
"current-value": integer "current-value": integer
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
"current-value": integer "current-value": integer
}, },
"max-retransmit": { "max-retransmit": {
"current-value": integer "current-value": integer
}, },
"ack-timeout": { "ack-timeout": {
"current-value": integer "current-value-decimal": number
}, },
"ack-random-factor": { "ack-random-factor": {
"current-value-decimal": number "current-value-decimal": number
} }
}, },
"trigger-mitigation": boolean "trigger-mitigation": boolean
} }
} }
Figure 20: PUT to Convey the DOTS Signal Channel Session Figure 19: PUT to Convey the DOTS Signal Channel Session
Configuration Data Configuration Data
The additional Uri-Path parameter to those defined in Table 1 is as The additional Uri-Path parameter to those defined in Table 1 is as
follows: follows:
sid: Session Identifier is an identifier for the DOTS signal channel sid: Session Identifier is an identifier for the DOTS signal channel
session configuration data represented as an integer. This session configuration data represented as an integer. This
identifier MUST be generated by DOTS clients. This document does identifier MUST be generated by DOTS clients. 'sid' values MUST
not make any assumption about how this identifier is generated. increase monotonically.
This is a mandatory attribute. This is a mandatory attribute.
The meaning of the parameters in the CBOR body is defined in The meaning of the parameters in the CBOR body is defined in
Section 4.5.1. Section 4.5.1.
At least one of the attributes 'heartbeat-interval', 'missing-hb- At least one of the attributes 'heartbeat-interval', 'missing-hb-
allowed', 'max-retransmit', 'ack-timeout', 'ack-random-factor', and allowed', 'max-retransmit', 'ack-timeout', 'ack-random-factor', and
'trigger-mitigation' MUST be present in the PUT request. 'trigger-mitigation' MUST be present in the PUT request. Note that
'heartbeat-interval', 'missing-hb-allowed', 'max-retransmit', 'ack-
timeout', and 'ack-random-factor', if present, do not need to be
provided for both 'mitigating-config', and 'idle-config' in a PUT
request.
The PUT request with a higher numeric 'sid' value overrides the DOTS The PUT request with a higher numeric 'sid' value overrides the DOTS
signal channel session configuration data installed by a PUT request signal channel session configuration data installed by a PUT request
with a lower numeric 'sid' value. To avoid maintaining a long list with a lower numeric 'sid' value. To avoid maintaining a long list
of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be
automatically deleted and no longer available at the DOTS server. automatically deleted and no longer available at the DOTS server.
Figure 21 shows a PUT request example to convey the configuration Figure 20 shows a PUT request example to convey the configuration
parameters for the DOTS signal channel. In this example, heartbeat parameters for the DOTS signal channel. In this example, the
mechanism is disabled when no mitigation is active, while the heartbeat mechanism is disabled when no mitigation is active, while
heartbeat interval is set to '91' when a mitigation is active. the heartbeat interval is set to '91' when a mitigation is active.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Host: "www.example.com" Uri-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"
Uri-Path: "sid=123" Uri-Path: "sid=123"
Content-Format: "application/cbor" Content-Format: "application/cbor"
{ {
skipping to change at page 44, line 26 skipping to change at page 46, line 26
"heartbeat-interval": { "heartbeat-interval": {
"current-value": 91 "current-value": 91
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
"current-value": 3 "current-value": 3
}, },
"max-retransmit": { "max-retransmit": {
"current-value": 7 "current-value": 7
}, },
"ack-timeout": { "ack-timeout": {
"current-value": 5 "current-value-decimal": 5
}, },
"ack-random-factor": { "ack-random-factor": {
"current-value-decimal": 1.5 "current-value-decimal": 1.5
} }
}, },
"idle-config": { "idle-config": {
"heartbeat-interval": { "heartbeat-interval": {
"current-value": 0 "current-value": 0
}, },
"max-retransmit": { "max-retransmit": {
"current-value": 7 "current-value": 7
}, },
"ack-timeout": { "ack-timeout": {
"current-value": 5 "current-value-decimal": 5
}, },
"ack-random-factor": { "ack-random-factor": {
"current-value-decimal": 1.5 "current-value-decimal": 1.5
} }
}, },
"trigger-mitigation": false "trigger-mitigation": false
} }
} }
Figure 21: PUT to Convey the Configuration Parameters Figure 20: 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 request is missing a mandatory attribute, does not include o If the request is missing a mandatory attribute, does not include
a 'sid' Uri-Path, or contains one or more invalid or unknown a 'sid' Uri-Path, or contains one or more invalid or unknown
parameters, 4.00 (Bad Request) MUST be returned in the response. parameters, 4.00 (Bad Request) MUST be returned in the response.
o If the DOTS server does not find the 'sid' parameter value o If the DOTS server does not find the 'sid' 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
skipping to change at page 45, line 33 skipping to change at page 47, line 33
retransmit', 'target-protocol', 'ack-timeout', and 'ack-random- 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,
4.22 (Unprocessable Entity) MUST be returned in the response. 4.22 (Unprocessable Entity) MUST be returned in the response.
Upon receipt of this error code, the DOTS client SHOULD request Upon receipt of this error code, the DOTS client SHOULD request
the maximum and minimum attribute values acceptable to the DOTS the maximum and minimum attribute values acceptable to the DOTS
server (Section 4.5.1). server (Section 4.5.1).
The DOTS client may re-try and send the PUT request with updated The DOTS client may re-try and send the PUT request with updated
attribute values acceptable to the DOTS server. attribute values acceptable to the DOTS server.
4.5.3. Delete DOTS Signal Channel Session Configuration 4.5.3. Configuration Freshness and Notifications
Max-Age Option (Section 5.10.5 of [RFC7252]) SHOULD be returned by a
DOTS server to associate a validity time with a configuration it
sends. This feature allows the update of the configuration data if a
change occurs at the DOTS server side. For example, the new
configuration may instruct a DOTS client to cease heartbeats or
reduce heartbeat frequency.
It is NOT RECOMMENDED to return a Max-Age Option set to 0.
Returning a Max-Age Option set to 2**32-1 is equivalent to
associating an infinite lifetime with the configuration.
If a non-zero value of Max-Age Option is received by a DOTS client,
it MUST issue a PUT request to refresh the configuration parameters
for the signal channel before the expiry of the value enclosed in the
Max-Age option. When a DDoS attack is active, refresh requests MUST
NOT be sent by DOTS clients and the DOTS server MUST NOT terminate
the (D)TLS session after the expiry of the value returned in Max-Age
Option.
If Max-Age Option is not returned in a response, DOTS servers should
expect to receive PUT requests to refresh the configuration
parameters each 60 seconds (Section 5.10.5 of [RFC7252]). To prevent
such overload, it is RECOMMENDED that DOTS servers return a Max-Age
Option in GET responses. Considerations related to which value to
use and how such value is set, are implementation- and deployment-
specific.
If an Observe Option set to 0 is included in the configuration
request, the DOTS server sends notifications of any configuration
change (Section 4.2 of [RFC7641]).
If a DOTS server detects that a misbehaving DOTS client does not
contact the DOTS server after the expiry of Max-Age, in order to
retrieve the signal channel configuration data, it MAY terminate the
(D)TLS session. A (D)TLS session is terminated by the receipt of an
authenticated message that closes the connection (e.g., a fatal alert
(Section 7.2 of [RFC5246])).
4.5.4. Delete DOTS Signal Channel Session Configuration
A DELETE request is used to delete the installed DOTS signal channel A DELETE request is used to delete the installed DOTS signal channel
session configuration data (Figure 22). session configuration data (Figure 21).
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: "v1" Uri-Path: "v1"
Uri-Path: "config" Uri-Path: "config"
Uri-Query: "sid=123" Uri-Path: "sid=123"
Figure 22: DELETE Configuration Figure 21: DELETE Configuration
The DOTS server resets the DOTS signal channel session configuration The DOTS server resets the DOTS signal channel session configuration
back to the default values and acknowledges a DOTS client's request back to the default values and acknowledges a DOTS client's request
to remove the DOTS signal channel session configuration using 2.02 to remove the DOTS signal channel session configuration using 2.02
(Deleted) response code. (Deleted) response code.
Upon bootsrapping or reboot, a DOTS client MAY send a DELETE request Upon bootsrapping or reboot, a DOTS client MAY send a DELETE request
to set the configuration parameters to default values. Such a to set the configuration parameters to default values. Such a
request does not include any 'sid'. request does not include any 'sid'.
skipping to change at page 46, line 26 skipping to change at page 49, line 22
(alternate server) will be returned in the response to the DOTS (alternate server) will be returned in the response to the DOTS
client. 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's FQDN, and the alternate DOTS server's IP address(es) and server's FQDN, and the alternate DOTS server's IP address(es) and
time to live values in the CBOR body (Figure 23). time to live values in the CBOR body (Figure 22).
{ {
"ietf-dots-signal-channel:redirected-signal": { "ietf-dots-signal-channel:redirected-signal": {
"alt-server": "string", "alt-server": "string",
"alt-server-record": [ "alt-server-record": [
{ {
"addr": "string", "addr": "string",
"ttl" : integer "ttl" : integer
} }
] ]
} }
} }
Figure 23: Redirected Server Error Response Body Figure 22: Redirected Server 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 24 shows a 3.00 response example to convey the DOTS alternate Figure 23 shows a 3.00 response example to convey the DOTS alternate
server 'alt-server.example', 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.
{ {
"ietf-dots-signal-channel:redirected-signal": { "ietf-dots-signal-channel:redirected-signal": {
"alt-server": "alt-server.example", "alt-server": "alt-server.example",
"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 24: Example of Redirected Server Error Response Body Figure 23: Example of Redirected Server 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 failed, but SHOULD try re-sending the request to the request as failed, but SHOULD try re-sending the request to 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
the target of another DDoS attack, alternate DOTS server's IP the target of another DDoS attack, alternate DOTS server's IP
addresses conveyed in the 3.00 response help the DOTS client skip DNS addresses conveyed in the 3.00 response help the DOTS client skip DNS
lookup of the alternate DOTS server. The DOTS client can then try to lookup of the alternate DOTS server. The DOTS client can then try to
establish a UDP or a TCP session with the alternate DOTS server. The establish a UDP or a TCP session with the alternate DOTS server. The
DOTS client SHOULD implement a DNS64 function to handle the scenario DOTS client SHOULD implement a DNS64 function to handle the scenario
where an IPv6-only DOTS client communicates with an IPv4-only where an IPv6-only DOTS client communicates with an IPv4-only
skipping to change at page 48, line 48 skipping to change at page 51, line 48
reached, the DOTS server concludes the session is disconnected. reached, the DOTS server concludes the session is disconnected.
In DOTS over UDP, heartbeat messages MUST be exchanged between the In DOTS over UDP, heartbeat messages MUST 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 a Reset message and the peer DOTS agent will respond by sending a Reset
message. message.
In DOTS over TCP, heartbeat messages MUST be exchanged between the In DOTS over TCP, heartbeat messages MUST 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 [RFC8323]. That is, the DOTS agent sends a Ping message and the
Ping message and the peer DOTS agent would respond by sending a peer DOTS agent would respond by sending a single Pong message.
single Pong message.
5. DOTS Signal Channel YANG Module 5. DOTS Signal Channel YANG Module
This document defines a YANG [RFC7950] module for mitigation scope This document defines a YANG [RFC7950] module for mitigation scope
and DOTS signal channel session configuration data. and DOTS signal channel session configuration data.
This YANG module defines the DOTS client interaction with the DOTS This YANG module defines the DOTS client interaction with the DOTS
server as seen by the DOTS client. A DOTS server is allowed to server as seen by the DOTS client. A DOTS server is allowed to
update the non-configurable 'ro' entities in the responses. This update the non-configurable 'ro' entities in the responses. This
YANG module is not intended to be used for DOTS servers management YANG module is not intended to be used for DOTS server management
purposes. Such module is out of the scope of this document. purposes. Such module is out of the scope of this document.
5.1. Tree Structure 5.1. Tree Structure
This document defines the YANG module "ietf-dots-signal-channel" This document defines the YANG module "ietf-dots-signal-channel"
(Section 5.2), which has the following tree structure. A DOTS signal (Section 5.2), which has the following tree structure. A DOTS signal
message can either be a mitigation or a configuration message. message can either be a mitigation or a configuration message.
module: ietf-dots-signal-channel module: ietf-dots-signal-channel
+--rw dots-signal +--rw dots-signal
+--rw (message-type)? +--rw (message-type)?
+--:(mitigation-scope) +--:(mitigation-scope)
| +--rw cdid? string
| +--rw scope* [cuid mid] | +--rw scope* [cuid mid]
| +--rw cdid? string
| +--rw cuid string | +--rw cuid string
| +--rw mid uint32 | +--rw mid uint32
| +--rw target-prefix* inet:ip-prefix | +--rw target-prefix* inet:ip-prefix
| +--rw target-port-range* [lower-port upper-port] | +--rw target-port-range* [lower-port upper-port]
| | +--rw lower-port inet:port-number | | +--rw lower-port inet:port-number
| | +--rw upper-port inet:port-number | | +--rw upper-port inet:port-number
| +--rw target-protocol* uint8 | +--rw target-protocol* uint8
| +--rw target-fqdn* inet:domain-name | +--rw target-fqdn* inet:domain-name
| +--rw target-uri* inet:uri | +--rw target-uri* inet:uri
| +--rw alias-name* string | +--rw alias-name* string
skipping to change at page 50, line 7 skipping to change at page 53, line 7
| | +--ro target-prefix* inet:ip-prefix | | +--ro target-prefix* inet:ip-prefix
| | +--ro target-port-range* [lower-port upper-port] | | +--ro target-port-range* [lower-port upper-port]
| | | +--ro lower-port inet:port-number | | | +--ro lower-port inet:port-number
| | | +--ro upper-port inet:port-number | | | +--ro upper-port inet:port-number
| | +--ro target-protocol* uint8 | | +--ro target-protocol* uint8
| | +--ro target-fqdn* inet:domain-name | | +--ro target-fqdn* inet:domain-name
| | +--ro target-uri* inet:uri | | +--ro target-uri* inet:uri
| | +--ro alias-name* string | | +--ro alias-name* string
| | +--ro acl-list* [acl-name] | | +--ro acl-list* [acl-name]
| | +--ro acl-name | | +--ro acl-name
| | | -> /ietf-acl:access-lists/acl/name | | | -> /ietf-acl:acls/acl/name
| | +--ro acl-type? | | +--ro acl-type?
| | -> /ietf-acl:access-lists/acl/type | | -> /ietf-acl:acls/acl/type
| +--ro bytes-dropped? yang:zero-based-counter64 | +--ro bytes-dropped? yang:zero-based-counter64
| +--ro bps-dropped? yang:zero-based-counter64 | +--ro bps-dropped? yang:zero-based-counter64
| +--ro pkts-dropped? yang:zero-based-counter64 | +--ro pkts-dropped? yang:zero-based-counter64
| +--ro pps-dropped? yang:zero-based-counter64 | +--ro pps-dropped? yang:zero-based-counter64
| +--rw attack-status? enumeration | +--rw attack-status? enumeration
+--:(signal-config) +--:(signal-config)
| +--rw sid uint32 | +--rw sid uint32
| +--rw mitigating-config | +--rw mitigating-config
| | +--rw heartbeat-interval | | +--rw heartbeat-interval
| | | +--ro max-value? uint16 | | | +--ro max-value? uint16
skipping to change at page 50, line 31 skipping to change at page 53, line 31
| | | +--rw current-value? uint16 | | | +--rw current-value? uint16
| | +--rw missing-hb-allowed | | +--rw missing-hb-allowed
| | | +--ro max-value? uint16 | | | +--ro max-value? uint16
| | | +--ro min-value? uint16 | | | +--ro min-value? uint16
| | | +--rw current-value? uint16 | | | +--rw current-value? uint16
| | +--rw max-retransmit | | +--rw max-retransmit
| | | +--ro max-value? uint16 | | | +--ro max-value? uint16
| | | +--ro min-value? uint16 | | | +--ro min-value? uint16
| | | +--rw current-value? uint16 | | | +--rw current-value? uint16
| | +--rw ack-timeout | | +--rw ack-timeout
| | | +--ro max-value? uint16 | | | +--ro max-value-decimal? decimal64
| | | +--ro min-value? uint16 | | | +--ro min-value-decimal? decimal64
| | | +--rw current-value? uint16 | | | +--rw current-value-decimal? decimal64
| | +--rw ack-random-factor | | +--rw ack-random-factor
| | +--ro max-value-decimal? decimal64 | | +--ro max-value-decimal? decimal64
| | +--ro min-value-decimal? decimal64 | | +--ro min-value-decimal? decimal64
| | +--rw current-value-decimal? decimal64 | | +--rw current-value-decimal? decimal64
| +--rw idle-config | +--rw idle-config
| | +--rw heartbeat-interval | | +--rw heartbeat-interval
| | | +--ro max-value? uint16 | | | +--ro max-value? uint16
| | | +--ro min-value? uint16 | | | +--ro min-value? uint16
| | | +--rw current-value? uint16 | | | +--rw current-value? uint16
| | +--rw missing-hb-allowed | | +--rw missing-hb-allowed
| | | +--ro max-value? uint16 | | | +--ro max-value? uint16
| | | +--ro min-value? uint16 | | | +--ro min-value? uint16
| | | +--rw current-value? uint16 | | | +--rw current-value? uint16
| | +--rw max-retransmit | | +--rw max-retransmit
| | | +--ro max-value? uint16 | | | +--ro max-value? uint16
| | | +--ro min-value? uint16 | | | +--ro min-value? uint16
| | | +--rw current-value? uint16 | | | +--rw current-value? uint16
| | +--rw ack-timeout | | +--rw ack-timeout
| | | +--ro max-value? uint16 | | | +--ro max-value-decimal? decimal64
| | | +--ro min-value? uint16 | | | +--ro min-value-decimal? decimal64
| | | +--rw current-value? uint16 | | | +--rw current-value-decimal? decimal64
| | +--rw ack-random-factor | | +--rw ack-random-factor
| | +--ro max-value-decimal? decimal64 | | +--ro max-value-decimal? decimal64
| | +--ro min-value-decimal? decimal64 | | +--ro min-value-decimal? decimal64
| | +--rw current-value-decimal? decimal64 | | +--rw current-value-decimal? decimal64
| +--rw trigger-mitigation? boolean | +--rw trigger-mitigation? boolean
| +--ro config-interval? uint32
+--:(redirected-signal) +--:(redirected-signal)
+--ro alt-server string +--ro alt-server string
+--ro alt-server-record* [addr] +--ro alt-server-record* [addr]
+--ro addr inet:ip-address +--ro addr inet:ip-address
+--ro ttl? uint32 +--ro ttl? uint32
5.2. YANG Module 5.2. YANG Module
<CODE BEGINS> file "ietf-dots-signal-channel@2018-01-23.yang" <CODE BEGINS> file "ietf-dots-signal-channel@2018-03-15.yang"
module ietf-dots-signal-channel { module ietf-dots-signal-channel {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel"; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel";
prefix signal; prefix signal;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
import ietf-yang-types { import ietf-yang-types {
skipping to change at page 52, line 27 skipping to change at page 55, line 27
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 2018-01-23 { revision 2018-03-15 {
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 Specification";
} }
/* /*
* Groupings * Groupings
*/ */
grouping target { grouping target {
description description
"Specifies the targets of the mitigation request."; "Specifies the targets of the mitigation request.";
leaf-list target-prefix { leaf-list target-prefix {
skipping to change at page 53, line 48 skipping to change at page 56, line 48
leaf-list target-uri { leaf-list target-uri {
type inet:uri; type inet:uri;
description description
"URI identifying the target."; "URI identifying the target.";
} }
} }
grouping mitigation-scope { grouping mitigation-scope {
description description
"Specifies the scope of the mitigation request."; "Specifies the scope of the mitigation request.";
leaf cdid {
type string;
description
"The cdid should be included by a server-domain
DOTS gateway to propagate the client domain
identification information from the
gateway's client-facing-side to the gateway's
server-facing-side, and from the gateway's
server-facing-side to the DOTS server.
It may be used by the final DOTS server
for policy enforcement purposes.";
}
list scope { list scope {
key "cuid mid"; key "cuid mid";
description description
"The scope of the request."; "The scope of the request.";
leaf cdid {
type string;
description
"The cdid should be included by a server-domain
DOTS gateway to propagate the client domain
identification information from the
gateway's client-facing-side to the gateway's
server-facing-side, and from the gateway's
server-facing-side to the DOTS server.
It may be used by the final DOTS server
for policy enforcement purposes.";
}
leaf cuid { leaf cuid {
type string; type string;
description description
"A unique identifier that is randomly "A unique identifier that is randomly
generated by a DOTS client to prevent generated by a DOTS client to prevent
request collisions. It is expected that the request collisions. It is expected that the
cuid will remain consistent throughout the cuid will remain consistent throughout the
lifetime of the DOTS client."; lifetime of the DOTS client.";
} }
leaf mid { leaf mid {
skipping to change at page 58, line 15 skipping to change at page 61, line 15
} }
list acl-list { list acl-list {
when "../../conflict-cause = 'conflict-with-whitelist'"; when "../../conflict-cause = 'conflict-with-whitelist'";
key "acl-name"; key "acl-name";
description description
"List of conflicting ACLs as defined in the DOTS data "List of conflicting ACLs as defined in the DOTS data
channel. These ACLs are uniquely defined by channel. These ACLs are uniquely defined by
cuid and acl-name."; cuid and acl-name.";
leaf acl-name { leaf acl-name {
type leafref { type leafref {
path "/ietf-acl:access-lists/ietf-acl:acl/" + path "/ietf-acl:acls/ietf-acl:acl/" +
"ietf-acl:name"; "ietf-acl:name";
} }
description description
"Reference to the conflicting ACL name bound to "Reference to the conflicting ACL name bound to
a DOTS client."; a DOTS client.";
} }
leaf acl-type { leaf acl-type {
type leafref { type leafref {
path "/ietf-acl:access-lists/ietf-acl:acl/" + path "/ietf-acl:acls/ietf-acl:acl/" +
"ietf-acl:type"; "ietf-acl:type";
} }
description description
"Reference to the conflicting ACL type bound to "Reference to the conflicting ACL type bound to
a DOTS client."; a DOTS client.";
} }
} }
} }
} }
leaf bytes-dropped { leaf bytes-dropped {
skipping to change at page 61, line 30 skipping to change at page 64, line 30
leaf current-value { leaf current-value {
type uint16; type uint16;
default "3"; default "3";
description description
"Current max-retransmit value."; "Current max-retransmit value.";
} }
} }
container ack-timeout { container ack-timeout {
description description
"Initial retransmission timeout value."; "Initial retransmission timeout value.";
leaf max-value { leaf max-value-decimal {
type uint16; type decimal64 {
fraction-digits 2;
}
units "seconds"; units "seconds";
config false; config false;
description description
"Maximum ack-timeout value."; "Maximum ack-timeout value.";
} }
leaf min-value { leaf min-value-decimal {
type uint16; type decimal64 {
fraction-digits 2;
}
units "seconds"; units "seconds";
config false; config false;
description description
"Minimum ack-timeout value."; "Minimum ack-timeout value.";
} }
leaf current-value { leaf current-value-decimal {
type uint16; type decimal64 {
fraction-digits 2;
}
units "seconds"; units "seconds";
default "2"; default "2";
description description
"Current ack-timeout value."; "Current ack-timeout value.";
} }
} }
container ack-random-factor { container ack-random-factor {
description description
"Random factor used to influence the timing of "Random factor used to influence the timing of
retransmissions."; retransmissions.";
skipping to change at page 63, line 16 skipping to change at page 66, line 22
is active."; is active.";
uses config-parameters; uses config-parameters;
} }
leaf trigger-mitigation { leaf trigger-mitigation {
type boolean; type boolean;
default "true"; default "true";
description description
"If false, then mitigation is triggered "If false, then mitigation is triggered
only when the DOTS server channel session is lost."; only when the DOTS server channel session is lost.";
} }
leaf config-interval {
type uint32;
units "seconds";
default "3600";
config false;
description
"This parameter is returned by a DOTS server to
a requesting DOTS client to indicate the time interval
after which the DOTS client must contact the DOTS
server in order to retrieve the signal channel
configuration data.
This mechanism allows the update of the configuration
data if a change occurs.
For example, the new configuration may instruct
a DOTS client to cease heartbeats or reduce
heartbeat frequency.
'0' is used to disable this refresh mechanism.";
}
} }
grouping redirected-signal { grouping redirected-signal {
description description
"Grouping for the redirected signaling."; "Grouping for the redirected signaling.";
leaf alt-server { leaf alt-server {
type string; type string;
config false; config false;
mandatory true; mandatory true;
description description
skipping to change at page 65, line 19 skipping to change at page 68, line 4
key to save space. The recipient of the payload MAY reject the key 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.
+----------------------+-------------+-----+---------------+--------+ +----------------------+-------------+-----+---------------+--------+
| Parameter Name | YANG | CBOR| CBOR Major | JSON | | Parameter Name | YANG | CBOR| CBOR Major | JSON |
| | Type | Key | Type & | Type | | | Type | Key | Type & | Type |
| | | | Information | | | | | | Information | |
+----------------------+-------------+-----+---------------+--------+ +----------------------+-------------+-----+---------------+--------+
| ietf-dots-signal-cha | | | | | | ietf-dots-signal-cha | | | | |
| nnel:mitigation-scope| container | 1 | 5 map | Object | | nnel:mitigation-scope| container | 1 | 5 map | Object |
| cdid | string | 2 | 3 text string | String | | scope | list | 2 | 4 array | Array |
| scope | list | 3 | 4 array | Array | | cdid | string | 3 | 3 text string | String |
| cuid | string | 4 | 3 text string | String | | cuid | string | 4 | 3 text string | String |
| mid | uint32 | 5 | 0 unsigned | Number | | mid | uint32 | 5 | 0 unsigned | Number |
| target-prefix | leaf-list | 6 | 4 array | Array | | target-prefix | leaf-list | 6 | 4 array | Array |
| | inet: | | | | | | inet: | | | |
| | ip-prefix | | 3 text string | String | | | ip-prefix | | 3 text string | String |
| target-port-range | list | 7 | 4 array | Array | | target-port-range | list | 7 | 4 array | Array |
| lower-port | inet: | | | | | lower-port | inet: | | | |
| | port-number| 8 | 0 unsigned | Number | | | port-number| 8 | 0 unsigned | Number |
| upper-port | inet: | | | | | upper-port | inet: | | | |
| | port-number| 9 | 0 unsigned | Number | | | port-number| 9 | 0 unsigned | Number |
skipping to change at page 66, line 37 skipping to change at page 69, line 23
| ack-random-factor | container | 40 | 5 map | Object | | ack-random-factor | container | 40 | 5 map | Object |
| max-value-decimal | decimal64 | 41 | 6 tag 4 | | | max-value-decimal | decimal64 | 41 | 6 tag 4 | |
| | | | [-2, integer]| String | | | | | [-2, integer]| String |
| min-value-decimal | decimal64 | 42 | 6 tag 4 | | | min-value-decimal | decimal64 | 42 | 6 tag 4 | |
| | | | [-2, integer]| String | | | | | [-2, integer]| String |
| current-value-decimal| decimal64 | 43 | 6 tag 4 | | | current-value-decimal| decimal64 | 43 | 6 tag 4 | |
| | | | [-2, integer]| String | | | | | [-2, integer]| String |
| idle-config | container | 44 | 5 map | Object | | idle-config | container | 44 | 5 map | Object |
| trigger-mitigation | boolean | 45 | 7 bits 20 | False | | trigger-mitigation | boolean | 45 | 7 bits 20 | False |
| | | | 7 bits 21 | True | | | | | 7 bits 21 | True |
| config-interval | uint32 | 46 | 0 unsigned | Number |
| ietf-dots-signal-cha | | | | | | ietf-dots-signal-cha | | | | |
|nnel:redirected-signal| container | 47 | 5 map | Object | |nnel:redirected-signal| container | 46 | 5 map | Object |
| alt-server | string | 48 | 3 text string | String | | alt-server | string | 47 | 3 text string | String |
| alt-server-record | list | 49 | 4 array | Array | | alt-server-record | list | 48 | 4 array | Array |
| addr | inet: | | | | | addr | inet: | | | |
| | ip-address | 50 | 3 text string | String | | | ip-address | 49 | 3 text string | String |
| ttl | uint32 | 51 | 0 unsigned | Number | | ttl | uint32 | 50 | 0 unsigned | Number |
+----------------------+-------------+-----+---------------+--------+ +----------------------+-------------+-----+---------------+--------+
Table 4: CBOR Mappings Used in DOTS Signal Channel Messages Table 4: CBOR Mappings Used in DOTS Signal Channel Messages
7. (D)TLS Protocol Profile and Performance Considerations 7. (D)TLS Protocol Profile and Performance Considerations
7.1. (D)TLS Protocol Profile 7.1. (D)TLS Protocol Profile
This section defines the (D)TLS protocol profile of DOTS signal This section defines the (D)TLS protocol profile of DOTS signal
channel over (D)TLS and DOTS data channel over TLS. channel over (D)TLS and DOTS data channel over TLS.
skipping to change at page 69, line 16 skipping to change at page 71, line 49
to convey the DOTS mitigation request message and, if there is no to convey the DOTS mitigation request message and, if there is no
response from the server after multiple retries, the DOTS client response from the server after multiple retries, the DOTS client
can resume the (D)TLS session in 0-RTT mode using PSK. can resume the (D)TLS session in 0-RTT mode using PSK.
Section 8 of [I-D.ietf-tls-tls13] discusses some mechanisms to Section 8 of [I-D.ietf-tls-tls13] discusses some mechanisms to
implement to limit the impact of replay attacks on 0-RTT data. If implement to limit the impact of replay attacks on 0-RTT data. If
TLS1.3 is used, DOTS servers must implement one of these TLS1.3 is used, DOTS servers must implement one of these
mechanisms. mechanisms.
A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request
message exchange is shown in Figure 25. message exchange is shown in Figure 24.
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 25: TLS 1.3 handshake with 0-RTT Figure 24: TLS 1.3 handshake with 0-RTT
7.3. MTU and Fragmentation 7.3. MTU and Fragmentation
To avoid DOTS signal message fragmentation and the subsequent To avoid DOTS signal message fragmentation and the subsequent
decreased probability of message delivery, DOTS agents MUST ensure decreased probability of message delivery, DOTS agents MUST ensure
that the DTLS record MUST fit within a single datagram. If the path 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 MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD
be assumed. If UDP is used to convey the DOTS signal messages then be assumed. If UDP is used to convey the DOTS signal messages then
the DOTS client must consider the amount of record expansion expected the DOTS client must consider the amount of record expansion expected
by the DTLS processing when calculating the size of CoAP message that by the DTLS processing when calculating the size of CoAP message that
skipping to change at page 70, line 9 skipping to change at page 72, line 44
[CoAP message size + DTLS overhead of 13 octets + authentication [CoAP message size + DTLS overhead of 13 octets + authentication
overhead of the negotiated DTLS cipher suite + block padding overhead of the negotiated DTLS cipher suite + block padding
(Section 4.1.1.1 of [RFC6347]). If the request size exceeds the path (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 MTU then the DOTS client MUST split the DOTS signal into separate
messages, for example the list of addresses in the 'target-prefix' messages, for example the list of addresses in the 'target-prefix'
parameter could be split into multiple lists and each list conveyed parameter could be split into multiple lists and each list conveyed
in a new PUT request. in a new PUT request.
Implementation Note: DOTS choice of message size parameters works Implementation Note: DOTS choice of message size parameters works
well with IPv6 and with most of today's IPv4 paths. However, with well with IPv6 and with most of today's IPv4 paths. However, with
IPv4, it is harder to reliably ensure that there is no IP IPv4, it is harder to safely make sure that there is no IP
fragmentation. If IPv4 path MTU is unknown, implementations may want fragmentation. If IPv4 path MTU is unknown, implementations may want
to limit themselves to more conservative IPv4 datagram sizes such as to limit themselves to more conservative IPv4 datagram sizes such as
576 bytes, as per [RFC0791]. IP packets whose size does not exceed 576 bytes, as per [RFC0791]. IP packets whose size does not exceed
576 bytes should never need to be fragmented: therefore, sending a 576 bytes should never need to be fragmented: therefore, sending a
maximum of 500 bytes of DOTS signal over a UDP datagram will maximum of 500 bytes of DOTS signal over a UDP datagram will
generally avoid IP fragmentation. generally avoid IP fragmentation.
8. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients 8. Mutual Authentication of DOTS Agents & Authorization of DOTS Clients
(D)TLS based upon client certificate can be used for mutual (D)TLS based upon client certificate can be used for mutual
skipping to change at page 71, line 28 skipping to change at page 73, line 49
| +--------------+ | | | | | | +--------------+ | | | | |
| +----+--------+ | +---------------+ | +----+--------+ | +---------------+
| ^ | | ^ |
| | | | | |
| +----------------+ | | | +----------------+ | |
| | DDoS detector | | | | | DDoS detector | | |
| | (DOTS client) +<---------------+ | | | (DOTS client) +<---------------+ |
| +----------------+ | | +----------------+ |
+-----------------------------------------------+ +-----------------------------------------------+
Figure 26: Example of Authentication and Authorization of DOTS Agents Figure 25: Example of Authentication and Authorization of DOTS Agents
In the example depicted in Figure 26, the DOTS gateway and DOTS In the example depicted in Figure 25, the DOTS gateway and DOTS
clients within the 'example.com' domain mutually authenticate with clients within the 'example.com' domain mutually authenticate. After
each other. After the DOTS gateway validates the identity of a DOTS the DOTS gateway validates the identity of a DOTS client, it
client, it communicates with the AAA server in the 'example.com' communicates with the AAA server in the 'example.com' domain to
domain to determine if the DOTS client is authorized to request DDoS 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 attack detector to request DDoS mitigation, but does not permit DDoS attack detector to request DDoS mitigation, but does not permit
the user of type 'guest' to request DDoS mitigation. the user of type 'guest' to request DDoS mitigation.
Also, DOTS gateways and servers located in different domains MUST Also, DOTS gateways and servers 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 26, the DOTS server only allows the DOTS gateway reference to Figure 25, 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.
9. IANA Considerations 9. IANA Considerations
This specification registers a service port (Section 9.1), a URI This specification registers a service port (Section 9.1), a URI
suffix in the Well-Known URIs registry (Section 9.2), a CoAP response suffix in the Well-Known URIs registry (Section 9.2), a CoAP response
code (Section 9.3), a YANG module (Section 9.5). It also creates a code (Section 9.3), a YANG module (Section 9.6). It also creates a
registry for mappings to CBOR (Section 9.4). registry for mappings to CBOR (Section 9.5).
9.1. DOTS Signal Channel UDP and TCP Port Number 9.1. DOTS Signal Channel UDP and TCP Port Number
IANA is requested to assign the port number TBD to the DOTS signal IANA is requested to assign the port number TBD to the DOTS signal
channel protocol for both UDP and TCP from the "Service Name and channel protocol for both UDP and TCP from the "Service Name and
Transport Protocol Port Number Registry" available at Transport Protocol Port Number Registry" available at
https://www.iana.org/assignments/service-names-port-numbers/service- https://www.iana.org/assignments/service-names-port-numbers/service-
names-port-numbers.xhtml. names-port-numbers.xhtml.
The assignment of port number 4646 is strongly suggested, as 4646 is The assignment of port number 4646 is strongly suggested, as 4646 is
skipping to change at page 72, line 40 skipping to change at page 75, line 16
| URI | Change | Specification | Related | | URI | Change | Specification | Related |
| suffix | controller | document(s) | information | | suffix | controller | document(s) | information |
+----------+----------------+---------------------+-----------------+ +----------+----------------+---------------------+-----------------+
| dots | IETF | [RFCXXXX] | None | | dots | IETF | [RFCXXXX] | None |
+----------+----------------+---------------------+-----------------+ +----------+----------------+---------------------+-----------------+
Table 5: 'dots' well-known URI Table 5: 'dots' well-known URI
9.3. CoAP Response Code 9.3. CoAP Response Code
IANA is requested to add the following entry to the "CoAP Response IANA is requested to add the following entries to the "CoAP Response
Codes" sub-registry available at https://www.iana.org/assignments/ Codes" sub-registry available at https://www.iana.org/assignments/
core-parameters/core-parameters.xhtml#response-codes: core-parameters/core-parameters.xhtml#response-codes:
+------+------------------+-----------+ +------+------------------+-----------+
| Code | Description | Reference | | Code | Description | Reference |
+------+------------------+-----------+ +------+------------------+-----------+
| 3.00 | Alternate Server | [RFCXXXX] | | 3.00 | Alternate Server | [RFCXXXX] |
| 5.06 | Hop Limit Reached| [RFCXXXX] |
+------+------------------+-----------+ +------+------------------+-----------+
Table 6: CoAP Response Code Table 6: CoAP Response Codes
9.4. DOTS Signal Channel CBOR Mappings Registry 9.4. CoAP Option Number
IANA is requested to add the following entry to the "CoAP Option
Numbers" sub-registry available at https://www.iana.org/assignments/
core-parameters/core-parameters.xhtml#option-numbers:
+--------+------------------+-----------+
| Number | Name | Reference |
+--------+------------------+-----------+
| 2 | Hop-Limit | [RFCXXXX] |
+--------+------------------+-----------+
Table 7: CoAP Option Number
9.5. DOTS Signal Channel CBOR Mappings Registry
The document requests IANA to create a new registry, entitled "DOTS The document requests IANA to create a new registry, entitled "DOTS
Signal Channel CBOR Mappings Registry". The structure of this Signal Channel CBOR Mappings Registry". The structure of this
registry is provided in Section 9.4.1. registry is provided in Section 9.5.1.
The registry is initially populated with the values in Section 9.4.2. The registry is initially populated with the values in Section 9.5.2.
Values from that registry MUST be assigned via Expert Review Values from that registry MUST be assigned via Expert Review
[RFC8126]. [RFC8126].
9.4.1. Registration Template 9.5.1. Registration Template
Parameter name: Parameter name:
Parameter name as used in the DOTS signal channel. Parameter name as used in the DOTS signal channel.
CBOR Key Value: CBOR Key Value:
Key value for the parameter. The key value MUST be an integer in Key value for the parameter. The key value MUST be an integer in
the 1-65536 range. The key values in the 32758-65536 range are the 1-65535 range. The key values in the 32768-65535 range are
assigned to Vendor-Specific parameters. assigned to Vendor-Specific parameters.
CBOR Major Type: CBOR Major Type:
CBOR Major type and optional tag for the claim. CBOR Major type and optional tag for the claim.
Change Controller: Change Controller:
For Standards Track RFCs, list the "IESG". For others, give the For Standards Track RFCs, list the "IESG". For others, give the
name of the responsible party. Other details (e.g., postal name of the responsible party. Other details (e.g., postal
address, email address, home page URI) may also be included. address, email address, home page URI) may also be included.
Specification Document(s): Specification Document(s):
Reference to the document or documents that specify the parameter, Reference to the document or documents that specify the parameter,
preferably including URIs that can be used to retrieve copies of preferably including URIs that can be used to retrieve copies of
the documents. An indication of the relevant sections may also be the documents. An indication of the relevant sections may also be
included but is not required. included but is not required.
9.4.2. Initial Registry Content 9.5.2. Initial Registry Content
+----------------------+-------+-------+------------+---------------+ +----------------------+-------+-------+------------+---------------+
| Parameter Name | CBOR | CBOR | Change | Specification | | Parameter Name | CBOR | CBOR | Change | Specification |
| | Key | Major | Controller | Document(s) | | | Key | Major | Controller | Document(s) |
| | Value | Type | | | | | Value | Type | | |
+----------------------+-------+-------+------------+---------------+ +----------------------+-------+-------+------------+---------------+
| ietf-dots-signal-chan| 1 | 5 | IESG | [RFCXXXX] | | ietf-dots-signal-chan| 1 | 5 | IESG | [RFCXXXX] |
| nel:mitigation-scope | | | | | | nel:mitigation-scope | | | | |
| cdid | 2 | 3 | IESG | [RFCXXXX] | | scope | 2 | 4 | IESG | [RFCXXXX] |
| scope | 3 | 4 | IESG | [RFCXXXX] | | cdid | 3 | 3 | IESG | [RFCXXXX] |
| cuid | 4 | 3 | IESG | [RFCXXXX] | | cuid | 4 | 3 | IESG | [RFCXXXX] |
| mid | 5 | 0 | IESG | [RFCXXXX] | | mid | 5 | 0 | IESG | [RFCXXXX] |
| target-prefix | 6 | 4 | IESG | [RFCXXXX] | | target-prefix | 6 | 4 | IESG | [RFCXXXX] |
| target-port-range | 7 | 4 | IESG | [RFCXXXX] | | target-port-range | 7 | 4 | IESG | [RFCXXXX] |
| lower-port | 8 | 0 | IESG | [RFCXXXX] | | lower-port | 8 | 0 | IESG | [RFCXXXX] |
| upper-port | 9 | 0 | IESG | [RFCXXXX] | | upper-port | 9 | 0 | IESG | [RFCXXXX] |
| target-protocol | 10 | 4 | IESG | [RFCXXXX] | | target-protocol | 10 | 4 | IESG | [RFCXXXX] |
| target-fqdn | 11 | 4 | IESG | [RFCXXXX] | | target-fqdn | 11 | 4 | IESG | [RFCXXXX] |
| target-uri | 12 | 4 | IESG | [RFCXXXX] | | target-uri | 12 | 4 | IESG | [RFCXXXX] |
| alias-name | 13 | 4 | IESG | [RFCXXXX] | | alias-name | 13 | 4 | IESG | [RFCXXXX] |
skipping to change at page 74, line 46 skipping to change at page 77, line 35
| missing-hb-allowed | 37 | 5 | IESG | [RFCXXXX] | | missing-hb-allowed | 37 | 5 | IESG | [RFCXXXX] |
| max-retransmit | 38 | 5 | IESG | [RFCXXXX] | | max-retransmit | 38 | 5 | IESG | [RFCXXXX] |
| ack-timeout | 39 | 5 | IESG | [RFCXXXX] | | ack-timeout | 39 | 5 | IESG | [RFCXXXX] |
| ack-random-factor | 40 | 5 | IESG | [RFCXXXX] | | ack-random-factor | 40 | 5 | IESG | [RFCXXXX] |
| min-value-decimal | 41 | 6tag4 | IESG | [RFCXXXX] | | min-value-decimal | 41 | 6tag4 | IESG | [RFCXXXX] |
| max-value-decimal | 42 | 6tag4 | IESG | [RFCXXXX] | | max-value-decimal | 42 | 6tag4 | IESG | [RFCXXXX] |
| current-value- | 43 | 6tag4 | IESG | [RFCXXXX] | | current-value- | 43 | 6tag4 | IESG | [RFCXXXX] |
| decimal | | | | | | decimal | | | | |
| idle-config | 44 | 5 | IESG | [RFCXXXX] | | idle-config | 44 | 5 | IESG | [RFCXXXX] |
| trigger-mitigation | 45 | 7 | IESG | [RFCXXXX] | | trigger-mitigation | 45 | 7 | IESG | [RFCXXXX] |
| config-interval | 46 | 0 | IESG | [RFCXXXX] | | ietf-dots-signal-chan| 46 | 5 | IESG | [RFCXXXX] |
| ietf-dots-signal-chan| 47 | 5 | IESG | [RFCXXXX] |
| nel:redirected-signal| | | | | | nel:redirected-signal| | | | |
| alt-server | 48 | 3 | IESG | [RFCXXXX] | | alt-server | 47 | 3 | IESG | [RFCXXXX] |
| alt-server-record | 49 | 4 | IESG | [RFCXXXX] | | alt-server-record | 48 | 4 | IESG | [RFCXXXX] |
| addr | 50 | 3 | IESG | [RFCXXXX] | | addr | 49 | 3 | IESG | [RFCXXXX] |
| ttl | 51 | 0 | IESG | [RFCXXXX] | | ttl | 50 | 0 | IESG | [RFCXXXX] |
+----------------------+-------+-------+------------+---------------+ +----------------------+-------+-------+------------+---------------+
Table 7: Initial DOTS Signal Channel CBOR Mappings Registry Table 8: Initial DOTS Signal Channel CBOR Mappings Registry
9.5. DOTS Signal Channel YANG Module 9.6. DOTS Signal Channel YANG Module
This document requests IANA to register the following URI 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-channel URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel
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.
This document requests IANA to register the following YANG module in This document requests IANA to register the following YANG module 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-channel namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel
prefix: signal prefix: signal
reference: RFC XXXX reference: RFC XXXX
10. Implementation Status 10. Security Considerations
[Note to RFC Editor: Please remove this section and reference to
[RFC7942] prior to publication.]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting this
Internet-Draft, and is based upon a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision-making process when progressing
drafts to RFCs. Please note that the listing of any individual
implementation here does not imply endorsement by the IETF.
Furthermore, no effort has been spent to verify the information
presented here, and which was provided by individuals. This is not
intended as, and must not be construed to be, a catalog of available
implementations or features. Readers are advised to note that other
implementations may exist.
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
10.1. nttdots
Organization: NTT Communication is developing a DOTS client and
DOTS server software based on DOTS signal channel specified in
this draft. It will be open-sourced.
Description: Early implementation of DOTS protocol. It is aimed to
implement a full DOTS protocol specification in accordance with
the nurturing DOTS protocol.
Implementation: https://github.com/nttdots/go-dots
Level of maturity: It is an early implementation of the DOTS
protocol. Messaging between DOTS clients and DOTS servers has
been tested. Level of maturity will increase in accordance with
the nurturing DOTS protocol.
Coverage: Capability of DOTS client: sending DOTS messages to the
DOTS server in CoAP over DTLS as dots-signal. Capability of DOTS
server: receiving dots-signal, validating received dots-signal,
starting mitigation by handing over the dots-signal to DDoS
mitigator.
Licensing: It will be open-sourced with BSD 3-clause license.
Implementation experience: It is implemented in Go-lang. Core
specification of signaling is mature to be implemented, however,
finding good libraries(like DTLS, CoAP) is rather difficult.
Contact: Kaname Nishizuka <kaname@nttv6.jp>
11. Security Considerations
Authenticated encryption MUST be used for data confidentiality and Authenticated encryption MUST be used for data confidentiality and
message integrity. The interaction between the DOTS agents requires message integrity. The interaction between the DOTS agents requires
Datagram Transport Layer Security (DTLS) and Transport Layer Security Datagram Transport Layer Security (DTLS) and Transport Layer Security
(TLS) with a cipher suite offering confidentiality protection and the (TLS) with a cipher suite offering confidentiality protection and the
guidance given in [RFC7525] MUST be followed to avoid attacks on guidance given in [RFC7525] MUST be followed to avoid attacks on
(D)TLS. The (D)TLS protocol profile for DOTS signal channel is (D)TLS. The (D)TLS protocol profile for DOTS signal channel is
specified in Section 7. specified in Section 7.
A single DOTS signal channel between DOTS agents can be used to A single DOTS signal channel between DOTS agents can be used to
skipping to change at page 77, line 22 skipping to change at page 79, line 5
result in varying the 'cuid' to exhaust DOTS server resources. Rate- result in varying the 'cuid' to exhaust DOTS server resources. Rate-
limit policies SHOULD be enforced on DOTS gateways (if deployed) and limit policies SHOULD be enforced on DOTS gateways (if deployed) and
DOTS servers. DOTS servers.
In order to prevent leaking internal information outside a client- In order to prevent leaking internal information outside a client-
domain, DOTS gateways located in the client-domain SHOULD NOT reveal domain, DOTS gateways located in the client-domain SHOULD NOT reveal
the identification information that pertains to internal DOTS clients the identification information that pertains to internal DOTS clients
(e.g., source IP address, client's hostname) unless explicitly (e.g., source IP address, client's hostname) unless explicitly
configured to do so. configured to do so.
Special care should be taken in order to ensure that the activation DOTS servers MUST verify that requesting DOTS clients are entitled to
of the proposed mechanism will not impact the stability of the trigger actions on a given IP prefix. That is, only actions on IP
network (including connectivity and services delivered over that resources that belong to the DOTS client' domain MUST be authorized
network). by a DOTS server. The exact mechanism for the DOTS servers to
validate that the target prefixes are within the scope of the DOTS
client's domain is deployment-specific.
12. Contributors 11. Contributors
The following individuals have contributed to this document: The following individuals have contributed to this document:
o Mike Geller, Cisco Systems, Inc. 3250 Florida 33309 USA, Email: o Mike Geller, Cisco Systems, Inc. 3250 Florida 33309 USA, Email:
mgeller@cisco.com mgeller@cisco.com
o Robert Moskowitz, HTT Consulting Oak Park, MI 42837 United States, o Robert Moskowitz, HTT Consulting Oak Park, MI 42837 United States,
Email: rgm@htt-consult.com Email: rgm@htt-consult.com
o Dan Wing, Email: dwing-ietf@fuggles.com o Dan Wing, Email: dwing-ietf@fuggles.com
o Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.trust o Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.trust
13. Acknowledgements 12. Acknowledgements
Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw, Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw,
Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang
Xia, Gilbert Clark, and Nesredien Suleiman for the discussion and Xia, Gilbert Clark, and Nesredien Suleiman for the discussion and
comments. comments.
Special thanks to Jon Shallow for the careful reviews and inputs that Special thanks to Jon Shallow for the careful reviews and inputs that
enhanced this specification. enhanced this specification.
14. References 13. References
14.1. Normative References
[I-D.ietf-core-coap-tcp-tls] 13.1. Normative References
Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
draft-ietf-core-coap-tcp-tls-11 (work in progress),
December 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,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 78, line 46 skipping to change at page 80, line 21
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010, DOI 10.17487/RFC5785, April 2010,
<https://www.rfc-editor.org/info/rfc5785>. <https://www.rfc-editor.org/info/rfc5785>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
skipping to change at page 80, line 15 skipping to change at page 81, line 30
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[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>.
14.2. Informative References [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>.
13.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-02 (work in Management Interface", draft-ietf-core-comi-02 (work in
progress), December 2017. progress), December 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-06 (work in progress), February
2017. 2018.
[I-D.ietf-dots-architecture] [I-D.ietf-dots-architecture]
Mortensen, A., Andreasen, F., Reddy, T., Mortensen, A., Andreasen, F., Reddy, T.,
christopher_gray3@cable.comcast.com, c., Compton, R., and christopher_gray3@cable.comcast.com, c., Compton, R., and
N. Teague, "Distributed-Denial-of-Service Open Threat N. Teague, "Distributed-Denial-of-Service Open Threat
Signaling (DOTS) Architecture", draft-ietf-dots- Signaling (DOTS) Architecture", draft-ietf-dots-
architecture-05 (work in progress), October 2017. architecture-06 (work in progress), March 2018.
[I-D.ietf-dots-data-channel] [I-D.ietf-dots-data-channel]
Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil, Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil,
P., Mortensen, A., and N. Teague, "Distributed Denial-of- P., Mortensen, A., and N. Teague, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Data Channel", draft- Service Open Threat Signaling (DOTS) Data Channel
ietf-dots-data-channel-11 (work in progress), December Specification", draft-ietf-dots-data-channel-13 (work in
2017. progress), January 2018.
[I-D.ietf-dots-requirements] [I-D.ietf-dots-requirements]
Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed
Denial of Service (DDoS) Open Threat Signaling Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-10 (work in Requirements", draft-ietf-dots-requirements-14 (work in
progress), January 2018. progress), February 2018.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
Open Threat Signaling", draft-ietf-dots-use-cases-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]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-04 (work in progress),
December 2017.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-22 (work in progress), 1.3", draft-ietf-tls-dtls13-26 (work in progress), March
November 2017. 2018.
[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-23 (work in progress), Version 1.3", draft-ietf-tls-tls13-27 (work in progress),
January 2018. March 2018.
[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>.
[RFC1983] Malkin, G., Ed., "Internet Users' Glossary", FYI 18, [RFC1983] Malkin, G., Ed., "Internet Users' Glossary", FYI 18,
skipping to change at page 82, line 33 skipping to change at page 84, line 5
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/info/rfc5389>. <https://www.rfc-editor.org/info/rfc5389>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>. April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
<https://www.rfc-editor.org/info/rfc6296>. <https://www.rfc-editor.org/info/rfc6296>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
skipping to change at page 84, line 10 skipping to change at page 85, line 33
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
Authors' Addresses Authors' Addresses
Tirumaleswar Reddy (editor) Tirumaleswar Reddy (editor)
McAfee, Inc. McAfee, Inc.
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore, Karnataka 560071 Bangalore, Karnataka 560071
India India
Email: kondtir@gmail.com Email: kondtir@gmail.com
Mohamed Boucadair (editor) Mohamed Boucadair (editor)
Orange Orange
Rennes 35000 Rennes 35000
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Prashanth Patil Prashanth Patil
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 156 change blocks. 
406 lines changed or deleted 405 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/