< draft-ietf-dots-signal-channel-09.txt   draft-ietf-dots-signal-channel-10.txt >
DOTS T. Reddy DOTS T. Reddy
Internet-Draft McAfee Internet-Draft McAfee
Intended status: Standards Track M. Boucadair Intended status: Standards Track M. Boucadair
Expires: May 31, 2018 Orange Expires: June 3, 2018 Orange
P. Patil P. Patil
Cisco Cisco
A. Mortensen A. Mortensen
Arbor Networks, Inc. Arbor Networks, Inc.
N. Teague N. Teague
Verisign, Inc. Verisign, Inc.
November 27, 2017 November 30, 2017
Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel Channel
draft-ietf-dots-signal-channel-09 draft-ietf-dots-signal-channel-10
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 2, line 12 skipping to change at page 2, line 12
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 May 31, 2018. This Internet-Draft will expire on June 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 36
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions and Terminology . . . . . . . . . . . 5 2. Notational Conventions and Terminology . . . . . . . . . . . 5
3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 5 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 5
4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 7 4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 7
4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 7 4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 7
4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 8 4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 8
4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 9 4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 9
4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 10 4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 10
4.4.2. Withdraw a Mitigation . . . . . . . . . . . . . . . . 18 4.4.2. Withdraw a Mitigation . . . . . . . . . . . . . . . . 18
4.4.3. Retrieve Information Related to a Mitigation . . . . 19 4.4.3. Retrieve Information Related to a Mitigation . . . . 19
4.4.4. Efficacy Update from DOTS Clients . . . . . . . . . . 25 4.4.4. Efficacy Update from DOTS Clients . . . . . . . . . . 26
4.5. DOTS Signal Channel Session Configuration . . . . . . . . 27 4.5. DOTS Signal Channel Session Configuration . . . . . . . . 28
4.5.1. Discover Configuration Parameters . . . . . . . . . . 28 4.5.1. Discover Configuration Parameters . . . . . . . . . . 29
4.5.2. Convey DOTS Signal Channel Session Configuration . . 30 4.5.2. Convey DOTS Signal Channel Session Configuration . . 31
4.5.3. Delete DOTS Signal Channel Session Configuration . . 34 4.5.3. Delete DOTS Signal Channel Session Configuration . . 35
4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 35 4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 36
4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 36 4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 37
5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 37 5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 38
5.1. Mitigation Request YANG Module Tree Structure . . . . . . 37 5.1. Mitigation Request YANG Module Tree Structure . . . . . . 38
5.2. Mitigation Request YANG Module . . . . . . . . . . . . . 38 5.2. Mitigation Request YANG Module . . . . . . . . . . . . . 39
5.3. Session Configuration YANG Module Tree Structure . . . . 41 5.3. Session Configuration YANG Module Tree Structure . . . . 46
5.4. Session Configuration YANG Module . . . . . . . . . . . . 41 5.4. Session Configuration YANG Module . . . . . . . . . . . . 46
6. Mapping Parameters to CBOR . . . . . . . . . . . . . . . . . 44 6. Mapping Parameters to CBOR . . . . . . . . . . . . . . . . . 48
7. (D)TLS Protocol Profile and Performance Considerations . . . 45 7. (D)TLS Protocol Profile and Performance Considerations . . . 50
7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 46 7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 50
7.2. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 47 7.2. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 51
8. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . . . 48 8. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . . . 52
9. Mutual Authentication of DOTS Agents & Authorization of DOTS 9. Mutual Authentication of DOTS Agents & Authorization of DOTS
Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
10.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . 50 10.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . 54
10.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . 50 10.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . 54
10.3. CoAP Response Code . . . . . . . . . . . . . . . . . . . 50 10.3. CoAP Response Code . . . . . . . . . . . . . . . . . . . 54
10.4. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 51 10.4. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 55
10.4.1. Registration Template . . . . . . . . . . . . . . . 51 10.4.1. Registration Template . . . . . . . . . . . . . . . 55
10.4.2. Initial Registry Contents . . . . . . . . . . . . . 51 10.4.2. Initial Registry Contents . . . . . . . . . . . . . 55
10.5. YANG Modules . . . . . . . . . . . . . . . . . . . . . . 56 10.5. YANG Modules . . . . . . . . . . . . . . . . . . . . . . 60
11. Implementation Status . . . . . . . . . . . . . . . . . . . . 56 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 61
11.1. nttdots . . . . . . . . . . . . . . . . . . . . . . . . 57 11.1. nttdots . . . . . . . . . . . . . . . . . . . . . . . . 61
12. Security Considerations . . . . . . . . . . . . . . . . . . . 57 12. Security Considerations . . . . . . . . . . . . . . . . . . . 62
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 58 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 63
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 58 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 63
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 63
15.1. Normative References . . . . . . . . . . . . . . . . . . 59 15.1. Normative References . . . . . . . . . . . . . . . . . . 63
15.2. Informative References . . . . . . . . . . . . . . . . . 60 15.2. Informative References . . . . . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68
1. Introduction 1. Introduction
A distributed denial-of-service (DDoS) attack is an attempt to make A distributed denial-of-service (DDoS) attack is an attempt to make
machines or network resources unavailable to their intended users. machines or network resources unavailable to their intended users.
In most cases, sufficient scale can be achieved by compromising In most cases, sufficient scale can be achieved by compromising
enough end-hosts and using those infected hosts to perpetrate and enough end-hosts and using those infected hosts to perpetrate and
amplify the attack. The victim in this attack can be an application amplify the attack. The victim in this attack can be an application
server, a host, a router, a firewall, or an entire network. server, a host, a router, a firewall, or an entire network.
skipping to change at page 4, line 24 skipping to change at page 4, line 24
determine the causes of an attack, but instead just realize that determine the causes of an attack, but instead just realize that
certain resources seem to be under attack. This document defines a certain resources seem to be under attack. This document defines a
lightweight protocol permitting a DOTS client to request mitigation lightweight protocol permitting a DOTS client to request mitigation
from one or more DOTS servers for protection against detected, from one or more DOTS servers for protection against detected,
suspected, or anticipated attacks. This protocol enables cooperation suspected, or anticipated attacks. This protocol enables cooperation
between DOTS agents to permit a highly-automated network defense that between DOTS agents to permit a highly-automated network defense that
is robust, reliable and secure. is robust, reliable and secure.
An example of network diagram showing a deployment of DOTS agents is An example of network diagram showing a deployment of DOTS agents is
shown in Figure 1. In this example, the DOTS server is operating on shown in Figure 1. In this example, the DOTS server is operating on
the access network. the access network. The DOTS client is located on the LAN (Local
Area Network), while a DOTS gateway is embedded in the CPE (Customer
Premises Equipment).
Network Network
Resource CPE router Access network __________ Resource CPE router Access network __________
+-----------+ +--------------+ +-------------+ / \ +-----------+ +--------------+ +-------------+ / \
| |____| |_______| |___ | Internet | | |____| |_______| |___ | Internet |
|DOTS client| | DOTS gateway | | DOTS server | | | |DOTS client| | DOTS gateway | | DOTS server | | |
| | | | | | | | | | | | | | | |
+-----------+ +--------------+ +-------------+ \__________/ +-----------+ +--------------+ +-------------+ \__________/
Figure 1: Sample DOTS Deployment (1) Figure 1: Sample DOTS Deployment (1)
The DOTS server can also be running on the Internet, as depicted in The DOTS server can also be running on the Internet, as depicted in
Figure 2. Figure 2.
Network DDoS mitigation Network DDoS mitigation
Resource CPE router __________ service Resource CPE router __________ service
+-----------+ +-------------+ / \ +-------------+ +-----------+ +-------------+ / \ +-------------+
| |____| |_______| |___ | | | |____| |_______| |___ | |
|DOTS client| |DOTS gateway | | Internet | | DOTS server | |DOTS client| |DOTS gateway | | Internet | | DOTS server |
| | | | | | | | | | | | | | | |
+-----------+ +-------------+ \__________/ +-------------+ +-----------+ +-------------+ \__________/ +-------------+
Figure 2: Sample DOTS Deployment (2) Figure 2: Sample DOTS Deployment (2)
In typical deployments, the DOTS client belongs to a different In typical deployments, the DOTS client belongs to a different
administrative domain than the DOTS server. For example, the DOTS administrative domain than the DOTS server. For example, the DOTS
client is a firewall protecting services owned and operated by an client is a firewall protecting services owned and operated by a
domain, while the DOTS server is owned and operated by a different domain, while the DOTS server is owned and operated by a different
domain providing DDoS mitigation services. That domain providing domain providing DDoS mitigation services. That domain providing
DDoS mitigation service might, or might not, also provide Internet DDoS mitigation service might, or might not, also provide Internet
access service to the website operator. access service to the website operator.
The DOTS server may (not) be co-located with the DOTS mitigator. In The DOTS server may (not) be co-located with the DOTS mitigator. In
typical deployments, the DOTS server belongs to the same typical deployments, the DOTS server belongs to the same
administrative domain as the mitigator. The DOTS client can administrative domain as the mitigator. The DOTS client can
communicate directly with the DOTS server or indirectly via a DOTS communicate directly with the DOTS server or indirectly via a DOTS
gateway. gateway.
skipping to change at page 7, line 23 skipping to change at page 7, line 24
for more details. for more details.
DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The DOTS agents MUST support GET, PUT, and DELETE CoAP methods. The
payload included in CoAP responses with 2.xx and 3.xx Response Codes payload included in CoAP responses with 2.xx and 3.xx Response Codes
MUST be of content type "application/cbor" (Section 5.5.1 of MUST be of content type "application/cbor" (Section 5.5.1 of
[RFC7252]). CoAP responses with 4.xx and 5.xx error Response Codes [RFC7252]). CoAP responses with 4.xx and 5.xx error Response Codes
MUST include a diagnostic payload (Section 5.5.2 of [RFC7252]). The MUST include a diagnostic payload (Section 5.5.2 of [RFC7252]). The
Diagnostic Payload may contain additional information to aid Diagnostic Payload may contain additional information to aid
troubleshooting. troubleshooting.
In deployments where multiple DOTS clients are enabled in a network
(owned by the same entity), the DOTS server may detect conflicting
mitigation requests from these clients. This document does not aim
to specify a comprehensive list of conditions under which a DOTS
server will characterize two mitigation requests from distinct DOTS
clients as conflicting, nor recommend a DOTS server behavior for
processing conflicting mitigation requests. Those considerations are
implementation- and deployment-specific. Nevertheless, the document
specifies the mechanisms to notify DOTS clients when conflicts occur,
including the conflict cause.
4. DOTS Signal Channel: Messages & Behaviors 4. DOTS Signal Channel: Messages & Behaviors
4.1. DOTS Server(s) Discovery 4.1. DOTS Server(s) Discovery
This document assumes that DOTS clients are provisioned with the This document assumes that DOTS clients are provisioned with the
reachability information of their DOTS server(s) using a variety of reachability information of their DOTS server(s) using a variety of
means (e.g., local configuration, or dynamic means such as DHCP). means (e.g., local configuration, or dynamic means such as DHCP).
These means are out of scope of this document. These means are out of scope of this document.
Likewise, it is out of scope of this document to specify the behavior Likewise, it is out of scope of this document to specify the behavior
to follow by a DOTS client to place its requests (e.g., contact all to follow by a DOTS client to place its requests (e.g., contact all
servers, select one server among the list) when multiple DOTS servers servers, select one server among the list) when multiple DOTS servers
are provisioned. are provisioned.
4.2. CoAP URIs 4.2. CoAP URIs
The DOTS server MUST support the use of the path-prefix of "/.well- The DOTS server MUST support the use of the path-prefix of "/.well-
known/" as defined in [RFC5785] and the registered name of "dots". known/" as defined in [RFC5785] and the registered name of "dots".
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. 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
desired DOTS operation.
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
| Operation | Operation path | Details | | Operation | Operation path | Details |
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
| Mitigation | /v1/mitigate | Section 4.4 | | Mitigation | /v1/mitigate | Section 4.4 |
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
| Session configuration | /v1/config | Section 4.5 | | Session configuration | /v1/config | Section 4.5 |
+-----------------------+----------------+-------------+ +-----------------------+----------------+-------------+
Table 1: Operations and their corresponding URIs Table 1: Operations and their corresponding URIs
skipping to change at page 11, line 35 skipping to change at page 11, line 35
], ],
"target-port-range": [ "target-port-range": [
{ {
"lower-port": integer, "lower-port": integer,
"upper-port": integer "upper-port": integer
} }
], ],
"target-protocol": [ "target-protocol": [
integer integer
], ],
"fqdn": [ "target-fqdn": [
"string" "string"
], ],
"uri": [ "target-uri": [
"string" "string"
], ],
"alias-name": [ "alias-name": [
"string" "string"
], ],
"lifetime": integer "lifetime": integer
} }
] ]
} }
} }
skipping to change at page 12, line 51 skipping to change at page 12, line 51
port. For TCP, UDP, Stream Control Transmission Protocol (SCTP) port. For TCP, UDP, Stream Control Transmission Protocol (SCTP)
[RFC4960], or Datagram Congestion Control Protocol (DCCP) [RFC4960], or Datagram Congestion Control Protocol (DCCP)
[RFC4340]: the range of ports (e.g., 1024-65535). This is an [RFC4340]: the range of ports (e.g., 1024-65535). This is an
optional attribute. optional attribute.
target-protocol: A list of protocols under attack. Values are taken target-protocol: A list of protocols under attack. Values are taken
from the IANA protocol registry [proto_numbers]. The value 0 has from the IANA protocol registry [proto_numbers]. The value 0 has
a special meaning for 'all protocols'. This is an optional a special meaning for 'all protocols'. This is an optional
attribute. attribute.
fqdn: A list of Fully Qualified Domain Names. Fully Qualified target-fqdn: A list of Fully Qualified Domain Names. Fully
Domain Name (FQDN) is the full name of a system, rather than just Qualified Domain Name (FQDN) is the full name of a system, rather
its hostname. For example, "venera" is a hostname, and than just its hostname. For example, "venera" is a hostname, and
"venera.isi.edu" is an FQDN. This is an optional attribute. "venera.isi.edu" is an FQDN. This is an optional attribute.
uri: A list of Uniform Resource Identifiers (URI). This is an target-uri: A list of Uniform Resource Identifiers (URI). This is
optional attribute. an optional attribute.
alias-name: A list of aliases. Aliases can be created using the alias-name: A list of aliases. Aliases can be created using the
DOTS data channel (Section 3.1.1 of [I-D.ietf-dots-data-channel]) DOTS data channel (Section 3.1.1 of [I-D.ietf-dots-data-channel])
or direct configuration, or other means and then used in or direct configuration, or other means and then used in
subsequent signal channel exchanges to refer more efficiently to subsequent signal channel exchanges to refer more efficiently to
the resources under attack. This is an optional attribute. the resources under attack. This is an optional attribute.
lifetime: Lifetime of the mitigation request in seconds. The lifetime: Lifetime of the mitigation request in seconds. The
RECOMMENDED lifetime of a mitigation request is 3600 seconds (60 RECOMMENDED lifetime of a mitigation request is 3600 seconds (60
minutes) -- this value was chosen to be long enough so that minutes) -- this value was chosen to be long enough so that
skipping to change at page 13, line 47 skipping to change at page 13, line 47
The CBOR key values for the parameters are defined in Section 6. The CBOR key values for the parameters are defined in Section 6.
Section 10 defines how the CBOR key values can be allocated to Section 10 defines how the CBOR key values can be allocated to
standards bodies and vendors. standards bodies and vendors.
FQDN and URI mitigation scopes may be thought of as a form of scope FQDN and URI mitigation scopes may be thought of as a form of scope
alias, in which the addresses to which the domain name or URI resolve alias, in which the addresses to which the domain name or URI resolve
represent the full scope of the mitigation. represent the full scope of the mitigation.
In the PUT request at least one of the attributes 'target-ip' or In the PUT request at least one of the attributes 'target-ip' or
'target-prefix' or 'fqdn' or 'uri 'or 'alias-name' MUST be present. 'target-prefix' or 'target-fqdn' or 'target-uri 'or 'alias-name' MUST
If the attribute value is empty, then the attribute MUST NOT be be present. If the attribute value is empty, then the attribute MUST
present in the request. DOTS agents can safely ignore Vendor- NOT be present in the request. DOTS agents can safely ignore Vendor-
Specific parameters they don't understand. Specific parameters they don't understand.
The relative order of two mitigation requests from a DOTS client is The relative order of two mitigation requests from a DOTS client is
determined by comparing their respective 'mitigation-id' values. If determined by comparing their respective 'mitigation-id' values. If
two mitigation requests have overlapping mitigation scopes, the two mitigation requests have overlapping mitigation scopes, the
mitigation request with higher numeric 'mitigation-id' value will mitigation request with higher numeric 'mitigation-id' value will
override the mitigation request with a lower numeric 'mitigation-id' override the mitigation request with a lower numeric 'mitigation-id'
value. Two mitigation-ids from a DOTS client are overlapping if value. Two mitigation-ids from a DOTS client are overlapping if
there is a common IP address, IP prefix, FQDN, URI, or alias-name. there is a common IP address, IP prefix, FQDN, URI, or alias-name.
To avoid maintaining a long list of overlapping mitigation requests To avoid maintaining a long list of overlapping mitigation requests
skipping to change at page 15, line 10 skipping to change at page 15, line 10
mitigation request were indeed created by the same DOTS client using mitigation request were indeed created by the same DOTS client using
the DOTS data channel session. If the aliases were not created by the DOTS data channel session. If the aliases were not created by
the DOTS client, the DOTS server returns 4.00 (Bad Request) in the the DOTS client, the DOTS server returns 4.00 (Bad Request) in the
response. response.
The DOTS server couples the DOTS signal channel sessions using the The DOTS server couples the DOTS signal channel sessions using the
DOTS client identity and the 'client-identifier' parameter value, and DOTS client identity and the 'client-identifier' parameter value, and
the DOTS server uses 'mitigation-id' parameter value to detect the DOTS server uses 'mitigation-id' parameter value to detect
duplicate mitigation requests. If the mitigation request contains duplicate mitigation requests. If the mitigation request contains
both alias-name and other parameters identifying the target resources both alias-name and other parameters identifying the target resources
(such as, 'target-ip', 'target-prefix', 'target-port-range', 'fqdn', (such as, 'target-ip', 'target-prefix', 'target-port-range', 'target-
or 'uri'), then the DOTS server appends the parameter values in fqdn', or 'target-uri'), then the DOTS server appends the parameter
'alias-name' with the corresponding parameter values in 'target-ip', values in 'alias-name' with the corresponding parameter values in
'target-prefix', 'target-port-range', 'fqdn', or 'uri'. 'target-ip', 'target-prefix', 'target-port-range', 'target-fqdn', or
'target-uri'.
Figure 6 shows a PUT request example to signal that ports 80, 8080, Figure 6 shows a PUT request example to signal that ports 80, 8080,
and 443 on the servers 2001:db8:6401::1 and 2001:db8:6401::2 are and 443 on the servers 2001:db8:6401::1 and 2001:db8:6401::2 are
being attacked (illustrated in JSON diagnostic notation). being attacked (illustrated in JSON diagnostic notation).
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Host: "www.example.com" Uri-Host: "www.example.com"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "v1" Uri-Path: "v1"
skipping to change at page 15, line 52 skipping to change at page 16, line 4
{ {
"lower-port": 443 "lower-port": 443
}, },
{ {
"lower-port": 8080 "lower-port": 8080
} }
], ],
"target-protocol": [ "target-protocol": [
6 6
] ]
}
}
] ]
} }
} }
The CBOR encoding format is shown below: The CBOR encoding format is shown below:
A1 # map(1) A1 # map(1)
01 # unsigned(1) 01 # unsigned(1)
A2 # map(2) A2 # map(2)
18 20 # unsigned(32) 18 20 # unsigned(32)
skipping to change at page 17, line 40 skipping to change at page 17, line 42
If the DOTS server finds the 'mitigation-id' parameter value conveyed If the DOTS server finds the 'mitigation-id' parameter value conveyed
in the PUT request in its configuration data, then the server MAY in the PUT request in its configuration data, then the server MAY
update the mitigation request, and a 2.04 (Changed) response is update the mitigation request, and a 2.04 (Changed) response is
returned to indicate a successful update of the mitigation request. returned to indicate a successful update of the mitigation request.
If the request is missing one or more mandatory attributes, then 4.00 If the request is missing one or more mandatory attributes, then 4.00
(Bad Request) will be returned in the response or if the request (Bad Request) will be returned in the response or if the request
contains invalid or unknown parameters then 4.02 (Invalid query) is contains invalid or unknown parameters then 4.02 (Invalid query) is
returned in the response. returned in the response.
If the request is conflicting with an existing mitigation request
from a different DOTS client, and the DOTS server decides to maintain
the conflicting mitigation request, the DOTS server returns 4.09
(Conflict) [RFC8132] to the requesting DOTS client.
For a mitigation request to continue beyond the initial negotiated For a mitigation request to continue beyond the initial negotiated
lifetime, the DOTS client need to refresh the current mitigation lifetime, the DOTS client need to refresh the current mitigation
request by sending a new PUT request. The PUT request MUST use the request by sending a new PUT request. The PUT request MUST use the
same 'mitigation-id' value, and MUST repeat all the other parameters same 'mitigation-id' value, and MUST repeat all the other parameters
as sent in the original mitigation request apart from a possible as sent in the original mitigation request apart from a possible
change to the lifetime parameter value. change to the lifetime parameter value.
A DOTS gateway MUST update the 'client-identifier' list in the A DOTS gateway MUST update the 'client-identifier' list in the
response to remove the 'client-identifier' value it had added in the response to remove the 'client-identifier' value it had added in the
corresponding request before forwarding the response to the DOTS corresponding request before forwarding the response to the DOTS
skipping to change at page 21, line 40 skipping to change at page 21, line 40
"bps-dropped": 0, "bps-dropped": 0,
"pkts-dropped": 0, "pkts-dropped": 0,
"pps-dropped": 0 "pps-dropped": 0
} }
] ]
} }
} }
Figure 10: Response body Figure 10: Response body
The mitigation status parameters are described below. The mitigation status parameters are described below:
lifetime: The remaining lifetime of the mitigation request in
seconds.
mitigation-start: Mitigation start time is represented in seconds mitigation-start: Mitigation start time is represented in seconds
relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of
[RFC7049]). The encoding is modified so that the leading tag 1 [RFC7049]). The encoding is modified so that the leading tag 1
(epoch-based date/time) MUST be omitted. (epoch-based date/time) MUST be omitted.
lifetime: The remaining lifetime of the mitigation request in
seconds.
status: Status of attack mitigation. The 'status' parameter is a
mandatory attribute. The various possible values of 'status'
parameter are explained in Table 2.
conflict-information: Indicates that a mitigation request is
conflicting with another mitigation request(s) from other DOTS
client(s). This optional attribute has the following structure:
conflict-status: Indicates the status of a conflicting mitigation
request. The following values are defined:
1: 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.
2: DOTS Server has detected conflicting mitigation requests
from different DOTS clients. This mitigation request is
currently active.
3: DOTS Server has detected conflicting mitigation requests
from different DOTS clients. All conflicting mitigation
requests are inactive.
conflict-cause: Indicates the cause of the conflict. The
following values are defined:
1: Overlapping target prefixes
2: Conflicts with an existing white list
retry-timer Indicates, in seconds, the time upon which the DOTS
client may re-issue the same request. Any retransmission of
the same mitigation request before the expiry of this timer
will be discarded by the DOTS server.
bytes-dropped: The total dropped byte count for the mitigation bytes-dropped: The total dropped byte count for the mitigation
request since the attack mitigation is triggered. The count wraps request since the attack mitigation is triggered. The count wraps
around when it reaches the maximum value of unsigned integer. around when it reaches the maximum value of unsigned integer.
This is an optional attribute. This is an optional attribute.
bps-dropped: The average dropped bytes per second for the mitigation bps-dropped: The average dropped bytes per second for the mitigation
request since the attack mitigation is triggered. This SHOULD be request since the attack mitigation is triggered. This SHOULD be
a five-minute average. This is an optional attribute. a five-minute average. This is an optional attribute.
pkts-dropped: The total dropped packet count for the mitigation pkts-dropped: The total dropped packet count for the mitigation
request since the attack mitigation is triggered. This is an request since the attack mitigation is triggered. This is an
optional attribute. optional attribute.
pps-dropped: The average dropped packets per second for the pps-dropped: The average dropped packets per second for the
mitigation request since the attack mitigation is triggered. This mitigation request since the attack mitigation is triggered. This
SHOULD be a five-minute average. This is an optional attribute. SHOULD be a five-minute average. This is an optional attribute.
status: Status of attack mitigation. The 'status' parameter is a
mandatory attribute.
The various possible values of 'status' parameter are explained in
Table 2.
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Parameter | Description | | Parameter | Description |
| value | | | value | |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 1 | Attack mitigation is in progress (e.g., changing the | | 1 | Attack mitigation is in progress (e.g., changing the |
| | network path to re-route the inbound traffic to DOTS | | | network path to re-route the inbound traffic to DOTS |
| | mitigator). | | | mitigator). |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 2 | Attack is successfully mitigated (e.g., traffic is | | 2 | Attack is successfully mitigated (e.g., traffic is |
| | redirected to a DDOS mitigator and attack traffic is | | | redirected to a DDOS mitigator and attack traffic is |
| | dropped). | | | dropped). |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 3 | Attack has stopped and the DOTS client an withdraw | | 3 | Attack has stopped and the DOTS client can withdraw |
| | the mitigation request. | | | the mitigation request. |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 4 | Attack has exceeded the mitigation provider | | 4 | Attack has exceeded the mitigation provider |
| | capability. | | | capability. |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 5 | DOTS client has withdrawn the mitigation request and | | 5 | DOTS client has withdrawn the mitigation request and |
| | the mitigation is active but terminating. | | | the mitigation is active but terminating. |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 6 | Attack mitigation is now terminated. |
+-----------+-------------------------------------------------------+
| 7 | Attack mitigation is withdrawn. |
+-----------+-------------------------------------------------------+
| 8 | Attack mitigation is rejected. |
+-----------+-------------------------------------------------------+
Table 2: Values of 'status' parameter Table 2: Values of 'status' parameter
The observe option defined in [RFC7641] extends the CoAP core The observe option defined in [RFC7641] extends the CoAP core
protocol with a mechanism for a CoAP client to "observe" a resource protocol with a mechanism for a CoAP client to "observe" a resource
on a CoAP server: the client retrieves a representation of the on a CoAP server: the client retrieves a representation of the
resource and requests this representation be updated by the server as resource and requests this representation be updated by the server as
long as the client is interested in the resource. A DOTS client long as the client is interested in the resource. A DOTS client
conveys the observe option set to '0' in the GET request to receive conveys the observe option set to '0' in the GET request to receive
unsolicited notifications of attack mitigation status from the DOTS unsolicited notifications of attack mitigation status from the DOTS
skipping to change at page 23, line 19 skipping to change at page 24, line 5
channel allows unsolicited message delivery, enabling asynchronous channel allows unsolicited message delivery, enabling asynchronous
notifications between the agents. Due to the higher likelihood of notifications between the agents. Due to the higher likelihood of
packet loss during a DDoS attack, DOTS server periodically sends packet loss during a DDoS attack, DOTS server periodically sends
attack mitigation status to the DOTS client and also notifies the attack mitigation status to the DOTS client and also notifies the
DOTS client whenever the status of the attack mitigation changes. If DOTS client whenever the status of the attack mitigation changes. If
the DOTS server cannot maintain a RTT estimate, it SHOULD NOT send the DOTS server cannot maintain a RTT estimate, it SHOULD NOT send
more than one unsolicited notification every 3 seconds, and SHOULD more than one unsolicited notification every 3 seconds, and SHOULD
use an even less aggressive rate when possible (case 2 in use an even less aggressive rate when possible (case 2 in
Section 3.1.3 of [RFC8085]). Section 3.1.3 of [RFC8085]).
When conflicting requests are detected, the DOTS server enforces the
corresponding policy (e.g. accept all requests, reject all requests,
accept only one request but reject all the other, ...). It is
assumed that this policy is supplied by the DOTS server administrator
or it is a default behavior of the DOTS server implementation. Then,
the DOTS server sends notification message(s) to the DOTS client(s)
at the origin of the conflict. A conflict notification message
includes information about the conflict cause and the status of the
mitigation request(s). For example,
o A notification message with status code set to '8 (Attack
mitigation is rejected)' is sent to a DOTS client to indicate that
this mitigation request is rejected because a conflict is
detected.
o A notification message with status code set to '7 (Attack
mitigation is withdrawn)' is sent to a DOTS client to indicate
that an active mitigation request is deactivated because a
conflict is detected.
o A notification message with status code set to '1 (Attack
mitigation is in progress)' and 'conflict-status' set to 2 is sent
to a DOTS client to indicate that this mitigation request is in
progress, but a conflict is detected.
Upon receipt of a conflict notification message indicating that a
mitigation request is deactivated because of a conflict, a DOTS
client MUST NOT resend the same mitigation request before the expiry
of 'retry-timer'. It is also recommended that DOTS clients support
means to alert administrators about mitigation conflicts.
A DOTS client that is no longer interested in receiving notifications A DOTS client that is no longer interested in receiving notifications
from the DOTS server can simply "forget" the observation. When the from the DOTS server can simply "forget" the observation. When the
DOTS server then sends the next notification, the DOTS client will DOTS server then sends the next notification, the DOTS client will
not recognize the token in the message and thus will return a Reset not recognize the token in the message and thus will return a Reset
message. This causes the DOTS server to remove the associated entry. message. This causes the DOTS server to remove the associated entry.
Alternatively, the DOTS client can explicitly deregister by issuing a Alternatively, the DOTS client can explicitly deregister by issuing a
GET request that has the Token field set to the token of the GET request that has the Token field set to the token of the
observation to be cancelled and includes an Observe Option with the observation to be cancelled and includes an Observe Option with the
value set to '1' (deregister). value set to '1' (deregister).
skipping to change at page 26, line 12 skipping to change at page 27, line 12
the request is processed. If no match is found, the PUT request is the request is processed. If no match is found, the PUT request is
silently ignored. silently ignored.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Host: "host" Uri-Host: "host"
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "version" Uri-Path: "version"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Content-Format: "application/cbor" Content-Format: "application/cbor"
If-Match:
{ {
"mitigation-scope": { "mitigation-scope": {
"client-identifier": [ "client-identifier": [
"string" "string"
], ],
"scope": [ "scope": [
{ {
"mitigation-id": integer, "mitigation-id": integer,
"target-ip": [ "target-ip": [
"string" "string"
], ],
"target-port-range": [ "target-port-range": [
{ {
"lower-port": integer, "lower-port": integer,
"upper-port": integer "upper-port": integer
} }
], ],
"target-protocol": [ "target-protocol": [
integer integer
], ],
"fqdn": [ "target-fqdn": [
"string" "string"
], ],
"uri": [ "target-uri": [
"string" "string"
], ],
"alias-name": [ "alias-name": [
"string" "string"
], ],
"lifetime": integer, "lifetime": integer,
"attack-status": integer "attack-status": integer
} }
] ]
} }
skipping to change at page 37, line 17 skipping to change at page 38, line 17
o The DOTS client MUST NOT consider the DOTS session terminated even o The DOTS client MUST NOT consider the DOTS session terminated even
after maximum "missing-hb-allowed" threshold is reached. The DOTS after maximum "missing-hb-allowed" threshold is reached. The DOTS
client SHOULD continue to use the current DOTS session, and send client SHOULD continue to use the current DOTS session, and send
heartbeat requests over the current DOTS session, so the DOTS heartbeat requests over the current DOTS session, so the DOTS
server knows the DOTS client has not disconnected the DOTS server knows the DOTS client has not disconnected the DOTS
session. After the maximum "missing-hb-allowed" threshold is session. After the maximum "missing-hb-allowed" threshold is
reached, the DOTS client SHOULD try (D)TLS session resumption. reached, the DOTS client SHOULD try (D)TLS session resumption.
The DOTS client SHOULD send mitigation requests over the current The DOTS client SHOULD send mitigation requests over the current
DOTS session, and in parallel, try (D)TLS session resumption or DOTS session, and in parallel, try (D)TLS session resumption or
0-RTT mode in DTLS 1.3 to piggyback the mitigation request in the 0-RTT mode in DTLS 1.3 to piggyback the mitigation request in the
ClientHello message. Once the link is no longer statured, if ClientHello message. Once the link is no longer saturated, if
traffic from the DOTS server reaches the DOTS client over the traffic from the DOTS server reaches the DOTS client over the
current DOTS session, the DOTS client can stop (D)TLS session current DOTS session, the DOTS client can stop (D)TLS session
resumption or if (D)TLS session resumption is successful then resumption or if (D)TLS session resumption is successful then
disconnect the current DOTS session. disconnect the current DOTS session.
o If the DOTS server does not receive any traffic from the peer DOTS o If the DOTS server does not receive any traffic from the peer DOTS
client, then the DOTS server sends heartbeat requests to the DOTS client, then the DOTS server sends heartbeat requests to the DOTS
client and after maximum "missing-hb-allowed" threshold is client and after maximum "missing-hb-allowed" threshold is
reached, the DOTS server concludes the session is disconnected. reached, the DOTS server concludes the session is disconnected.
skipping to change at page 38, line 9 skipping to change at page 39, line 9
5.1. Mitigation Request YANG Module Tree Structure 5.1. Mitigation Request YANG Module Tree Structure
This document defines the YANG module "ietf-dots-signal" This document defines the YANG module "ietf-dots-signal"
(Section 5.2), which has the following tree structure: (Section 5.2), which has the following tree structure:
module: ietf-dots-signal module: ietf-dots-signal
+--rw mitigation-scope +--rw mitigation-scope
+--rw client-identifier* binary +--rw client-identifier* binary
+--rw scope* [mitigation-id] +--rw scope* [mitigation-id]
+--rw mitigation-id int32 +--rw mitigation-id int32
+--rw target-ip* inet:ip-address +--rw target-ip* inet:ip-address
+--rw target-prefix* inet:ip-prefix +--rw target-prefix* inet:ip-prefix
+--rw target-port-range* [lower-port upper-port] +--rw target-port-range* [lower-port upper-port]
| +--rw lower-port inet:port-number | +--rw lower-port inet:port-number
| +--rw upper-port inet:port-number | +--rw upper-port inet:port-number
+--rw target-protocol* uint8 +--rw target-protocol* uint8
+--rw fqdn* inet:domain-name +--rw target-fqdn* inet:domain-name
+--rw uri* inet:uri +--rw target-uri* inet:uri
+--rw alias-name* string +--rw alias-name* string
+--rw lifetime? int32 +--rw lifetime? int32
+--rw mitigation-start? int64
+--ro status? enumeration
+--ro conflict-information
| +--ro conflict-status? enumeration
| +--ro conflict-cause? enumeration
| +--ro retry-timer? int32
+--ro pkts-dropped? yang:zero-based-counter64
+--ro bps-dropped? yang:zero-based-counter64
+--ro bytes-dropped? yang:zero-based-counter64
+--ro pps-dropped? yang:zero-based-counter64
5.2. Mitigation Request YANG Module 5.2. Mitigation Request YANG Module
<CODE BEGINS> file "ietf-dots-signal@2017-11-27.yang" <CODE BEGINS> file "ietf-dots-signal@2017-12-01.yang"
module ietf-dots-signal { module ietf-dots-signal {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal"; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal";
prefix "signal"; prefix "signal";
import ietf-inet-types { import ietf-inet-types {prefix "inet";}
prefix "inet"; import ietf-yang-types {prefix yang; }
}
organization "IETF DOTS Working Group"; organization "IETF DOTS Working Group";
contact contact
"Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com> "Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>
Mohamed Boucadair <mohamed.boucadair@orange.com> Mohamed Boucadair <mohamed.boucadair@orange.com>
Prashanth Patil <praspati@cisco.com> Prashanth Patil <praspati@cisco.com>
Andrew Mortensen <amortensen@arbor.net> Andrew Mortensen <amortensen@arbor.net>
Nik Teague <nteague@verisign.com>"; Nik Teague <nteague@verisign.com>";
skipping to change at page 39, line 11 skipping to change at page 40, line 20
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2017-11-27 { revision 2017-12-01 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: A Distributed Denial-of-Service Open Threat "RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel"; Signaling (DOTS) Signal Channel";
} }
container mitigation-scope { container mitigation-scope {
description description
"Specifies the scope of the mitigation request."; "Specifies the scope of the mitigation request.";
leaf-list client-identifier { leaf-list client-identifier {
type binary; type binary;
description description
skipping to change at page 41, line 4 skipping to change at page 42, line 13
"Identifies the target protocol number. "Identifies the target protocol number.
The value '0' means 'all protocols'. The value '0' means 'all protocols'.
Values are taken from the IANA protocol registry: Values are taken from the IANA protocol registry:
https://www.iana.org/assignments/protocol-numbers/ https://www.iana.org/assignments/protocol-numbers/
protocol-numbers.xhtml protocol-numbers.xhtml
For example, 6 for a TCP or 17 for UDP."; For example, 6 for a TCP or 17 for UDP.";
} }
leaf-list fqdn {
leaf-list target-fqdn {
type inet:domain-name; type inet:domain-name;
description "FQDN"; description "FQDN";
} }
leaf-list uri { leaf-list target-uri {
type inet:uri; type inet:uri;
description "URI"; description "URI";
} }
leaf-list alias-name { leaf-list alias-name {
type string; type string;
description "alias name"; description "alias name";
} }
leaf lifetime { leaf lifetime {
type int32; type int32;
units "seconds"; units "seconds";
default 3600; default 3600;
description description
"Indicates the lifetime of the mitigation request."; "Indicates the lifetime of the mitigation request.";
} }
leaf mitigation-start {
type int64;
units "seconds";
description
"Mitigation start time is represented in seconds
relative to 1970-01-01T00:00Z in UTC time.";
}
leaf status {
type enumeration {
enum "1" {
description
"Attack mitigation is in progress (e.g., changing
the network path to re-route the inbound traffic
to DOTS mitigator).";
}
enum "2" {
description
"Attack is successfully mitigated (e.g., traffic
is redirected to a DDOS mitigator and attack
traffic is dropped).";
}
enum "3" {
description
"Attack has stopped and the DOTS client can
withdraw the mitigation request.";
}
enum "4" {
description
"Attack has exceeded the mitigation provider
capability.";
}
enum "5" {
description
"DOTS client has withdrawn the mitigation
request and the mitigation is active but
terminating.";
}
enum "6" {
description
"Attack mitigation is now terminated.";
}
enum "7" {
description
"Attack mitigation is withdrawn.";
}
enum "8" {
description
"Attack mitigation is rejected.";
}
}
config false;
description
"Indicates the status of a mitigation request.
It must be included in responses, only.";
}
container conflict-information {
config false;
description
"Indicates that a conflict is detected.
Must only be used for responses.";
leaf conflict-status {
type enumeration {
enum "1" {
description
"DOTS Server has detected conflicting mitigation
requests from different DOTS clients.
This mitigation request is currently inactive
until the conflicts are resolved. Another
mitigation request is active.";
}
enum "2" {
description
"DOTS Server has detected conflicting mitigation
requests from different DOTS clients.
This mitigation request is currently active.";
}
enum "3" {
description
"DOTS Server has detected conflicting mitigation
requests from different DOTS clients. All
conflicting mitigation requests are inactive.";
}
}
description
"Indicates the conflict status.
It must be included in responses, only.";
}
leaf conflict-cause {
type enumeration {
enum "1" {
description
"Overlapping target prefixes.";
}
enum "2" {
description
"Conflicts with an existing white list.";
}
}
description
"Indicates the cause of the conflict.
It must be included in responses, only.";
}
leaf retry-timer {
type int32;
units "seconds";
description
"The DOTS client must not re-send the
same request before the expiry of this timer.
It must be included in responses, only.";
}
}
leaf pkts-dropped {
type yang:zero-based-counter64;
config false;
description
"Number of dropped packets";
}
leaf bps-dropped {
type yang:zero-based-counter64;
config false;
description
"The average dropped bytes per second for
the mitigation request since the attack
mitigation is triggered.";
}
leaf bytes-dropped {
type yang:zero-based-counter64;
units 'bytes';
config false;
description
"Counter for dropped pacckets; in bytes.";
}
leaf pps-dropped {
type yang:zero-based-counter64;
config false;
description
"The average dropped packets per second
for the mitigation request since the attack
mitigation is triggered.";
}
}
} }
}
} }
<CODE ENDS> <CODE ENDS>
5.3. Session Configuration YANG Module Tree Structure 5.3. Session Configuration YANG Module Tree Structure
This document defines the YANG module "ietf-dots-signal-config" This document defines the YANG module "ietf-dots-signal-config"
(Section 5.4), which has the following structure: (Section 5.4), which has the following structure:
module: ietf-dots-signal-config module: ietf-dots-signal-config
+--rw signal-config +--rw signal-config
skipping to change at page 44, line 4 skipping to change at page 48, line 27
description description
"Random factor used to influence the timing of "Random factor used to influence the timing of
retransmissions."; retransmissions.";
} }
leaf trigger-mitigation { leaf trigger-mitigation {
type boolean; type boolean;
default true; default true;
description description
"If false, then mitigation is triggered "If false, then mitigation is triggered
only when the DOTS server channel session is lost"; only when the DOTS server channel session is lost";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
6. Mapping Parameters to CBOR 6. Mapping Parameters to CBOR
All parameters in the payload in the DOTS signal channel MUST be All parameters in the payload in the DOTS signal channel MUST be
mapped to CBOR types as shown in Table 4 and are given an integer key mapped to CBOR types as shown in Table 4 and are given an integer key
to save space. The recipient of the payload MAY reject the to save space. The recipient of the payload MAY reject the
information if it is not suitably mapped. information if it is not suitably mapped.
/--------------------+---------------------+--------------------------\ /----------------------+----------------+--------------------------\
| Parameter name | CBOR key | CBOR major type of value | | Parameter name | CBOR key | CBOR major type of value |
+--------------------+---------------------+--------------------------+ +----------------------+----------------+--------------------------+
| mitigation-scope | 1 | 5 (map) | | mitigation-scope | 1 | 5 (map) |
| scope | 2 | 5 (map) | | scope | 2 | 5 (map) |
| mitigation-id | 3 | 0 (unsigned) | | mitigation-id | 3 | 0 (unsigned) |
| target-ip | 4 | 4 (array) | | target-ip | 4 | 4 (array) |
| target-port-range | 5 | 4 | | target-port-range | 5 | 4 |
| lower-port | 6 | 0 | | lower-port | 6 | 0 |
| upper-port | 7 | 0 | | upper-port | 7 | 0 |
| target-protocol | 8 | 4 | | target-protocol | 8 | 4 |
| fqdn | 9 | 4 | | target-fqdn | 9 | 4 |
| uri | 10 | 4 | | target-uri | 10 | 4 |
| alias-name | 11 | 4 | | alias-name | 11 | 4 |
| lifetime | 12 | 0 | | lifetime | 12 | 0 |
| attack-status | 13 | 0 | | attack-status | 13 | 0 |
| signal-config | 14 | 5 | | signal-config | 14 | 5 |
| heartbeat-interval | 15 | 0 | | heartbeat-interval | 15 | 0 |
| max-retransmit | 16 | 0 | | max-retransmit | 16 | 0 |
| ack-timeout | 17 | 0 | | ack-timeout | 17 | 0 |
| ack-random-factor | 18 | 7 | | ack-random-factor | 18 | 7 |
| MinValue | 19 | 0 | | MinValue | 19 | 0 |
| MaxValue | 20 | 0 | | MaxValue | 20 | 0 |
| status | 21 | 0 | | status | 21 | 0 |
| bytes-dropped | 22 | 0 | | conflict-information | 22 | 5 (map) |
| bps-dropped | 23 | 0 | | conflict-status | 23 | 0 |
| pkts-dropped | 24 | 0 | | conflict-cause | 24 | 0 |
| pps-dropped | 25 | 0 | | retry-timer | 25 | 0 |
| session-id | 26 | 0 | | bytes-dropped | 26 | 0 |
| trigger-mitigation | 27 | 7 (simple types) | | bps-dropped | 27 | 0 |
| missing-hb-allowed | 28 | 0 | | pkts-dropped | 28 | 0 |
| CurrentValue | 29 | 0 | | pps-dropped | 29 | 0 |
| mitigation-start | 30 | 7 (floating-point) | | session-id | 30 | 0 |
| target-prefix | 31 | 4 (array) | | trigger-mitigation | 31 | 7 (simple types) |
| client-identifier | 32 | 2 (byte string) | | missing-hb-allowed | 32 | 0 |
| alt-server | 33 | 2 | | CurrentValue | 33 | 0 |
| alt-server-record | 34 | 4 | | mitigation-start | 34 | 7 (floating-point) |
| addr | 35 | 2 | | target-prefix | 35 | 4 (array) |
| ttl | 36 | 0 | | client-identifier | 36 | 2 (byte string) |
\--------------------+---------------------+--------------------------/ | alt-server | 37 | 2 |
Table 4: CBOR mappings used in DOTS signal channel message | alt-server-record | 38 | 4 |
| addr | 39 | 2 |
| ttl | 40 | 0 |
\----------------------+----------------+--------------------------/
Table 4: CBOR mappings used in DOTS signal channel message
7. (D)TLS Protocol Profile and Performance Considerations 7. (D)TLS Protocol Profile and Performance Considerations
7.1. (D)TLS Protocol Profile 7.1. (D)TLS Protocol Profile
This section defines the (D)TLS protocol profile of DOTS signal This section defines the (D)TLS protocol profile of DOTS signal
channel over (D)TLS and DOTS data channel over TLS. channel over (D)TLS and DOTS data channel over TLS.
There are known attacks on (D)TLS, such as machine-in-the-middle and There are known attacks on (D)TLS, such as machine-in-the-middle and
protocol downgrade. These are general attacks on (D)TLS and not protocol downgrade. These are general attacks on (D)TLS and not
specific to DOTS over (D)TLS; please refer to the (D)TLS RFCs for specific to DOTS over (D)TLS; please refer to the (D)TLS RFCs for
discussion of these security issues. DOTS agents MUST adhere to the discussion of these security issues. DOTS agents MUST adhere to the
(D)TLS implementation recommendations and security considerations of (D)TLS implementation recommendations and security considerations of
skipping to change at page 50, line 42 skipping to change at page 54, line 42
Specification document(s): This RFC Specification document(s): This RFC
Related information: None Related information: None
10.3. CoAP Response Code 10.3. CoAP Response Code
The following entry is added to the "CoAP Response Codes" sub- The following entry is added to the "CoAP Response Codes" sub-
registry: registry:
+------+-------------------+-----------+ +------+------------------+-----------+
| Code | Description | Reference | | Code | Description | Reference |
+------+-------------------+-----------+ +------+------------------+-----------+
| 3.00 | Alternate server | [RFCXXXX] | | 3.00 | Alternate server | [RFCXXXX] |
+------+-------------------+-----------+ +------+------------------+-----------+
Table 4: CoAP Response Code Table 4: CoAP Response Code
10.4. DOTS Signal Channel CBOR Mappings Registry 10.4. DOTS Signal Channel CBOR Mappings Registry
A new registry will be requested from IANA, entitled "DOTS signal A new registry will be requested from IANA, entitled "DOTS signal
channel CBOR Mappings Registry". The registry is to be created as channel CBOR Mappings Registry". The registry is to be created as
Expert Review Required. Expert Review Required.
10.4.1. Registration Template 10.4.1. Registration Template
skipping to change at page 52, line 36 skipping to change at page 56, line 36
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: target-protocol o Parameter Name: target-protocol
o CBOR Key Value: 8 o CBOR Key Value: 8
o CBOR Major Type: 4 o CBOR Major Type: 4
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: "fqdn" o Parameter Name: "target-fqdn"
o CBOR Key Value: 9 o CBOR Key Value: 9
o CBOR Major Type: 4 o CBOR Major Type: 4
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: "uri" o Parameter Name: "target-uri"
o CBOR Key Value: 10 o CBOR Key Value: 10
o CBOR Major Type: 4 o CBOR Major Type: 4
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: alias-name o Parameter Name: alias-name
o CBOR Key Value: 11 o CBOR Key Value: 11
o CBOR Major Type: 4 o CBOR Major Type: 4
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
skipping to change at page 54, line 18 skipping to change at page 58, line 18
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: status o Parameter Name: status
o CBOR Key Value: 21 o CBOR Key Value: 21
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: bytes-dropped o Parameter Name: conflict-information
o CBOR Key Value: 22 o CBOR Key Value: 22
o CBOR Major Type: 5
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: conflict-status
o CBOR Key Value: 23
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: conflict-cause
o CBOR Key Value: 24
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: retry-timer
o CBOR Key Value: 25
o CBOR Major Type: 0
o Change Controller: IESG
o Specification Document(s): this document
o Parameter Name: bytes-dropped
o CBOR Key Value: 26
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: bps-dropped o Parameter Name: bps-dropped
o CBOR Key Value: 23 o CBOR Key Value: 27
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: pkts-dropped o Parameter Name: pkts-dropped
o CBOR Key Value: 24 o CBOR Key Value: 28
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: pps-dropped o Parameter Name: pps-dropped
o CBOR Key Value: 25 o CBOR Key Value: 29
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: session-id o Parameter Name: session-id
o CBOR Key Value: 26 o CBOR Key Value: 30
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: trigger-mitigation o Parameter Name: trigger-mitigation
o CBOR Key Value: 27 o CBOR Key Value: 31
o CBOR Major Type: 7 o CBOR Major Type: 7
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: missing-hb-allowed o Parameter Name: missing-hb-allowed
o CBOR Key Value: 28 o CBOR Key Value: 32
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name: CurrentValue o Parameter Name: CurrentValue
o CBOR Key Value: 29 o CBOR Key Value: 33
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name:mitigation-start o Parameter Name:mitigation-start
o CBOR Key Value: 30 o CBOR Key Value: 34
o CBOR Major Type: 7 o CBOR Major Type: 7
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name:target-prefix o Parameter Name:target-prefix
o CBOR Key Value: 31 o CBOR Key Value: 35
o CBOR Major Type: 4 o CBOR Major Type: 4
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name:client-identifier o Parameter Name:client-identifier
o CBOR Key Value: 32 o CBOR Key Value: 36
o CBOR Major Type: 2 o CBOR Major Type: 2
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name:alt-server o Parameter Name:alt-server
o CBOR Key Value: 33 o CBOR Key Value: 37
o CBOR Major Type: 2 o CBOR Major Type: 2
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name:alt-server-record o Parameter Name:alt-server-record
o CBOR Key Value: 34 o CBOR Key Value: 38
o CBOR Major Type: 4 o CBOR Major Type: 4
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name:addr o Parameter Name:addr
o CBOR Key Value: 35 o CBOR Key Value: 39
o CBOR Major Type: 2 o CBOR Major Type: 2
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
o Parameter Name:ttl o Parameter Name:ttl
o CBOR Key Value: 36 o CBOR Key Value: 40
o CBOR Major Type: 0 o CBOR Major Type: 0
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): this document o Specification Document(s): this document
10.5. YANG Modules 10.5. YANG Modules
This document requests IANA to register the following URIs in the This document requests IANA to register the following URIs in the
"IETF XML Registry" [RFC3688]: "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal
skipping to change at page 57, line 28 skipping to change at page 62, line 4
DOTS server software based on DOTS signal channel specified in DOTS server software based on DOTS signal channel specified in
this draft. It will be open-sourced. this draft. It will be open-sourced.
Description: Early implementation of DOTS protocol. It is aimed to Description: Early implementation of DOTS protocol. It is aimed to
implement a full DOTS protocol spec in accordance with maturing of implement a full DOTS protocol spec in accordance with maturing of
DOTS protocol itself. DOTS protocol itself.
Implementation: https://github.com/nttdots/go-dots Implementation: https://github.com/nttdots/go-dots
Level of maturity: It is a early implementation of DOTS protocol. Level of maturity: It is a early implementation of DOTS protocol.
Messaging between DOTS clients and DOTS servers has been tested. Messaging between DOTS clients and DOTS servers has been tested.
Level of maturity will increase in accordance with maturing of Level of maturity will increase in accordance with maturing of
DOTS protocol itself. DOTS protocol itself.
Coverage: Capability of DOTS client: sending DOTS messages to the Coverage: Capability of DOTS client: sending DOTS messages to the
DOTS server in CoAP over DTLS as dots-signal. Capability of DOTS DOTS server in CoAP over DTLS as dots-signal. Capability of DOTS
server: receiving dots-signal, validating received dots-signal, server: receiving dots-signal, validating received dots-signal,
starting mitigation by handing over the dots-signal to DDOS starting mitigation by handing over the dots-signal to DDOS
mitigator. mitigator.
Licensing: It will be open-sourced with BSD 3-clause license. Licensing: It will be open-sourced with BSD 3-clause license.
Implementation experience: It is implemented in Go-lang. Core Implementation experience: It is implemented in Go-lang. Core
specification of signaling is mature to be implemented, however, specification of signaling is mature to be implemented, however,
finding good libraries(like DTLS, CoAP) is rather difficult. finding good libraries(like DTLS, CoAP) is rather difficult.
Contact: Kaname Nishizuka <kaname@nttv6.jp> Contact: Kaname Nishizuka <kaname@nttv6.jp>
12. Security Considerations 12. Security Considerations
Authenticated encryption MUST be used for data confidentiality and Authenticated encryption MUST be used for data confidentiality and
message integrity. (D)TLS based on client certificate MUST be used message integrity. The interaction between the DOTS agents requires
for mutual authentication. The interaction between the DOTS agents Datagram Transport Layer Security (DTLS) and Transport Layer Security
requires Datagram Transport Layer Security (DTLS) and Transport Layer (TLS) with a cipher suite offering confidentiality protection and the
Security (TLS) with a cipher suite offering confidentiality guidance given in [RFC7525] MUST be followed to avoid attacks on
protection and the guidance given in [RFC7525] MUST be followed to (D)TLS.
avoid attacks on (D)TLS.
A single DOTS signal channel between DOTS agents can be used to A single DOTS signal channel between DOTS agents can be used to
exchange multiple DOTS signal messages. To reduce DOTS client and exchange multiple DOTS signal messages. To reduce DOTS client and
DOTS server workload, DOTS client SHOULD re-use the (D)TLS session. DOTS server workload, DOTS client SHOULD re-use the (D)TLS session.
If TCP is used between DOTS agents, an attacker may be able to inject If TCP is used between DOTS agents, an attacker may be able to inject
RST packets, bogus application segments, etc., regardless of whether RST packets, bogus application segments, etc., regardless of whether
TLS authentication is used. Because the application data is TLS TLS authentication is used. Because the application data is TLS
protected, this will not result in the application receiving bogus protected, this will not result in the application receiving bogus
data, but it will constitute a DoS on the connection. This attack data, but it will constitute a DoS on the connection. This attack
skipping to change at page 58, line 48 skipping to change at page 63, line 23
Robert Moskowitz HTT Consulting Oak Park, MI 42837 United States Robert Moskowitz HTT Consulting Oak Park, MI 42837 United States
Email: rgm@htt-consult.com Email: rgm@htt-consult.com
Dan Wing Email: dwing-ietf@fuggles.com Dan Wing Email: dwing-ietf@fuggles.com
14. Acknowledgements 14. Acknowledgements
Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw, Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw,
Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang
Xia, Jon Shallow, and Gilbert Clark for the discussion and comments. Xia, Jon Shallow, Gilbert Clark, and Nesredien Suleiman for the
discussion and comments.
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-core-coap-tcp-tls] [I-D.ietf-core-coap-tcp-tls]
Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, "CoAP (Constrained Silverajan, B., and B. Raymor, "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets", Application Protocol) over TCP, TLS, and WebSockets",
draft-ietf-core-coap-tcp-tls-10 (work in progress), draft-ietf-core-coap-tcp-tls-10 (work in progress),
skipping to change at page 60, line 47 skipping to change at page 65, line 20
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and
FETCH Methods for the Constrained Application Protocol
(CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
<https://www.rfc-editor.org/info/rfc8132>.
15.2. Informative References 15.2. Informative References
[I-D.ietf-core-comi] [I-D.ietf-core-comi]
Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP
Management Interface", draft-ietf-core-comi-01 (work in Management Interface", draft-ietf-core-comi-01 (work in
progress), July 2017. progress), July 2017.
[I-D.ietf-core-yang-cbor] [I-D.ietf-core-yang-cbor]
Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A.
Minaburo, "CBOR Encoding of Data Modeled with YANG", Minaburo, "CBOR Encoding of Data Modeled with YANG",
 End of changes. 68 change blocks. 
162 lines changed or deleted 455 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/