< draft-ietf-dots-signal-channel-25.txt   draft-ietf-dots-signal-channel-26.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: March 9, 2019 Orange Expires: June 24, 2019 Orange
P. Patil P. Patil
Cisco Cisco
A. Mortensen A. Mortensen
Arbor Networks, Inc. Arbor Networks, Inc.
N. Teague N. Teague
Verisign, Inc. Verisign, Inc.
September 5, 2018 December 21, 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-25 draft-ietf-dots-signal-channel-26
Abstract Abstract
This document specifies the DOTS signal channel, a protocol for This document specifies the DOTS signal channel, a protocol for
signaling the need for protection against Distributed Denial-of- signaling the need for protection against Distributed Denial-of-
Service (DDoS) attacks to a server capable of enabling network Service (DDoS) attacks to a server capable of enabling network
traffic mitigation on behalf of the requesting client. traffic mitigation on behalf of the requesting client.
A companion document defines the DOTS data channel, a separate A companion document defines the DOTS data channel, a separate
reliable communication layer for DOTS management and configuration reliable communication layer for DOTS management and configuration
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 Specification"; (DOTS) Signal Channel Specification";
o "| [RFCXXXX] |" o "| [RFCXXXX] |"
o reference: RFC XXXX o reference: RFC XXXX
Please update this statement with the RFC number to be assigned to
the following documents:
o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Data Channel Specification (used to be
[I-D.ietf-dots-data-channel])
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. Also, please update the "revision" date of the YANG modules.
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 March 9, 2019. This Internet-Draft will expire on June 24, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6
4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 8 4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 9
4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 8 4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 9
4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 9 4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 9
4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 11 4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 11
4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 11 4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 12
4.4.2. Retrieve Information Related to a Mitigation . . . . 26 4.4.2. Retrieve Information Related to a Mitigation . . . . 27
4.4.2.1. DOTS Servers Sending Mitigation Status . . . . . 30 4.4.2.1. DOTS Servers Sending Mitigation Status . . . . . 31
4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 33 4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 34
4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 34 4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 35
4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 36 4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 37
4.5. DOTS Signal Channel Session Configuration . . . . . . . . 38
4.5. DOTS Signal Channel Session Configuration . . . . . . . . 37 4.5.1. Discover Configuration Parameters . . . . . . . . . . 40
4.5.1. Discover Configuration Parameters . . . . . . . . . . 39 4.5.2. Convey DOTS Signal Channel Session Configuration . . 44
4.5.2. Convey DOTS Signal Channel Session Configuration . . 43 4.5.3. Configuration Freshness and Notifications . . . . . . 49
4.5.3. Configuration Freshness and Notifications . . . . . . 48 4.5.4. Delete DOTS Signal Channel Session Configuration . . 50
4.5.4. Delete DOTS Signal Channel Session Configuration . . 49 4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 51
4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 50 4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 53
4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 52 5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 54
5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . . . 53 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 54
5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 53 5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 56
5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 55 5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 60
6. Mapping Parameters to CBOR . . . . . . . . . . . . . . . . . 69 6. Mapping Parameters to CBOR . . . . . . . . . . . . . . . . . 70
7. (D)TLS Protocol Profile and Performance Considerations . . . 71 7. (D)TLS Protocol Profile and Performance Considerations . . . 72
7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 71 7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 72
7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 72 7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 74
7.3. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 73 7.3. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 75
8. Mutual Authentication of DOTS Agents & Authorization of DOTS 8. Mutual Authentication of DOTS Agents & Authorization of DOTS
Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78
9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 76 9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 78
9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 76 9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 78
9.3. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 76 9.3. Media Type Registration . . . . . . . . . . . . . . . . . 78
9.3.1. Registration Template . . . . . . . . . . . . . . . . 77 9.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 78
9.3.2. Initial Registry Content . . . . . . . . . . . . . . 78 9.4. CoAP Content-Formats Registration . . . . . . . . . . . . 79
9.4. Media Type Registration . . . . . . . . . . . . . . . . . 79
9.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 79 9.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 79
9.5. CoAP Content-Formats Registration . . . . . . . . . . . . 80 9.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 79
9.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 80 9.5.1. Registry Contents . . . . . . . . . . . . . . . . . . 80
9.6. CBOR Tag registration . . . . . . . . . . . . . . . . . . 80 9.6. DOTS Signal Channel Protocol Registry . . . . . . . . . . 80
9.6.1. Registry Contents . . . . . . . . . . . . . . . . . . 80 9.6.1. DOTS Signal Channel CBOR Mappings Sub-Registry . . . 80
9.7. DOTS Signal Channel YANG Module . . . . . . . . . . . . . 81 9.6.1.1. Registration Template . . . . . . . . . . . . . . 81
10. Security Considerations . . . . . . . . . . . . . . . . . . . 81 9.6.1.2. Initial Sub-Registry Content . . . . . . . . . . 81
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 82 9.6.2. Status Codes Sub-Registry . . . . . . . . . . . . . . 83
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 82 9.6.3. Conflict Status Codes Sub-Registry . . . . . . . . . 84
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 82 9.6.4. Conflict Cause Codes Sub-Registry . . . . . . . . . . 86
13.1. Normative References . . . . . . . . . . . . . . . . . . 82 9.6.5. Attack Status Codes Sub-Registry . . . . . . . . . . 86
13.2. Informative References . . . . . . . . . . . . . . . . . 85 9.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 88
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 89
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 90
13.1. Normative References . . . . . . . . . . . . . . . . . . 90
13.2. Informative References . . . . . . . . . . . . . . . . . 92
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96
1. Introduction 1. Introduction
A distributed denial-of-service (DDoS) attack is an attempt to make A distributed denial-of-service (DDoS) attack is an attempt to make
machines or network resources unavailable to their intended users. machines or network resources unavailable to their intended users.
In most cases, sufficient scale can be achieved by compromising In most cases, sufficient scale can be achieved by compromising
enough end-hosts and using those infected hosts to perpetrate and enough end-hosts and using those infected hosts to perpetrate and
amplify the attack. The victim in this attack can be an application amplify the attack. The victim in this attack can be an application
server, a host, a router, a firewall, or an entire network. server, a host, a router, a firewall, or an entire network.
skipping to change at page 5, line 44 skipping to change at page 6, line 9
This document focuses on the DOTS signal channel. This is a This document focuses on the DOTS signal channel. This is a
companion document of the DOTS data channel specification companion document of the DOTS data channel specification
[I-D.ietf-dots-data-channel] that defines a configuration and a bulk [I-D.ietf-dots-data-channel] that defines a configuration and a bulk
data exchange mechanism supporting the DOTS signal channel. data exchange mechanism supporting the DOTS signal channel.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC2119]. 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
(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][RFC8446] and Datagram Transport Layer Security Security [RFC5246][RFC8446] and Datagram Transport Layer Security
[RFC6347]. Specific terms are used for any statement that applies to [RFC6347]. Specific terms are used for any statement that applies to
either protocol alone. either 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-requirements]. [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
skipping to change at page 7, line 39 skipping to change at page 8, line 5
errors. In order to allow the use of the same data models, [RFC7951] errors. In order to allow the use of the same data models, [RFC7951]
specifies the JavaScript Object Notation (JSON) encoding of YANG- specifies the JavaScript Object Notation (JSON) encoding of YANG-
modeled data. A similar effort for CBOR is defined in modeled data. A similar effort for CBOR is defined in
[I-D.ietf-core-yang-cbor]. [I-D.ietf-core-yang-cbor].
DOTS agents determine the CBOR data structure is a DOTS signal DOTS agents determine the CBOR data structure is a DOTS signal
channel object from the application context, such as from the port channel object from the application context, such as from the port
number assigned to the DOTS signal channel. The other method DOTS number assigned to the DOTS signal channel. The other method DOTS
agents use to indicate that a CBOR data structure is a DOTS signal agents use to indicate that a CBOR data structure is a DOTS signal
channel object is the use of the "application/dots+cbor" content type channel object is the use of the "application/dots+cbor" content type
(Section 9.4). (Section 9.3).
From that standpoint, this document specifies a YANG module for From that standpoint, this document specifies a YANG module for
representing DOTS mitigation scopes, DOTS signal channel session representing DOTS mitigation scopes, DOTS signal channel session
configuration data, and DOTS redirected signalling (Section 5). configuration data, and DOTS redirected signalling (Section 5).
Representing these data as CBOR data is assumed to follow the rules Representing these data as CBOR data is assumed to follow the rules
in [I-D.ietf-core-yang-cbor] or those in [RFC7951] combined with in [I-D.ietf-core-yang-cbor] or those in [RFC7951] combined with
JSON/CBOR conversion rules in [RFC7049]. All parameters in the JSON/CBOR conversion rules in [RFC7049]. All parameters in the
payload of the DOTS signal channel are mapped to CBOR types as payload of the DOTS signal channel are mapped to CBOR types as
specified in Section 6. specified in Section 6.
skipping to change at page 9, line 22 skipping to change at page 9, line 37
The DOTS server MUST support the use of the path-prefix of "/.well- The DOTS server MUST support the use of the path-prefix of "/.well-
known/" as defined in [RFC5785] and the registered name of "dots". known/" as defined in [RFC5785] and the registered name of "dots".
Each DOTS operation is indicated by a path-suffix that indicates the Each DOTS operation is indicated by a path-suffix that indicates the
intended operation. The operation path (Table 1) is appended to the intended operation. The operation path (Table 1) is appended to the
path-prefix to form the URI used with a CoAP request to perform the path-prefix to form the URI used with a CoAP request to perform the
desired DOTS operation. desired DOTS operation.
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
| Operation | Operation Path | Details | | Operation | Operation Path | Details |
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
| Mitigation | /v1.0/mitigate | Section 4.4 | | Mitigation | /mitigate | Section 4.4 |
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
| Session configuration | /v1.0/config | Section 4.5 | | Session configuration | /config | Section 4.5 |
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
Table 1: Operations and their Corresponding URIs Table 1: Operations and their Corresponding URIs
4.3. Happy Eyeballs for DOTS Signal Channel 4.3. Happy Eyeballs for DOTS Signal Channel
[I-D.ietf-dots-requirements] mentions that DOTS agents will have to [I-D.ietf-dots-requirements] mentions that DOTS agents will have to
support both connectionless and connection-oriented protocols. As support both connectionless and connection-oriented protocols. As
such, the DOTS signal channel is designed to operate with DTLS over such, the DOTS signal channel is designed to operate with DTLS over
UDP and TLS over TCP. Further, a DOTS client may acquire a list of UDP and TLS over TCP. Further, a DOTS client may acquire a list of
skipping to change at page 11, line 37 skipping to change at page 12, line 7
not sending more than one UDP datagram per round-trip time (RTT) to not sending more than one UDP datagram per round-trip time (RTT) to
the peer DOTS agent on average. the peer DOTS agent on average.
Requests marked by the DOTS client as Non-confirmable messages are Requests marked by the DOTS client as Non-confirmable messages are
sent at regular intervals until a response is received from the DOTS sent at regular intervals until a response is received from the DOTS
server. If the DOTS client cannot maintain an RTT estimate, it server. If the DOTS client cannot maintain an RTT estimate, it
SHOULD NOT send more than one Non-confirmable request every 3 SHOULD NOT send more than one Non-confirmable request every 3
seconds, and SHOULD use an even less aggressive rate whenever seconds, and SHOULD use an even less aggressive rate whenever
possible (case 2 in Section 3.1.3 of [RFC8085]). possible (case 2 in Section 3.1.3 of [RFC8085]).
JSON diagnostic notation is used to illustrate the various methods
defined in the following sub-sections.
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).
If a DOTS client is entitled to solicit the DOTS service, the DOTS If a DOTS client is entitled to solicit the DOTS service, the DOTS
server can enable mitigation on behalf of the DOTS client by server can enable mitigation on behalf of the DOTS client by
communicating the DOTS client's request to a mitigator and relaying communicating the DOTS client's request to a mitigator and relaying
the feedback of the thus-selected mitigator to the requesting DOTS the feedback of the thus-selected mitigator to the requesting DOTS
client. client.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1.0"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
Content-Type: "application/dots+cbor" Content-Type: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"target-prefix": [ "target-prefix": [
"string" "string"
], ],
"target-port-range": [ "target-port-range": [
{ {
"lower-port": integer, "lower-port": number,
"upper-port": integer "upper-port": number
} }
], ],
"target-protocol": [ "target-protocol": [
integer number
], ],
"target-fqdn": [ "target-fqdn": [
"string" "string"
], ],
"target-uri": [ "target-uri": [
"string" "string"
], ],
"alias-name": [ "alias-name": [
"string" "string"
], ],
"lifetime": integer, "lifetime": number,
"trigger-mitigation": boolean "trigger-mitigation": true|false
} }
] ]
} }
} }
Figure 5: PUT to Convey DOTS Mitigation Requests Figure 5: PUT to Convey DOTS Mitigation Requests
The Uri-Path option carries a major and minor version nomenclature to
manage versioning; DOTS signal channel in this specification uses
'v1' major version and '0' minor version.
The order of the Uri-Path options is important as it defines the CoAP The order of the Uri-Path options is important as it defines the CoAP
resource. In particular, 'mid' MUST follow 'cuid'. resource. In particular, 'mid' MUST follow 'cuid'.
The additional Uri-Path parameters to those defined in Section 4.2 The additional Uri-Path parameters to those defined in Section 4.2
are as follows: are as follows:
cuid: Stands for Client Unique Identifier. A globally unique cuid: Stands for Client Unique Identifier. A globally unique
identifier that is meant to prevent collisions among DOTS clients, identifier that is meant to prevent collisions among DOTS clients,
especially those from the same domain. It MUST be generated by especially those from the same domain. It MUST be generated by
DOTS clients. DOTS clients.
skipping to change at page 16, line 18 skipping to change at page 17, line 16
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.
trigger-mitigation: If the parameter value is set to 'false', DDoS trigger-mitigation: If the parameter value is set to 'false', DDoS
mitigation will not be triggered for the mitigation request unless mitigation will not be triggered for the mitigation request unless
the DOTS signal channel session is lost. the DOTS signal channel session is lost.
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 signal channel session is
lost.
The default value of the parameter is 'true' (that is, the The default value of the parameter is 'true' (that is, the
mitigation starts immediately). If 'trigger-mitigation' is not mitigation starts immediately). If 'trigger-mitigation' is not
present in a request, this is equivalent to receiving a request present in a request, this is equivalent to receiving a request
with 'trigger-mitigation' set to 'true'. with 'trigger-mitigation' set to 'true'.
This is an optional attribute. This is an optional 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
skipping to change at page 17, line 8 skipping to change at page 18, line 8
requests, and identifying the mitigation scope. These policies can requests, and identifying the mitigation scope. These policies can
be enforced per-client, per-client domain, or both. Also, the be enforced per-client, per-client domain, or both. Also, the
identity information may be used for auditing and debugging purposes. identity information may be used for auditing and debugging purposes.
Figure 6 shows an example of a request relayed by a server-domain Figure 6 shows an example of a request relayed by a server-domain
DOTS gateway. DOTS gateway.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1.0"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cdid=7eeaf349529eb55ed50113" Uri-Path: "cdid=7eeaf349529eb55ed50113"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
Content-Type: "application/dots+cbor" Content-Type: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"target-prefix": [ "target-prefix": [
"string" "string"
], ],
"target-port-range": [ "target-port-range": [
{ {
"lower-port": integer, "lower-port": number,
"upper-port": integer "upper-port": number
} }
], ],
"target-protocol": [ "target-protocol": [
integer number
], ],
"target-fqdn": [ "target-fqdn": [
"string" "string"
], ],
"target-uri": [ "target-uri": [
"string" "string"
], ],
"alias-name": [ "alias-name": [
"string" "string"
], ],
"lifetime": integer "lifetime": number
} }
] ]
} }
} }
Figure 6: PUT to Convey DOTS Mitigation Request as relayed by a Figure 6: PUT to Convey DOTS Mitigation Request as relayed by a
Server-Domain DOTS Gateway Server-Domain DOTS Gateway
A server-domain DOTS gateway SHOULD add the following Uri-Path A server-domain DOTS gateway SHOULD add the following Uri-Path
parameter: parameter:
skipping to change at page 18, line 47 skipping to change at page 19, line 46
'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. When present, 'cdid' MUST be This is an optional Uri-Path. When present, 'cdid' MUST be
positioned before 'cuid'. positioned before 'cuid'.
A DOTS gateway MAY add the CoAP Hop-Limit Option A DOTS gateway MAY add the CoAP Hop-Limit Option
[I-D.boucadair-core-hop-limit]. [I-D.ietf-core-hop-limit].
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 associated with the domain name or URI 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.
skipping to change at page 20, line 8 skipping to change at page 21, line 8
Figure 7 shows a PUT request example to signal that ports 80, 8080, Figure 7 shows a PUT request example to signal that ports 80, 8080,
and 443 used by 2001:db8:6401::1 and 2001:db8:6401::2 servers are and 443 used by 2001:db8:6401::1 and 2001:db8:6401::2 servers are
under attack (illustrated in JSON diagnostic notation). The presence under attack (illustrated in JSON diagnostic notation). The presence
of 'cdid' indicates that a server-domain DOTS gateway has modified of 'cdid' indicates that a server-domain DOTS gateway has modified
the initial PUT request sent by the DOTS client. Note that 'cdid' the initial PUT request sent by the DOTS client. Note that 'cdid'
MUST NOT appear in the PUT request message body. MUST NOT appear in the PUT request message body.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1.0"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cdid=7eeaf349529eb55ed50113" Uri-Path: "cdid=7eeaf349529eb55ed50113"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"target-prefix": [ "target-prefix": [
skipping to change at page 22, line 28 skipping to change at page 23, line 28
Figure 9 shows an example response to a PUT request that is Figure 9 shows an example response to a PUT request that is
successfully processed by a DOTS server (i.e., CoAP 2.xx response successfully processed by a DOTS server (i.e., CoAP 2.xx response
codes). This version of the specification forbids 'cuid' and 'cdid' codes). This version of the specification forbids 'cuid' and 'cdid'
(if used) to be returned in a response message body. (if used) to be returned in a response message body.
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"mid": 12332, "mid": 123,
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
Figure 9: 2.xx Response Body Figure 9: 2.xx Response Body
If the request is missing a mandatory attribute, does not include If the request is missing a mandatory attribute, does not include
'cuid' or 'mid' Uri-Path options, includes multiple 'scope' 'cuid' or 'mid' Uri-Path options, includes multiple 'scope'
skipping to change at page 25, line 11 skipping to change at page 26, line 11
3: DOTS server has detected conflicting mitigation requests 3: DOTS server has detected conflicting mitigation requests
from different DOTS clients. All conflicting mitigation from different DOTS clients. All conflicting mitigation
requests are inactive. requests are inactive.
conflict-cause: Indicates the cause of the conflict. The conflict-cause: Indicates the cause of the conflict. The
following values are defined: following values are defined:
1: Overlapping targets. 'conflict-scope' provides more details 1: Overlapping targets. 'conflict-scope' provides more details
about the conflicting target clauses. about the conflicting target clauses.
2: Conflicts with an existing white list. This code is 2: Conflicts with an existing accept-list. This code is
returned when the DDoS mitigation detects source addresses/ returned when the DDoS mitigation detects source addresses/
prefixes in the white-listed ACLs are attacking the target. prefixes in the accept-listed ACLs are attacking the
target.
3: CUID Collision. This code is returned when a DOTS client 3: CUID Collision. This code is returned when a DOTS client
uses a 'cuid' that is already used by another DOTS client. uses a 'cuid' that is already used by another DOTS client.
This code is an indication that the request has been This code is an indication that the request has been
rejected and a new request with a new 'cuid' is to be re- rejected and a new request with a new 'cuid' is to be re-
sent by the DOTS client. Note that 'conflict-status', sent by the DOTS client. Note that 'conflict-status',
'conflict-scope', and 'retry-timer' are not returned in the 'conflict-scope', and 'retry-timer' are not returned in the
error response. error response.
conflict-scope: Indicates the conflict scope. It may include a conflict-scope: Indicates the conflict scope. It may include a
skipping to change at page 27, line 20 skipping to change at page 28, line 23
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-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1.0"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Observe: 0 Observe: 0
Figure 10: GET to Retrieve all DOTS Mitigation Requests Figure 10: GET to Retrieve all DOTS Mitigation Requests
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1.0"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=12332" Uri-Path: "mid=12332"
Observe: 0 Observe: 0
Figure 11: GET to Retrieve a Specific DOTS Mitigation Request Figure 11: GET to Retrieve a Specific DOTS Mitigation Request
If the DOTS server does not find the 'mid' Uri-Path value conveyed in If the DOTS server does not find the 'mid' Uri-Path value conveyed in
the GET request in its configuration data for the requesting DOTS the GET request in its configuration data for the requesting DOTS
client, it MUST respond with a 4.04 (Not Found) error response code. client, it MUST respond with a 4.04 (Not Found) error response code.
skipping to change at page 35, line 8 skipping to change at page 36, line 8
request matches a mitigation request from that DOTS client, the request matches a mitigation request from that DOTS client, the
request is processed by the DOTS server. If no match is found, the request is processed by the DOTS server. If no match is found, the
PUT request is silently ignored by the DOTS server. PUT request is silently ignored by the DOTS server.
An example of an efficacy update message, which includes an If-Match An example of an efficacy update message, which includes an If-Match
Option with an empty value, is depicted in Figure 14. Option with an empty value, is depicted in Figure 14.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1.0"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
If-Match: If-Match:
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"target-prefix": [ "target-prefix": [
"string" "string"
], ],
"target-port-range": [ "target-port-range": [
{ {
"lower-port": integer, "lower-port": number,
"upper-port": integer "upper-port": number
} }
], ],
"target-protocol": [ "target-protocol": [
integer number
], ],
"target-fqdn": [ "target-fqdn": [
"string" "string"
], ],
"target-uri": [ "target-uri": [
"string" "string"
], ],
"alias-name": [ "alias-name": [
"string" "string"
], ],
"lifetime": integer, "lifetime": number,
"attack-status": integer "attack-status": "string"
} }
] ]
} }
} }
Figure 14: 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 value | Description |
| value | | +---------------------------------+---------------------------------+
+-----------+-------------------------------------------------------+ | 1 (under-attack) | The DOTS client determines that |
| 1 | The DOTS client determines that it is still under | | | it is still under attack. |
| | attack. | +---------------------------------+---------------------------------+
+-----------+-------------------------------------------------------+ | 2 (attack-successfully- | The DOTS client determines that |
| 2 | The DOTS client determines that the attack is | | mitigated) | the attack is successfully |
| | successfully mitigated (e.g., attack traffic is not | | | mitigated (e.g., attack traffic |
| | seen). | | | is not seen). |
+-----------+-------------------------------------------------------+ +---------------------------------+---------------------------------+
Table 3: Values of 'attack-status' Parameter Table 3: Values of 'attack-status' Parameter
The DOTS server indicates the result of processing a PUT request The DOTS server indicates the result of processing a PUT request
using CoAP response codes. The response code 2.04 (Changed) is using CoAP response codes. The response code 2.04 (Changed) is
returned if the DOTS server has accepted the mitigation efficacy returned if the DOTS server has accepted the mitigation efficacy
update. The error response code 5.03 (Service Unavailable) is update. The error response code 5.03 (Service Unavailable) is
returned if the DOTS server has erred or is incapable of performing returned if the DOTS server has erred or is incapable of performing
the mitigation. the mitigation.
skipping to change at page 36, line 42 skipping to change at page 37, line 42
requests. requests.
The same considerations for manipulating 'cdid' parameter by DOTS The same considerations for manipulating 'cdid' parameter by DOTS
gateways, as specified in Section 4.4.1, MUST be followed for DELETE gateways, as specified in Section 4.4.1, MUST be followed for DELETE
requests. Uri-Path parameters with empty values MUST NOT be present requests. Uri-Path parameters with empty values MUST NOT be present
in a request. in a request.
Header: DELETE (Code=0.04) Header: DELETE (Code=0.04)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1.0"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
Figure 15: Withdraw a DOTS Mitigation Figure 15: Withdraw a DOTS Mitigation
If the DELETE request does not include 'cuid' and 'mid' parameters, If the DELETE request does not include 'cuid' and 'mid' parameters,
the DOTS server MUST reply with a 4.00 (Bad Request). the DOTS server MUST reply with a 4.00 (Bad Request).
Once the request is validated, the DOTS server immediately Once the request is validated, the DOTS server immediately
skipping to change at page 39, line 29 skipping to change at page 40, line 24
DOTS signal channel session configuration. This procedure occurs DOTS signal channel session configuration. This procedure occurs
between a DOTS client and its immediate peer DOTS server. As such, between a DOTS client and its immediate peer DOTS server. As such,
this GET request MUST NOT be relayed by an on-path DOTS gateway. this GET request MUST NOT be relayed by an on-path DOTS gateway.
Figure 16 shows how to obtain acceptable configuration parameters for Figure 16 shows how to obtain acceptable configuration parameters for
the DOTS server. the DOTS server.
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1.0"
Uri-Path: "config" Uri-Path: "config"
Figure 16: GET to Retrieve Configuration Figure 16: GET to Retrieve Configuration
The DOTS server in the 2.05 (Content) response conveys the current, The DOTS server in the 2.05 (Content) response conveys the current,
minimum, and maximum attribute values acceptable by the DOTS server minimum, and maximum attribute values acceptable by the DOTS server
(Figure 17). (Figure 17).
Content-Format: "application/dots+cbor" Content-Format: "application/dots+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": number,
"min-value": integer, "min-value": number,
"current-value": integer "current-value": number
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
"max-value": integer, "max-value": number,
"min-value": integer, "min-value": number,
"current-value": integer "current-value": number
}, },
"max-retransmit": { "max-retransmit": {
"max-value": integer, "max-value": number,
"min-value": integer, "min-value": number,
"current-value": integer "current-value": number
}, },
"ack-timeout": { "ack-timeout": {
"max-value-decimal": number, "max-value-decimal": "string",
"min-value-decimal": number, "min-value-decimal": "string",
"current-value-decimal": number "current-value-decimal": "string"
}, },
"ack-random-factor": { "ack-random-factor": {
"max-value-decimal": number, "max-value-decimal": "string",
"min-value-decimal": number, "min-value-decimal": "string",
"current-value-decimal": number "current-value-decimal": "string"
} }
}, },
"idle-config": { "idle-config": {
"heartbeat-interval": { "heartbeat-interval": {
"max-value": integer, "max-value": number,
"min-value": integer, "min-value": number,
"current-value": integer "current-value": number
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
"max-value": integer, "max-value": number,
"min-value": integer, "min-value": number,
"current-value": integer "current-value": number
}, },
"max-retransmit": { "max-retransmit": {
"max-value": integer, "max-value": number,
"min-value": integer, "min-value": number,
"current-value": integer "current-value": number
}, },
"ack-timeout": { "ack-timeout": {
"max-value-decimal": number, "max-value-decimal": "string",
"min-value-decimal": number, "min-value-decimal": "string",
"current-value-decimal": number "current-value-decimal": "string"
}, },
"ack-random-factor": { "ack-random-factor": {
"max-value-decimal": number, "max-value-decimal": "string",
"min-value-decimal": number, "min-value-decimal": "string",
"current-value-decimal": number "current-value-decimal": "string"
} }
} }
} }
} }
Figure 17: GET Configuration Response Body Figure 17: GET Configuration Response Body
The parameters in Figure 17 are described below: The parameters in Figure 17 are described below:
mitigating-config: Set of configuration parameters to use when a mitigating-config: Set of configuration parameters to use when a
skipping to change at page 45, line 8 skipping to change at page 46, line 8
values for message transmission parameters and default values for values for message transmission parameters and default values for
non-negotiated message transmission parameters. non-negotiated message transmission parameters.
The signal channel session configuration is applicable to a single The signal channel session configuration is applicable to a single
DOTS signal channel session between DOTS agents, so the 'cuid' Uri- DOTS signal channel session between DOTS agents, so the 'cuid' Uri-
Path MUST NOT be used. Path MUST NOT be used.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1.0"
Uri-Path: "config" Uri-Path: "config"
Uri-Path: "sid=123" Uri-Path: "sid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:signal-config": { "ietf-dots-signal-channel:signal-config": {
"mitigating-config": { "mitigating-config": {
"heartbeat-interval": { "heartbeat-interval": {
"current-value": integer "current-value": number
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
"current-value": integer "current-value": number
}, },
"max-retransmit": { "max-retransmit": {
"current-value": integer "current-value": number
}, },
"ack-timeout": { "ack-timeout": {
"current-value-decimal": number "current-value-decimal": "string"
}, },
"ack-random-factor": { "ack-random-factor": {
"current-value-decimal": number "current-value-decimal": "string"
} }
}, },
"idle-config": { "idle-config": {
"heartbeat-interval": { "heartbeat-interval": {
"current-value": integer "current-value": number
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
"current-value": integer "current-value": number
}, },
"max-retransmit": { "max-retransmit": {
"current-value": integer "current-value": number
}, },
"ack-timeout": { "ack-timeout": {
"current-value-decimal": number "current-value-decimal": "string"
}, },
"ack-random-factor": { "ack-random-factor": {
"current-value-decimal": number "current-value-decimal": "string"
} }
} }
} }
} }
Figure 19: 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:
skipping to change at page 47, line 8 skipping to change at page 48, line 8
automatically deleted and no longer available at the DOTS server. automatically deleted and no longer available at the DOTS server.
Figure 20 shows a PUT request example to convey the configuration Figure 20 shows a PUT request example to convey the configuration
parameters for the DOTS signal channel. In this example, the parameters for the DOTS signal channel. In this example, the
heartbeat mechanism is disabled when no mitigation is active, while heartbeat mechanism is disabled when no mitigation is active, while
the heartbeat interval is set to '91' when a mitigation is active. the heartbeat interval is set to '91' when a mitigation is active.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1.0"
Uri-Path: "config" Uri-Path: "config"
Uri-Path: "sid=123" Uri-Path: "sid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:signal-config": { "ietf-dots-signal-channel:signal-config": {
"mitigating-config": { "mitigating-config": {
"heartbeat-interval": { "heartbeat-interval": {
"current-value": 91 "current-value": 91
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
skipping to change at page 49, line 35 skipping to change at page 50, line 35
(Section 6 of [RFC8446])). (Section 6 of [RFC8446])).
4.5.4. Delete DOTS Signal Channel Session Configuration 4.5.4. Delete DOTS Signal Channel Session Configuration
A DELETE request is used to delete the installed DOTS signal channel A DELETE request is used to delete the installed DOTS signal channel
session configuration data (Figure 21). session configuration data (Figure 21).
Header: DELETE (Code=0.04) Header: DELETE (Code=0.04)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1.0"
Uri-Path: "config" Uri-Path: "config"
Uri-Path: "sid=123" Uri-Path: "sid=123"
Figure 21: Delete Configuration Figure 21: Delete Configuration
The DOTS server resets the DOTS signal channel session configuration The DOTS server resets the DOTS signal channel session configuration
back to the default values and acknowledges a DOTS client's request back to the default values and acknowledges a DOTS client's request
to remove the DOTS signal channel session configuration using 2.02 to remove the DOTS signal channel session configuration using 2.02
(Deleted) response code. (Deleted) response code.
skipping to change at page 52, line 26 skipping to change at page 53, line 26
cryptographic state and vice versa. Such probes can also keep cryptographic state and vice versa. Such probes can also keep
firewalls and/or stateful translators bindings alive. This probing firewalls and/or stateful translators bindings alive. This probing
reduces the frequency of establishing a new handshake when a DOTS reduces the frequency of establishing a new handshake when a DOTS
signal needs to be conveyed to the DOTS server. signal needs to be conveyed to the DOTS server.
DOTS servers MAY trigger their heartbeat requests immediately after DOTS servers MAY trigger their heartbeat requests immediately after
receiving heartbeat probes from peer DOTS clients. As a reminder, it receiving heartbeat probes from peer DOTS clients. As a reminder, it
is the responsibility of DOTS clients to ensure that on-path is the responsibility of DOTS clients to ensure that on-path
translators/firewalls are maintaining a binding so that the same translators/firewalls are maintaining a binding so that the same
external IP address and/or port number is retained for the DOTS external IP address and/or port number is retained for the DOTS
session. signal channel session.
In case of a massive DDoS attack that saturates the incoming link(s) In case of a massive DDoS attack that saturates the incoming link(s)
to the DOTS client, all traffic from the DOTS server to the DOTS to the DOTS client, all traffic from the DOTS server to the DOTS
client will likely be dropped, although the DOTS server receives client will likely be dropped, although the DOTS server receives
heartbeat requests in addition to DOTS messages sent by the DOTS heartbeat requests in addition to DOTS messages sent by the DOTS
client. In this scenario, the DOTS agents MUST behave differently to client. In this scenario, the DOTS agents MUST behave differently to
handle message transmission and DOTS session liveliness during link handle message transmission and DOTS signal channel session
saturation: liveliness during link saturation:
o The DOTS client MUST NOT consider the DOTS session terminated even o The DOTS client MUST NOT consider the DOTS signal channel session
after a maximum 'missing-hb-allowed' threshold is reached. The terminated even after a maximum 'missing-hb-allowed' threshold is
DOTS client SHOULD keep on using the current DOTS session to send reached. The DOTS client SHOULD keep on using the current DOTS
heartbeat requests over it, so that the DOTS server knows the DOTS signal channel session to send heartbeat requests over it, so that
client has not disconnected the DOTS session. the DOTS server knows the DOTS client has not disconnected the
DOTS signal channel session.
After the maximum 'missing-hb-allowed' threshold is reached, the After the maximum 'missing-hb-allowed' threshold is reached, the
DOTS client SHOULD try to resume the (D)TLS session. The DOTS DOTS client SHOULD try to resume the (D)TLS session. The DOTS
client SHOULD send mitigation requests over the current DOTS client SHOULD send mitigation requests over the current DOTS
session, and in parallel, for example, try to resume the (D)TLS signal channel session, and in parallel, for example, try to
session or use 0-RTT mode in DTLS 1.3 to piggyback the mitigation resume the (D)TLS session or use 0-RTT mode in DTLS 1.3 to
request in the ClientHello message. piggyback the mitigation request in the ClientHello message.
As soon as the link is no longer saturated, if traffic from the As soon as the link is no longer saturated, if traffic from the
DOTS server reaches the DOTS client over the current DOTS session, DOTS server reaches the DOTS client over the current DOTS signal
the DOTS client can stop (D)TLS session resumption or if (D)TLS channel session, the DOTS client can stop (D)TLS session
session resumption is successful then disconnect the current DOTS resumption or if (D)TLS session resumption is successful then
session. disconnect the current DOTS signal channel session.
o If the DOTS server does not receive any traffic from the peer DOTS o If the DOTS server does not receive any traffic from the peer DOTS
client, then the DOTS server sends heartbeat requests to the DOTS client, then the DOTS server sends heartbeat requests to the DOTS
client and after maximum 'missing-hb-allowed' threshold is client and after maximum 'missing-hb-allowed' threshold is
reached, the DOTS server concludes the session is disconnected. reached, the DOTS server concludes the session is disconnected.
In DOTS over UDP, heartbeat messages 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 [RFC8323]. That is, the DOTS agent sends a Ping message and the of [RFC8323]. That is, the DOTS agent sends a Ping message and the
peer DOTS agent would respond by sending a single Pong message. peer DOTS agent would respond by sending a single Pong message.
5. DOTS Signal Channel YANG Module 5. DOTS Signal Channel YANG Modules
This document defines a YANG [RFC7950] module for DOTS mitigation This document defines a YANG [RFC7950] module for DOTS mitigation
scope, DOTS signal channel session configuration data, and DOTS scope, DOTS signal channel session configuration data, and DOTS
redirected signalling. redirected signalling.
This YANG module defines the DOTS client interaction with the DOTS This YANG module (ietf-dots-signal-channel) defines the DOTS client
server as seen by the DOTS client. A DOTS server is allowed to interaction with the DOTS server as seen by the DOTS client. A DOTS
update the non-configurable 'ro' entities in the responses. This server is allowed to update the non-configurable 'ro' entities in the
YANG module is not intended to be used for DOTS server management responses. This YANG module is not intended to be used for DOTS
purposes. Such module is out of the scope of this document. server management purposes. Such module is out of the scope of this
document.
A companion YANG module is defined to include a collection of types
defined by IANA: "iana-dots-signal-channel" (Section 5.2).
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.3), 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 scope* [cuid mid] | +--rw scope* [cuid mid]
| +--rw cdid? string | +--rw cdid? string
| +--rw cuid string | +--rw cuid string
| +--rw mid uint32 | +--rw mid uint32
skipping to change at page 54, line 12 skipping to change at page 55, line 16
| +--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
| +--rw lifetime? int32 | +--rw lifetime? int32
| +--rw trigger-mitigation? boolean | +--rw trigger-mitigation? boolean
| +--ro mitigation-start? uint64 | +--ro mitigation-start? uint64
| +--ro status? enumeration | +--ro status? iana-signal:status
| +--ro conflict-information | +--ro conflict-information
| | +--ro conflict-status? enumeration | | +--ro conflict-status? iana-signal:conflict-status
| | +--ro conflict-cause? enumeration | | +--ro conflict-cause? iana-signal:conflict-cause
| | +--ro retry-timer? uint32 | | +--ro retry-timer? uint32
| | +--ro conflict-scope | | +--ro conflict-scope
| | +--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 -> /ietf-acl:acls/acl/name | | | +--ro acl-name
| | | +--ro acl-type? -> /ietf-acl:acls/acl/type | | | | -> /ietf-data:dots-data/dots-client/acls/
| | | | acl/name
| | | +--ro acl-type?
| | | -> /ietf-data:dots-data/dots-client/acls/
| | | acl/type
| | +--ro mid? -> ../../../mid | | +--ro mid? -> ../../../mid
| +--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? iana-signal:attack-status
+--:(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
| | | +--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
skipping to change at page 55, line 35 skipping to change at page 56, line 43
| | +--ro min-value-decimal? decimal64 | | +--ro min-value-decimal? decimal64
| | +--rw current-value-decimal? decimal64 | | +--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
+--:(redirected-signal) +--:(redirected-signal)
+--ro alt-server string +--ro alt-server string
+--ro alt-server-record* inet:ip-address +--ro alt-server-record* inet:ip-address
5.2. YANG Module 5.2. IANA DOTS Signal Channel YANG Module
<CODE BEGINS> file "ietf-dots-signal-channel@2018-08-16.yang" <CODE BEGINS> file "iana-dots-signal-channel@2018-10-17.yang"
module iana-dots-signal-channel {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:iana-dots-signal-channel";
prefix iana-signal;
organization
"IANA";
contact
"Internet Assigned Numbers Authority
Postal: ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
United States of America
Tel: +1 310 301 5800
<mailto:iana@iana.org>";
description
"This module contains a collection of YANG data types defined
by IANA and used for DOTS signal channel protocol.
Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2018-10-17 {
description
"Initial revision.";
reference
"RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification";
}
typedef status {
type enumeration {
enum attack-mitigation-in-progress {
value 1;
description
"Attack mitigation setup is in progress (e.g., changing
the network path to re-route the inbound traffic
to DOTS mitigator).";
}
enum attack-successfully-mitigated {
value 2;
description
"Attack is being successfully mitigated (e.g., traffic
is redirected to a DDoS mitigator and attack
traffic is dropped or blackholed).";
}
enum attack-stopped {
value 3;
description
"Attack has stopped and the DOTS client can
withdraw the mitigation request.";
}
enum attack-exceeded-capability {
value 4;
description
"Attack has exceeded the mitigation provider
capability.";
}
enum dots-client-withdrawn-mitigation {
value 5;
description
"DOTS client has withdrawn the mitigation
request and the mitigation is active but
terminating.";
}
enum attack-mitigation-terminated {
value 6;
description
"Attack mitigation is now terminated.";
}
enum attack-mitigation-withdrawn {
value 7;
description
"Attack mitigation is withdrawn.";
}
enum attack-mitigation-signal-loss {
value 8;
description
"Attack mitigation will be triggered
for the mitigation request only when
the DOTS signal channel session is lost.";
}
}
description
"Enumeration for status reported by the DOTS server.";
}
typedef conflict-status {
type enumeration {
enum request-inactive-other-active {
value 1;
description
"DOTS Server has detected conflicting mitigation
requests from different DOTS clients.
This mitigation request is currently inactive
until the conflicts are resolved. Another
mitigation request is active.";
}
enum request-active {
value 2;
description
"DOTS Server has detected conflicting mitigation
requests from different DOTS clients.
This mitigation request is currently active.";
}
enum all-requests-inactive {
value 3;
description
"DOTS Server has detected conflicting mitigation
requests from different DOTS clients. All
conflicting mitigation requests are inactive.";
}
}
description
"Enumeration for conflict status.";
}
typedef conflict-cause {
type enumeration {
enum overlapping-targets {
value 1;
description
"Overlapping targets. conflict-scope provides
more details about the exact conflict.";
}
enum conflict-with-acceptlist {
value 2;
description
"Conflicts with an existing accept-list.
This code is returned when the DDoS mitigation
detects that some of the source addresses/prefixes
listed in the accept-list ACLs are actually
attacking the target.";
}
enum cuid-collision {
value 3;
description
"Conflicts with the cuid used by another
DOTS client.";
}
}
description
"Enumeration for conflict causes.";
}
typedef attack-status {
type enumeration {
enum under-attack {
value 1;
description
"The DOTS client determines that it is still under
attack.";
}
enum attack-successfully-mitigated {
value 2;
description
"The DOTS client determines that the attack is
successfully mitigated.";
}
}
description
"Enumeration for attack status codes.";
}
}
<CODE ENDS>
5.3. IETF DOTS Signal Channel YANG Module
This module uses the common YANG types defined in [RFC6991] and types
defined in [I-D.ietf-dots-data-channel].
<CODE BEGINS> file "ietf-dots-signal-channel@2018-10-17.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;
reference "Section 4 of RFC 6991";
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference "Section 3 of RFC 6991";
} }
import ietf-access-control-list { import ietf-dots-data-channel {
prefix ietf-acl; prefix ietf-data;
reference
"RFC YYYY: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Data Channel Specification";
}
import iana-dots-signal-channel {
prefix iana-signal;
} }
organization organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group"; "IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/dots/> "WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org> WG List: <mailto:dots@ietf.org>
Editor: Konda, Tirumaleswar Reddy Editor: Konda, Tirumaleswar Reddy
<mailto:TirumaleswarReddy_Konda@McAfee.com> <mailto:TirumaleswarReddy_Konda@McAfee.com>
skipping to change at page 56, line 44 skipping to change at page 61, line 50
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-08-16 { revision 2018-10-17 {
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 Specification"; Signaling (DOTS) Signal Channel Specification";
} }
/* /*
* Groupings * Groupings
*/ */
grouping target {
description
"Specifies the targets of the mitigation request.";
leaf-list target-prefix {
type inet:ip-prefix;
description
"IPv4 or IPv6 prefix identifying the target.";
}
list target-port-range {
key "lower-port upper-port";
description
"Port range. When only lower-port is
present, it represents a single port number.";
leaf lower-port {
type inet:port-number;
mandatory true;
description
"Lower port number of the port range.";
}
leaf upper-port {
type inet:port-number;
must ". >= ../lower-port" {
error-message
"The upper port number must be greater than
or equal to lower port number.";
}
description
"Upper port number of the port range.";
}
}
leaf-list target-protocol {
type uint8;
description
"Identifies the target protocol number.
The value '0' means 'all protocols'.
Values are taken from the IANA protocol registry:
https://www.iana.org/assignments/protocol-numbers/
protocol-numbers.xhtml
For example, 6 for TCP or 17 for UDP.";
}
leaf-list target-fqdn {
type inet:domain-name;
description
"FQDN identifying the target.";
}
leaf-list target-uri {
type inet:uri;
description
"URI identifying the target.";
}
}
grouping mitigation-scope { grouping mitigation-scope {
description description
"Specifies the scope of the mitigation request."; "Specifies the scope of the mitigation request.";
list scope { list scope {
key "cuid mid"; key "cuid mid";
description description
"The scope of the request."; "The scope of the request.";
leaf cdid { leaf cdid {
type string; type string;
skipping to change at page 58, line 51 skipping to change at page 62, line 51
lifetime of the DOTS client."; lifetime of the DOTS client.";
} }
leaf mid { leaf mid {
type uint32; type uint32;
description description
"Mitigation request identifier. "Mitigation request identifier.
This identifier must be unique for each mitigation This identifier must be unique for each mitigation
request bound to the DOTS client."; request bound to the DOTS client.";
} }
uses target; uses ietf-data:target;
leaf-list alias-name { leaf-list alias-name {
type string; type string;
description description
"An alias name that points to a resource."; "An alias name that points to a resource.";
} }
leaf lifetime { leaf lifetime {
type int32; type int32;
units "seconds"; units "seconds";
default "3600"; default "3600";
description description
skipping to change at page 59, line 38 skipping to change at page 63, line 38
session is lost."; session is lost.";
} }
leaf mitigation-start { leaf mitigation-start {
type uint64; type uint64;
config false; config false;
description description
"Mitigation start time is represented in seconds "Mitigation start time is represented in seconds
relative to 1970-01-01T00:00:00Z in UTC time."; relative to 1970-01-01T00:00:00Z in UTC time.";
} }
leaf status { leaf status {
type enumeration { type iana-signal:status;
enum "attack-mitigation-in-progress" {
value 1;
description
"Attack mitigation setup is in progress (e.g., changing
the network path to re-route the inbound traffic
to DOTS mitigator).";
}
enum "attack-successfully-mitigated" {
value 2;
description
"Attack is being successfully mitigated (e.g., traffic
is redirected to a DDoS mitigator and attack
traffic is dropped or blackholed).";
}
enum "attack-stopped" {
value 3;
description
"Attack has stopped and the DOTS client can
withdraw the mitigation request.";
}
enum "attack-exceeded-capability" {
value 4;
description
"Attack has exceeded the mitigation provider
capability.";
}
enum "dots-client-withdrawn-mitigation" {
value 5;
description
"DOTS client has withdrawn the mitigation
request and the mitigation is active but
terminating.";
}
enum "attack-mitigation-terminated" {
value 6;
description
"Attack mitigation is now terminated.";
}
enum "attack-mitigation-withdrawn" {
value 7;
description
"Attack mitigation is withdrawn.";
}
enum "attack-mitigation-signal-loss" {
value 8;
description
"Attack mitigation will be triggered
for the mitigation request only when
the DOTS signal channel session is lost.";
}
}
config false; config false;
description description
"Indicates the status of a mitigation request. "Indicates the status of a mitigation request.
It must be included in responses only."; It must be included in responses only.";
} }
container conflict-information { container conflict-information {
config false; config false;
description description
"Indicates that a conflict is detected. "Indicates that a conflict is detected.
Must only be used for responses."; Must only be used for responses.";
skipping to change at page 61, line 4 skipping to change at page 63, line 49
config false; config false;
description description
"Indicates the status of a mitigation request. "Indicates the status of a mitigation request.
It must be included in responses only."; It must be included in responses only.";
} }
container conflict-information { container conflict-information {
config false; config false;
description description
"Indicates that a conflict is detected. "Indicates that a conflict is detected.
Must only be used for responses."; Must only be used for responses.";
leaf conflict-status { leaf conflict-status {
type enumeration { type iana-signal:conflict-status;
enum "request-inactive-other-active" {
value 1;
description
"DOTS Server has detected conflicting mitigation
requests from different DOTS clients.
This mitigation request is currently inactive
until the conflicts are resolved. Another
mitigation request is active.";
}
enum "request-active" {
value 2;
description
"DOTS Server has detected conflicting mitigation
requests from different DOTS clients.
This mitigation request is currently active.";
}
enum "all-requests-inactive" {
value 3;
description
"DOTS Server has detected conflicting mitigation
requests from different DOTS clients. All
conflicting mitigation requests are inactive.";
}
}
description description
"Indicates the conflict status."; "Indicates the conflict status.";
} }
leaf conflict-cause { leaf conflict-cause {
type enumeration { type iana-signal:conflict-cause;
enum "overlapping-targets" {
value 1;
description
"Overlapping targets. conflict-scope provides
more details about the exact conflict.";
}
enum "conflict-with-whitelist" {
value 2;
description
"Conflicts with an existing white list.
This code is returned when the DDoS mitigation
detects that some of the source addresses/prefixes
listed in the white list ACLs are actually
attacking the target.";
}
enum "cuid-collision" {
value 3;
description
"Conflicts with the cuid used by another
DOTS client.";
}
}
description description
"Indicates the cause of the conflict."; "Indicates the cause of the conflict.";
} }
leaf retry-timer { leaf retry-timer {
type uint32; type uint32;
units "seconds"; units "seconds";
description description
"The DOTS client must not re-send the "The DOTS client must not re-send the
same request that has a conflict before the expiry of same request that has a conflict before the expiry of
this timer."; this timer.";
} }
container conflict-scope { container conflict-scope {
description description
"Provides more information about the conflict scope."; "Provides more information about the conflict scope.";
uses target { uses ietf-data:target {
when "../conflict-cause = 'overlapping-targets'"; when "../conflict-cause = 'overlapping-targets'";
} }
leaf-list alias-name { leaf-list alias-name {
when "../../conflict-cause = 'overlapping-targets'"; when "../../conflict-cause = 'overlapping-targets'";
type string; type string;
description description
"Conflicting alias-name."; "Conflicting alias-name.";
} }
list acl-list { list acl-list {
when "../../conflict-cause = 'conflict-with-whitelist'"; when "../../conflict-cause = 'conflict-with-acceptlist'";
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:acls/ietf-acl:acl/" + path "/ietf-data:dots-data/ietf-data:dots-client/"
"ietf-acl:name"; +"ietf-data:acls/ietf-data:acl/ietf-data: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:acls/ietf-acl:acl/" + path "/ietf-data:dots-data/ietf-data:dots-client/"
"ietf-acl:type"; +ietf-data:acls/ietf-data:acl/ietf-data: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 mid { leaf mid {
when "../../conflict-cause = 'overlapping-targets'"; when "../../conflict-cause = 'overlapping-targets'";
type leafref { type leafref {
path "../../../mid"; path "../../../mid";
skipping to change at page 64, line 12 skipping to change at page 66, line 10
leaf pps-dropped { leaf pps-dropped {
type yang:zero-based-counter64; type yang:zero-based-counter64;
config false; config false;
description description
"The average number of dropped packets per second "The average number of dropped packets per second
for the mitigation request since the attack for the mitigation request since the attack
mitigation is triggered. This should be a mitigation is triggered. This should be a
five-minute average."; five-minute average.";
} }
leaf attack-status { leaf attack-status {
type enumeration { type iana-signal:attack-status;
enum "under-attack" {
value 1;
description
"The DOTS client determines that it is still under
attack.";
}
enum "attack-successfully-mitigated" {
value 2;
description
"The DOTS client determines that the attack is
successfully mitigated.";
}
}
description description
"Indicates the status of an attack as seen by the "Indicates the status of an attack as seen by the
DOTS client."; DOTS client.";
} }
} }
} }
grouping config-parameters { grouping config-parameters {
description description
"Subset of DOTS signal channel session configuration."; "Subset of DOTS signal channel session configuration.";
skipping to change at page 68, line 4 skipping to change at page 69, line 37
is active."; is active.";
uses config-parameters; uses config-parameters;
} }
container idle-config { container idle-config {
description description
"Configuration parameters to use when no mitigation "Configuration parameters to use when no mitigation
is active."; is active.";
uses config-parameters; uses config-parameters;
} }
} }
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
"FQDN of an alternate server."; "FQDN of an alternate server.";
} }
leaf-list alt-server-record { leaf-list alt-server-record {
type inet:ip-address; type inet:ip-address;
config false; config false;
description description
"List of records for the alternate server."; "List of records for the alternate server.";
} }
} }
/* /*
* Main Container for DOTS Signal Channel * Main Container for DOTS Signal Channel
*/ */
container dots-signal { container dots-signal {
description description
"Main container for DOTS signal message. "Main container for DOTS signal message.
A DOTS signal message can be a mitigation, a configuration, A DOTS signal message can be a mitigation, a configuration,
or a redirected signal message."; or a redirected signal message.";
choice message-type { choice message-type {
description description
"Can be a mitigation, a configuration, or a redirect "Can be a mitigation, a configuration, or a redirect
skipping to change at page 76, line 8 skipping to change at page 78, line 8
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 25, 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), and a YANG suffix in the Well-Known URIs registry (Section 9.2), and two YANG
module (Section 9.7). It also creates a registry for mappings to modules (Section 9.7). It also creates a new registry for DOTS
CBOR (Section 9.3). signal channel protocol (Section 9.6).
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 76, line 39 skipping to change at page 78, line 39
+----------+----------------+---------------------+-----------------+ +----------+----------------+---------------------+-----------------+
| URI | Change | Specification | Related | | URI | Change | Specification | Related |
| suffix | controller | document(s) | information | | suffix | controller | document(s) | information |
+----------+----------------+---------------------+-----------------+ +----------+----------------+---------------------+-----------------+
| dots | IETF | [RFCXXXX] | None | | dots | IETF | [RFCXXXX] | None |
+----------+----------------+---------------------+-----------------+ +----------+----------------+---------------------+-----------------+
Table 5: 'dots' well-known URI Table 5: 'dots' well-known URI
9.3. DOTS Signal Channel CBOR Mappings Registry 9.3. Media Type Registration
The DOTS signal channel protocol is extensible to support new This section registers the "application/dots+cbor" media type in the
parameters and instructions for doing it are discussed below: "Media Types" registry [IANA.MediaTypes] in the manner described in
RFC 6838 [RFC6838], which can be used to indicate that the content is
a DOTS signal channel object.
9.3.1. Registry Contents
o Type name: application
o Subtype name: dots+cbor
o Required parameters: N/A
o Optional parameters: N/A
o Encoding considerations: binary
o Security considerations: See the Security Considerations section
of [RFCXXXX]
o Interoperability considerations: N/A
o Published specification: [RFCXXXX]
o Applications that use this media type: DOTS agents sending DOTS
messages over CoAP over (D)TLS.
o Fragment identifier considerations: N/A
o Additional information:
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
o Person & email address to contact for further information:
IESG, iesg@ietf.org
o Intended usage: COMMON
o Restrictions on usage: none
o Author: Tirumaleswar Reddy, kondtir@gmail.com
o Change controller: IESG
o Provisional registration? No
9.4. CoAP Content-Formats Registration
This section registers the CoAP Content-Format ID for the
"application/dots+cbor" media type in the "CoAP Content-Formats"
registry [IANA.CoAP.Content-Formats].
9.4.1. Registry Contents
o Media Type: application/dots+cbor
o Encoding: -
o Id: TBD
o Reference: [RFCXXXX]
9.5. CBOR Tag Registration
This section defines the DOTS CBOR tag as another means for
applications to declare that a CBOR data structure is a DOTS signal
channel object. Its use is optional and is intended for use in cases
in which this information would not otherwise be known. DOTS CBOR
tag is not required for DOTS signal channel protocol version
specified in this document. If present, the DOTS tag MUST prefix a
DOTS signal channel object.
This section registers the DOTS signal channel CBOR tag in the "CBOR
Tags" registry [IANA.CBOR.Tags].
9.5.1. Registry Contents
o CBOR Tag: TBD (please assign the same value as the Content-Format)
o Data Item: DDoS Open Threat Signaling (DOTS) signal channel object
o Semantics: DDoS Open Threat Signaling (DOTS) signal channel
object, as defined in [RFCXXXX]
o Description of Semantics: [RFCXXXX]
o Point of Contact: Tirumaleswar Reddy, kondtir@gmail.com
9.6. DOTS Signal Channel Protocol 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 Registry". The following sections creates new sub-
registry is provided in Section 9.3.1. Registration requests are registries.
evaluated using the criteria described in the CBOR Key Value
instructions in the registration template below after a three-week 9.6.1. DOTS Signal Channel CBOR Mappings Sub-Registry
review period on the dots-signal-reg-review@ietf.org mailing list, on
the advice of one or more Designated Experts [RFC8126]. However, to The document requests IANA to create a new sub-registry, entitled
allow for the allocation of values prior to publication, the "DOTS Signal Channel CBOR Mappings".
Designated Experts may approve registration once they are satisfied
that such a specification will be published. [[ Note to the RFC The structure of this sub-registry is provided in Section 9.6.1.1.
Editor: The name of the mailing list should be determined in Registration requests are evaluated using the criteria described in
consultation with the IESG and IANA. Suggested name: dots-signal- the CBOR Key Value instructions in the registration template below
reg-review@ietf.org. ]] after a three-week review period on the dots-signal-reg-
review@ietf.org mailing list, on the advice of one or more Designated
Experts [RFC8126]. However, to allow for the allocation of values
prior to publication, the Designated Experts may approve registration
once they are satisfied that such a specification will be published.
[[ Note to the RFC Editor: The name of the mailing list should be
determined in consultation with the IESG and IANA. Suggested name:
dots-signal-reg-review@ietf.org. ]]
Registration requests sent to the mailing list for review should use Registration requests sent to the mailing list for review should use
an appropriate subject (e.g., "Request to register parameter: an appropriate subject (e.g., "Request to register parameter:
example"). Registration requests that are undetermined for a period example"). Registration requests that are undetermined for a period
longer than 21 days can be brought to the IESG's attention (using the longer than 21 days can be brought to the IESG's attention (using the
iesg@ietf.org mailing list) for resolution. iesg@ietf.org mailing list) for resolution.
Criteria that should be applied by the Designated Experts includes Criteria that should be applied by the Designated Experts includes
determining whether the proposed registration duplicates existing determining whether the proposed registration duplicates existing
functionality, whether it is likely to be of general applicability or functionality, whether it is likely to be of general applicability or
skipping to change at page 77, line 35 skipping to change at page 81, line 15
It is suggested that multiple Designated Experts be appointed who are It is suggested that multiple Designated Experts be appointed who are
able to represent the perspectives of different applications using able to represent the perspectives of different applications using
this specification in order to enable broadly informed review of this specification in order to enable broadly informed review of
registration decisions. In cases where a registration decision could registration decisions. In cases where a registration decision could
be perceived as creating a conflict of interest for a particular be perceived as creating a conflict of interest for a particular
Expert, that Expert should defer to the judgment of the other Expert, that Expert should defer to the judgment of the other
Experts. Experts.
The registry is initially populated with the values in Table 6. The registry is initially populated with the values in Table 6.
9.3.1. Registration Template 9.6.1.1. Registration Template
Parameter name: Parameter name:
Parameter name as used in the DOTS signal channel. Parameter name as used in the DOTS signal channel.
CBOR Key Value: CBOR Key Value:
Key value for the parameter. The key value MUST be an integer in Key value for the parameter. The key value MUST be an integer in
the 1-65535 range. The key values of the comprehension-required the 1-65535 range. The key values of the comprehension-required
range (0x0001 - 0x3FFF) and of the comprehension-optional range range (0x0001 - 0x3FFF) and of the comprehension-optional range
(0x8000 - 0xBFFF) are assigned by IETF Review [RFC8126]. The key (0x8000 - 0xBFFF) are assigned by IETF Review [RFC8126]. The key
values of the comprehension-optional range (0x4000 - 0x7FFF) are values of the comprehension-optional range (0x4000 - 0x7FFF) are
skipping to change at page 78, line 16 skipping to change at page 81, line 44
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.3.2. Initial Registry Content 9.6.1.2. Initial Sub-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 | | | | |
| scope | 2 | 4 | IESG | [RFCXXXX] | | scope | 2 | 4 | IESG | [RFCXXXX] |
| cdid | 3 | 3 | IESG | [RFCXXXX] | | cdid | 3 | 3 | IESG | [RFCXXXX] |
skipping to change at page 79, line 30 skipping to change at page 83, line 10
| idle-config | 44 | 5 | IESG | [RFCXXXX] | | idle-config | 44 | 5 | IESG | [RFCXXXX] |
| trigger-mitigation | 45 | 7 | IESG | [RFCXXXX] | | trigger-mitigation | 45 | 7 | IESG | [RFCXXXX] |
| ietf-dots-signal-chan| 46 | 5 | IESG | [RFCXXXX] | | ietf-dots-signal-chan| 46 | 5 | IESG | [RFCXXXX] |
| nel:redirected-signal| | | | | | nel:redirected-signal| | | | |
| alt-server | 47 | 3 | IESG | [RFCXXXX] | | alt-server | 47 | 3 | IESG | [RFCXXXX] |
| alt-server-record | 48 | 4 | IESG | [RFCXXXX] | | alt-server-record | 48 | 4 | IESG | [RFCXXXX] |
+----------------------+-------+-------+------------+---------------+ +----------------------+-------+-------+------------+---------------+
Table 6: Initial DOTS Signal Channel CBOR Mappings Registry Table 6: Initial DOTS Signal Channel CBOR Mappings Registry
9.4. Media Type Registration 9.6.2. Status Codes Sub-Registry
This section registers the "application/dots+cbor" media type in the The document requests IANA to create a new sub-registry, entitled
"Media Types" registry [IANA.MediaTypes] in the manner described in "DOTS Signal Channel Status Codes". Codes in this registry are used
RFC 6838 [RFC6838], which can be used to indicate that the content is as valid values of 'status' parameter.
a DOTS signal channel object.
9.4.1. Registry Contents The registry is initially populated with the following values:
o Type name: application +-----+----------------------------------+--------------+-----------+
o Subtype name: dots+cbor | Cod | Label | Description | Reference |
o Required parameters: N/A | e | | | |
o Optional parameters: N/A +-----+----------------------------------+--------------+-----------+
o Encoding considerations: binary | 1 | attack-mitigation-in-progress | Attack | [RFCXXXX] |
o Security considerations: See the Security Considerations section | | | mitigation | |
of [RFCXXXX] | | | setup is in | |
o Interoperability considerations: N/A | | | progress | |
o Published specification: [RFCXXXX] | | | (e.g., | |
o Applications that use this media type: DOTS agents sending DOTS | | | changing the | |
messages over CoAP over (D)TLS. | | | network path | |
o Fragment identifier considerations: N/A | | | to redirect | |
o Additional information: | | | the inbound | |
| | | traffic to a | |
| | | DOTS | |
| | | mitigator). | |
| 2 | attack-successfully-mitigated | Attack is | [RFCXXXX] |
| | | being | |
| | | successfully | |
| | | mitigated | |
| | | (e.g., | |
| | | traffic is | |
| | | redirected | |
| | | to a DDoS | |
| | | mitigator | |
| | | and attack | |
| | | traffic is | |
| | | dropped). | |
| 3 | attack-stopped | Attack has | [RFCXXXX] |
| | | stopped and | |
| | | the DOTS | |
| | | client can | |
| | | withdraw the | |
| | | mitigation | |
| | | request. | |
| 4 | attack-exceeded-capability | Attack has | [RFCXXXX] |
| | | exceeded the | |
| | | mitigation | |
| | | provider | |
| | | capability. | |
| 5 | dots-client-withdrawn-mitigation | DOTS client | [RFCXXXX] |
| | | has | |
| | | withdrawn | |
| | | the | |
| | | mitigation | |
| | | request and | |
| | | the | |
| | | mitigation | |
| | | is active | |
| | | but | |
| | | terminating. | |
| 6 | attack-mitigation-terminated | Attack | [RFCXXXX] |
| | | mitigation | |
| | | is now | |
| | | terminated. | |
| 7 | attack-mitigation-withdrawn | Attack | [RFCXXXX] |
| | | mitigation | |
| | | is | |
| | | withdrawn. | |
| 8 | attack-mitigation-signal-loss | Attack | [RFCXXXX] |
| | | mitigation | |
| | | will be | |
| | | triggered | |
| | | for the | |
| | | mitigation | |
| | | request only | |
| | | when the | |
| | | DOTS signal | |
| | | channel | |
| | | session is | |
| | | lost. | |
+-----+----------------------------------+--------------+-----------+
Magic number(s): N/A New codes can be assigned via Standards Action [RFC8126].
File extension(s): N/A
Macintosh file type code(s): N/A
o Person & email address to contact for further information:
IESG, iesg@ietf.org
o Intended usage: COMMON
o Restrictions on usage: none
o Author: Tirumaleswar Reddy, kondtir@gmail.com
o Change controller: IESG
o Provisional registration? No
9.5. CoAP Content-Formats Registration 9.6.3. Conflict Status Codes Sub-Registry
This section registers the CoAP Content-Format ID for the The document requests IANA to create a new sub-registry, entitled
"application/dots+cbor" media type in the "CoAP Content-Formats" "DOTS Signal Channel Conflict Status Codes". Codes in this registry
registry [IANA.CoAP.Content-Formats]. are used as valid values of 'conflict-status' parameter.
9.5.1. Registry Contents The registry is initially populated with the following values:
o Media Type: application/dots+cbor +------+-------------------------------+----------------+-----------+
o Encoding: - | Code | Label | Description | Reference |
o Id: TBD +------+-------------------------------+----------------+-----------+
o Reference: [RFCXXXX] | 1 | request-inactive-other-active | DOTS server | [RFCXXXX] |
| | | has detected | |
| | | conflicting | |
| | | mitigation | |
| | | requests from | |
| | | different DOTS | |
| | | clients. This | |
| | | mitigation | |
| | | request is | |
| | | currently | |
| | | inactive until | |
| | | the conflicts | |
| | | are resolved. | |
| | | Another | |
| | | mitigation | |
| | | request is | |
| | | active. | |
| 2 | request-active | DOTS server | [RFCXXXX] |
| | | has detected | |
| | | conflicting | |
| | | mitigation | |
| | | requests from | |
| | | different DOTS | |
| | | clients. This | |
| | | mitigation | |
| | | request is | |
| | | currently | |
| | | active. | |
| 3 | all-requests-inactive | DOTS server | [RFCXXXX] |
| | | has detected | |
| | | conflicting | |
| | | mitigation | |
| | | requests from | |
| | | different DOTS | |
| | | clients. All | |
| | | conflicting | |
| | | mitigation | |
| | | requests are | |
| | | inactive. | |
+------+-------------------------------+----------------+-----------+
9.6. CBOR Tag registration New codes can be assigned via Standards Action [RFC8126].
This section defines the DOTS CBOR tag as another means for 9.6.4. Conflict Cause Codes Sub-Registry
applications to declare that a CBOR data structure is a DOTS signal
channel object. Its use is optional and is intended for use in cases
in which this information would not otherwise be known. DOTS CBOR
tag is not required for DOTS signal channel protocol version "v1.0".
If present, the DOTS tag MUST prefix a DOTS signal channel object.
This section registers the DOTS signal channel CBOR tag in the "CBOR The document requests IANA to create a new sub-registry, entitled
Tags" registry [IANA.CBOR.Tags]. "DOTS Signal Channel Conflict Cause Codes". Codes in this registry
are used as valid values of 'conflict-cause' parameter.
9.6.1. Registry Contents The registry is initially populated with the following values:
o CBOR Tag: TBD (please assign the same value as the Content-Format) +------+--------------------------+---------------------+-----------+
o Data Item: DDoS Open Threat Signaling (DOTS) signal channel object | Code | Label | Description | Reference |
o Semantics: DDoS Open Threat Signaling (DOTS) signal channel +------+--------------------------+---------------------+-----------+
object, as defined in [RFCXXXX] | 1 | overlapping-targets | Overlapping | [RFCXXXX] |
o Description of Semantics: [RFCXXXX] | | | targets. | |
o Point of Contact: Tirumaleswar Reddy, kondtir@gmail.com | 2 | conflict-with-acceptlist | Conflicts with an | [RFCXXXX] |
| | | existing accept- | |
| | | list. This code is | |
| | | returned when the | |
| | | DDoS mitigation | |
| | | detects source | |
| | | addresses/prefixes | |
| | | in the accept- | |
| | | listed ACLs are | |
| | | attacking the | |
| | | target. | |
| 3 | cuid-collision | CUID Collision. | [RFCXXXX] |
| | | This code is | |
| | | returned when a | |
| | | DOTS client uses a | |
| | | 'cuid' that is | |
| | | already used by | |
| | | another DOTS | |
| | | client. | |
+------+--------------------------+---------------------+-----------+
9.7. DOTS Signal Channel YANG Module New codes can be assigned via Standards Action [RFC8126].
This document requests IANA to register the following URI in the 9.6.5. Attack Status Codes Sub-Registry
"IETF XML Registry" [RFC3688]:
The document requests IANA to create a new sub-registry, entitled
"DOTS Signal Channel Attack Status Codes". Codes in this registry
are used as valid values of 'attack-status' parameter.
The registry is initially populated with the following values:
+------+-------------------------------+----------------+-----------+
| Code | Label | Description | Reference |
+------+-------------------------------+----------------+-----------+
| 1 | under-attack | The DOTS | [RFCXXXX] |
| | | client | |
| | | determines | |
| | | that it is | |
| | | still under | |
| | | attack. | |
| 2 | attack-successfully-mitigated | The DOTS | [RFCXXXX] |
| | | client | |
| | | determines | |
| | | that the | |
| | | attack is | |
| | | successfully | |
| | | mitigated. | |
+------+-------------------------------+----------------+-----------+
New codes can be assigned via Standards Action [RFC8126].
9.7. DOTS Signal Channel YANG Modules
This document requests IANA to register the following URIs in the
"ns" subregistry within the "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 URI: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel
the "YANG Module Names" registry [RFC7950]. Registrant Contact: IANA.
XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG modules in
the "YANG Module Names" subregistry [RFC7950] within the "YANG
Parameters" registry.
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
name: iana-signal
namespace: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel
prefix: iana-signal
reference: RFC XXXX
This document defines the initial version of the IANA-maintained
iana-dots-signal-channel YANG module. IANA is requested to add this
note:
Status, conflict status, conflict cause, and attack status values
must not be directly added to the iana-dots-signal-channel YANG
module. They must instead be respectively added to the "DOTS
Status Codes", "DOTS Conflict Status Codes", "DOTS Conflict Cause
Codes", and "DOTS Attack Status Codes" registries.
When a 'status', 'conflict-status', 'conflict-cause', or 'attack-
status' value is respectively added to the "DOTS Status Codes", "DOTS
Conflict Status Codes", "DOTS Conflict Cause Codes", or "DOTS Attack
Status Codes" registry, a new "enum" statement must be added to the
iana-dots-signal-channel YANG module. The following "enum"
statement, and substatements thereof, should be defined:
"enum": Replicates the label from the registry.
"value": Contains the IANA-assigned value corresponding to the
'status', 'conflict-status', 'conflict-cause', or
'attack-status'.
"description": Replicates the description from the registry.
"reference": Replicates the reference from the registry and add the
title of the document.
When the iana-dots-signal-channel YANG module is updated, a new
"revision" statement must be added in front of the existing revision
statements.
IANA is requested to add this note to "DOTS Status Codes", "DOTS
Conflict Status Codes", "DOTS Conflict Cause Codes", and "DOTS Attack
Status Codes" registries:
When this registry is modified, the YANG module iana-dots-signal-
channel must be updated as defined in [RFCXXXX].
10. Security Considerations 10. Security Considerations
Authenticated encryption MUST be used for data confidentiality and Authenticated encryption MUST be used for data confidentiality and
message integrity. The interaction between the DOTS agents requires message integrity. The interaction between the DOTS agents requires
Datagram Transport Layer Security (DTLS) and Transport Layer Security Datagram Transport Layer Security (DTLS) and Transport Layer Security
(TLS) with a cipher suite offering confidentiality protection and the (TLS) with a cipher suite offering confidentiality protection and the
guidance given in [RFC7525] MUST be followed to avoid attacks on guidance given in [RFC7525] MUST be followed to avoid attacks on
(D)TLS. The (D)TLS protocol profile for DOTS signal channel is (D)TLS. The (D)TLS protocol profile for DOTS signal channel is
specified in Section 7. specified in Section 7.
skipping to change at page 84, line 16 skipping to change at page 91, line 32
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
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>. June 2014, <https://www.rfc-editor.org/info/rfc7250>.
skipping to change at page 85, line 14 skipping to change at page 92, line 34
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets", Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018, RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>. <https://www.rfc-editor.org/info/rfc8323>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
13.2. Informative References 13.2. Informative References
[I-D.boucadair-core-hop-limit]
Boucadair, M., Reddy, T., and J. Shallow, "Constrained
Application Protocol (CoAP) Hop Limit Option", draft-
boucadair-core-hop-limit-00 (work in progress), August
2018.
[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-03 (work in Management Interface", draft-ietf-core-comi-04 (work in
progress), June 2018. progress), November 2018.
[I-D.ietf-core-hop-limit]
Boucadair, M., K, R., and J. Shallow, "Constrained
Application Protocol (CoAP) Hop Limit Option", draft-ietf-
core-hop-limit-02 (work in progress), December 2018.
[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-06 (work in progress), February draft-ietf-core-yang-cbor-07 (work in progress), September
2018. 2018.
[I-D.ietf-dots-architecture] [I-D.ietf-dots-architecture]
Mortensen, A., Andreasen, F., Reddy, T., Mortensen, A., Andreasen, F., K, R., Teague, N., Compton,
christopher_gray3@cable.comcast.com, c., Compton, R., and R., and c. christopher_gray3@cable.comcast.com,
N. Teague, "Distributed-Denial-of-Service Open Threat "Distributed-Denial-of-Service Open Threat Signaling
Signaling (DOTS) Architecture", draft-ietf-dots- (DOTS) Architecture", draft-ietf-dots-architecture-10
architecture-07 (work in progress), September 2018. (work in progress), December 2018.
[I-D.ietf-dots-data-channel] [I-D.ietf-dots-data-channel]
Boucadair, M., Reddy, T., Nishizuka, K., Xia, L., Patil, Boucadair, M., K, R., Nishizuka, K., Xia, L., Patil, P.,
P., Mortensen, A., and N. Teague, "Distributed Denial-of- Mortensen, A., and N. Teague, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Data Channel Service Open Threat Signaling (DOTS) Data Channel
Specification", draft-ietf-dots-data-channel-19 (work in Specification", draft-ietf-dots-data-channel-23 (work in
progress), September 2018. progress), November 2018.
[I-D.ietf-dots-requirements] [I-D.ietf-dots-requirements]
Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed Mortensen, A., Moskowitz, R., and R. K, "Distributed
Denial of Service (DDoS) Open Threat Signaling Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-15 (work in Requirements", draft-ietf-dots-requirements-16 (work in
progress), August 2018. progress), October 2018.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
Open Threat Signaling", draft-ietf-dots-use-cases-16 (work Open Threat Signaling", draft-ietf-dots-use-cases-16 (work
in progress), July 2018. in progress), July 2018.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-28 (work in progress), July 1.3", draft-ietf-tls-dtls13-30 (work in progress),
2018. November 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,
 End of changes. 132 change blocks. 
462 lines changed or deleted 759 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/