< draft-ietf-dots-signal-channel-30.txt   draft-ietf-dots-signal-channel-31.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: September 6, 2019 Orange Expires: September 29, 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.
March 5, 2019 March 28, 2019
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-30 draft-ietf-dots-signal-channel-31
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 25 skipping to change at page 2, line 25
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 September 6, 2019. This Internet-Draft will expire on September 29, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 50 skipping to change at page 2, line 50
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6
4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 9 4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 9
4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . 10
4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 11 4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 11
4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 12 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 . . . . . 31 4.4.2.1. DOTS Servers Sending Mitigation Status . . . . . 32
4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 34 4.4.2.2. DOTS Clients Polling for Mitigation Status . . . 35
4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 35 4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 36
4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 37 4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 38
4.5. DOTS Signal Channel Session Configuration . . . . . . . . 38 4.5. DOTS Signal Channel Session Configuration . . . . . . . . 39
4.5.1. Discover Configuration Parameters . . . . . . . . . . 40 4.5.1. Discover Configuration Parameters . . . . . . . . . . 41
4.5.2. Convey DOTS Signal Channel Session Configuration . . 44 4.5.2. Convey DOTS Signal Channel Session Configuration . . 45
4.5.3. Configuration Freshness and Notifications . . . . . . 49 4.5.3. Configuration Freshness and Notifications . . . . . . 50
4.5.4. Delete DOTS Signal Channel Session Configuration . . 50 4.5.4. Delete DOTS Signal Channel Session Configuration . . 51
4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 51 4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 52
4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 53 4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 54
5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 54 5. DOTS Signal Channel YANG Modules . . . . . . . . . . . . . . 55
5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 54 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 55
5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 56 5.2. IANA DOTS Signal Channel YANG Module . . . . . . . . . . 57
5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 60 5.3. IETF DOTS Signal Channel YANG Module . . . . . . . . . . 61
6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 70 6. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 71
7. (D)TLS Protocol Profile and Performance Considerations . . . 73 7. (D)TLS Protocol Profile and Performance Considerations . . . 74
7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 73 7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 74
7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 74 7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 75
7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 76 7.3. DTLS MTU and Fragmentation . . . . . . . . . . . . . . . 77
8. Mutual Authentication of DOTS Agents & Authorization of DOTS 8. Mutual Authentication of DOTS Agents & Authorization of DOTS
Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 78 9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 79
9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 78 9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 79
9.3. Media Type Registration . . . . . . . . . . . . . . . . . 79 9.3. Media Type Registration . . . . . . . . . . . . . . . . . 80
9.4. CoAP Content-Formats Registration . . . . . . . . . . . . 79 9.4. CoAP Content-Formats Registration . . . . . . . . . . . . 80
9.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 79 9.5. CBOR Tag Registration . . . . . . . . . . . . . . . . . . 80
9.6. DOTS Signal Channel Protocol Registry . . . . . . . . . . 80 9.6. DOTS Signal Channel Protocol Registry . . . . . . . . . . 81
9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry . . 80 9.6.1. DOTS Signal Channel CBOR Key Values Sub-Registry . . 81
9.6.1.1. Registration Template . . . . . . . . . . . . . . 80 9.6.1.1. Registration Template . . . . . . . . . . . . . . 81
9.6.1.2. Initial Sub-Registry Content . . . . . . . . . . 82 9.6.1.2. Initial Sub-Registry Content . . . . . . . . . . 83
9.6.2. Status Codes Sub-Registry . . . . . . . . . . . . . . 83 9.6.2. Status Codes Sub-Registry . . . . . . . . . . . . . . 84
9.6.3. Conflict Status Codes Sub-Registry . . . . . . . . . 85 9.6.3. Conflict Status Codes Sub-Registry . . . . . . . . . 86
9.6.4. Conflict Cause Codes Sub-Registry . . . . . . . . . . 87 9.6.4. Conflict Cause Codes Sub-Registry . . . . . . . . . . 88
9.6.5. Attack Status Codes Sub-Registry . . . . . . . . . . 87 9.6.5. Attack Status Codes Sub-Registry . . . . . . . . . . 88
9.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 88 9.7. DOTS Signal Channel YANG Modules . . . . . . . . . . . . 89
10. Security Considerations . . . . . . . . . . . . . . . . . . . 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 90
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 91 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 92
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 91 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 92
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 93
13.1. Normative References . . . . . . . . . . . . . . . . . . 91 13.1. Normative References . . . . . . . . . . . . . . . . . . 93
13.2. Informative References . . . . . . . . . . . . . . . . . 94 13.2. Informative References . . . . . . . . . . . . . . . . . 95
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100
1. Introduction 1. Introduction
A distributed denial-of-service (DDoS) attack is a distributed A distributed denial-of-service (DDoS) attack is a distributed
attempt to make machines or network resources unavailable to their attempt to make machines or network resources unavailable to their
intended users. In most cases, sufficient scale for an effective intended users. In most cases, sufficient scale for an effective
attack can be achieved by compromising enough end-hosts and using attack can be achieved by compromising enough end-hosts and using
those infected hosts to perpetrate and amplify the attack. The those infected hosts to perpetrate and amplify the attack. The
victim in this attack can be an application server, a host, a router, victim in this attack can be an application server, a host, a router,
a firewall, or an entire network. a firewall, or an entire network.
skipping to change at page 7, line 40 skipping to change at page 7, line 40
DOTS server periodically sends status messages to the client, DOTS server periodically sends status messages to the client,
including basic mitigation feedback details. Mitigation remains including basic mitigation feedback details. Mitigation remains
active until the DOTS client explicitly terminates mitigation, or the active until the DOTS client explicitly terminates mitigation, or the
mitigation lifetime expires. mitigation lifetime expires.
DOTS signaling can happen with DTLS over UDP and TLS over TCP. DOTS signaling can happen with DTLS over UDP and TLS over TCP.
Likewise, DOTS requests may be sent using IPv4 or IPv6 transfer Likewise, DOTS requests may be sent using IPv4 or IPv6 transfer
capabilities. A Happy Eyeballs procedure for DOTS signal channel is capabilities. A Happy Eyeballs procedure for DOTS signal channel is
specified in Section 4.3. specified in Section 4.3.
A DOTS client is entitled to access only to resources it creates. In
particular, a DOTS client can not retrieve data related to mitigation
requests created by other DOTS clients of the same DOTS client
domain.
Messages exchanged between DOTS agents are serialized using Concise Messages exchanged between DOTS agents are serialized using Concise
Binary Object Representation (CBOR) [RFC7049], a binary encoding Binary Object Representation (CBOR) [RFC7049], a binary encoding
scheme designed for small code and message size. CBOR-encoded scheme designed for small code and message size. CBOR-encoded
payloads are used to carry signal channel-specific payload messages payloads are used to carry signal channel-specific payload messages
which convey request parameters and response information such as which convey request parameters and response information such as
errors. In order to allow reusing data models across protocols, errors. In order to allow reusing data models across protocols,
[RFC7951] specifies the JavaScript Object Notation (JSON) encoding of [RFC7951] specifies the JavaScript Object Notation (JSON) encoding of
YANG-modeled data. A similar effort for CBOR is defined in YANG-modeled data. A similar effort for CBOR is defined in
[I-D.ietf-core-yang-cbor]. [I-D.ietf-core-yang-cbor].
skipping to change at page 13, line 22 skipping to change at page 13, line 27
specification, the cryptographic hash algorithm used is SHA-256 specification, the cryptographic hash algorithm used is SHA-256
[RFC6234]. The output of the cryptographic hash algorithm is [RFC6234]. The output of the cryptographic hash algorithm is
truncated to 16 bytes; truncation is done by stripping off the truncated to 16 bytes; truncation is done by stripping off the
final 16 bytes. The truncated output is base64url encoded. final 16 bytes. The truncated output is base64url encoded.
The 'cuid' is intended to be stable when communicating with a The 'cuid' is intended to be stable when communicating with a
given DOTS server, i.e., the 'cuid' used by a DOTS client SHOULD given DOTS server, i.e., the 'cuid' used by a DOTS client SHOULD
NOT change over time. Distinct 'cuid' values MAY be used by a NOT change over time. Distinct 'cuid' values MAY be used by a
single DOTS client per DOTS server. single DOTS client per DOTS server.
If a DOTS client has to change its 'cuid' for some reason, it MUST
NOT do so when mitigations are still active for the old 'cuid'.
The 'cuid' SHOULD be 22 characters to avoid DOTS signal message
fragmentation over UDP. Furthermore, if that DOTS client created
aliases and filtering entries at the DOTS server by means of the
DOTS data channel, it MUST delete all the entries bound to the old
'cuid' and re-install them using the new 'cuid'.
DOTS servers MUST return 4.09 (Conflict) error code to a DOTS peer DOTS servers MUST return 4.09 (Conflict) error code to a DOTS peer
to notify that the 'cuid' is already in-use by another DOTS to notify that the 'cuid' is already in-use by another DOTS
client. Upon receipt of that error code, a new 'cuid' MUST be client. Upon receipt of that error code, a new 'cuid' MUST be
generated by the DOTS peer (e.g., using [RFC4122]). generated by the DOTS peer (e.g., using [RFC4122]).
Client-domain DOTS gateways MUST handle 'cuid' collision directly Client-domain DOTS gateways MUST handle 'cuid' collision directly
and it is RECOMMENDED that 'cuid' collision is handled directly by and it is RECOMMENDED that 'cuid' collision is handled directly by
server-domain DOTS gateways. server-domain DOTS gateways.
DOTS gateways MAY rewrite the 'cuid' used by peer DOTS clients. DOTS gateways MAY rewrite the 'cuid' used by peer DOTS clients.
skipping to change at page 18, line 45 skipping to change at page 19, line 34
The 'cdid' attribute MUST NOT be generated and included by DOTS The 'cdid' attribute MUST NOT be generated and included by DOTS
clients. clients.
DOTS servers MUST ignore 'cdid' attributes that are directly DOTS servers MUST ignore 'cdid' attributes that are directly
supplied by source DOTS clients or client-domain DOTS gateways. supplied by source DOTS clients or client-domain DOTS gateways.
This implies that first server-domain DOTS gateways MUST strip This implies that first server-domain DOTS gateways MUST strip
'cdid' attributes supplied by DOTS clients. DOTS servers SHOULD 'cdid' attributes supplied by DOTS clients. DOTS servers SHOULD
support a configuration parameter to identify DOTS gateways that support a configuration parameter to identify DOTS gateways that
are trusted to supply 'cdid' attributes. are trusted to supply 'cdid' attributes.
Only single-valued 'cdid' are defined in this document. Only single-valued 'cdid' are defined in this document. That is,
only the first on-path server-domain DOTS gateway can insert a
'cdid' value. This specification does not allow multiple server-
domain DOTS gateways, whenever involved in the path, to insert a
'cdid' value for each server-domain gateway.
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.ietf-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
skipping to change at page 25, line 28 skipping to change at page 26, line 28
2: Conflicts with an existing accept-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 accept-listed ACLs are attacking the prefixes in the accept-listed ACLs are attacking the
target. 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 (see the example shown in
'conflict-scope', and 'retry-timer' MUST NOT be returned in Figure 11). Note that 'conflict-status', 'conflict-scope',
the error response. and 'retry-timer' MUST NOT be returned in the error
response.
conflict-scope: Characterizes the exact conflict scope. It may conflict-scope: Characterizes the exact conflict scope. It may
include a list of IP addresses, a list of prefixes, a list of include a list of IP addresses, a list of prefixes, a list of
port numbers, a list of target protocols, a list of FQDNs, a port numbers, a list of target protocols, a list of FQDNs, a
list of URIs, a list of alias-names, or references to list of URIs, a list of alias-names, or references to
conflicting ACLs (by an 'acl-name', typically conflicting ACLs (by an 'acl-name', typically
[I-D.ietf-dots-data-channel]). [I-D.ietf-dots-data-channel]).
retry-timer: Indicates, in seconds, the time after which the DOTS retry-timer: Indicates, in seconds, the time after which the DOTS
client may re-issue the same request. The DOTS server returns client may re-issue the same request. The DOTS server returns
skipping to change at page 26, line 5 skipping to change at page 27, line 7
be rejected by the DOTS server for the same reasons. be rejected by the DOTS server for the same reasons.
The retry-timer SHOULD be equal to the lifetime of the active The retry-timer SHOULD be equal to the lifetime of the active
mitigation request resulting in the deactivation of the mitigation request resulting in the deactivation of the
conflicting mitigation request. The lifetime of the conflicting mitigation request. The lifetime of the
deactivated mitigation request will be updated to (retry-timer deactivated mitigation request will be updated to (retry-timer
+ 45 seconds), so the DOTS client can refresh the deactivated + 45 seconds), so the DOTS client can refresh the deactivated
mitigation request after retry-timer seconds before expiry of mitigation request after retry-timer seconds before expiry of
lifetime and check if the conflict is resolved. lifetime and check if the conflict is resolved.
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=7eeaf349529eb55ed50113"
Uri-Path: "mid=12"
(1) Request with a conflicting 'cuid'
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=f30d281ce6b64fc5a0b91e"
Uri-Path: "mid=12"
(2) Request with a new 'cuid'
Figure 11: Example of Generating a New 'cuid'
As an active attack evolves, DOTS clients can adjust the scope of As an active attack evolves, DOTS clients can adjust the scope of
requested mitigation as necessary, by refining the scope of resources requested mitigation as necessary, by refining the scope of resources
requiring mitigation. This can be achieved by sending a PUT request requiring mitigation. This can be achieved by sending a PUT request
with a new 'mid' value that will override the existing one with with a new 'mid' value that will override the existing one with
overlapping mitigation scopes. overlapping mitigation scopes.
For a mitigation request to continue beyond the initial negotiated For a mitigation request to continue beyond the initial negotiated
lifetime, the DOTS client has to refresh the current mitigation lifetime, the DOTS client has to refresh the current mitigation
request by sending a new PUT request. This PUT request MUST use the request by sending a new PUT request. This PUT request MUST use the
same 'mid' value, and MUST repeat all the other parameters as sent in same 'mid' value, and MUST repeat all the other parameters as sent in
skipping to change at page 27, line 15 skipping to change at page 28, line 41
response. If the DOTS server uses the Block2 Option in the GET response. If the DOTS server uses the Block2 Option in the GET
response and the response is for a dynamically changing resource response and the response is for a dynamically changing resource
(e.g. "c=n" or "c=a" query), the DOTS server MUST include the ETag (e.g. "c=n" or "c=a" query), the DOTS server MUST include the ETag
Option in the response. The DOTS client MUST include the same ETag Option in the response. The DOTS client MUST include the same ETag
value in subsequent GET requests to retrieve the rest of the value in subsequent GET requests to retrieve the rest of the
representation. representation.
The following examples illustrate how a DOTS client retrieves active The following examples illustrate how a DOTS client retrieves active
mitigation requests from a DOTS server. In particular: mitigation requests from a DOTS server. In particular:
o Figure 11 shows the example of a GET request to retrieve all DOTS o Figure 12 shows the example of a GET request to retrieve all DOTS
mitigation requests signaled by a DOTS client. mitigation requests signaled by a DOTS client.
o Figure 12 shows the example of a GET request to retrieve a o Figure 13 shows the example of a GET request to retrieve a
specific DOTS mitigation request signaled by a DOTS client. The specific DOTS mitigation request signaled by a DOTS client. The
configuration data to be reported in the response is formatted in configuration data to be reported in the response is formatted in
the same order as was processed by the DOTS server in the original the same order as was processed by the DOTS server in the original
mitigation request. mitigation request.
These two examples assume the default of "c=a"; that is, the DOTS These two examples assume the default of "c=a"; that is, the DOTS
client asks for all data to be reported by the DOTS server. client asks for all data to be reported by the DOTS server.
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Observe: 0 Observe: 0
Figure 11: GET to Retrieve all DOTS Mitigation Requests Figure 12: 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: "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 12: GET to Retrieve a Specific DOTS Mitigation Request Figure 13: 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.
Likewise, the same error MUST be returned as a response to a request Likewise, the same error MUST be returned as a response to a request
to retrieve all mitigation records (i.e., 'mid' Uri-Path is not to retrieve all mitigation records (i.e., 'mid' Uri-Path is not
defined) of a given DOTS client if the DOTS server does not find any defined) of a given DOTS client if the DOTS server does not find any
mitigation record for that DOTS client. As a reminder, a DOTS client mitigation record for that DOTS client. As a reminder, a DOTS client
is identified by its identity (e.g., client certificate, 'cuid') and is identified by its identity (e.g., client certificate, 'cuid') and
optionally the 'cdid'. optionally the 'cdid'.
Figure 13 shows a response example of all active mitigation requests Figure 14 shows a response example of all active mitigation requests
associated with the DOTS client as maintained by the DOTS server. associated with the DOTS client as maintained by the DOTS server.
The response indicates the mitigation status of each mitigation The response indicates the mitigation status of each mitigation
request. request.
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"mid": 12332, "mid": 12332,
"mitigation-start": "1507818434", "mitigation-start": "1507818434",
skipping to change at page 29, line 46 skipping to change at page 30, line 46
"status": "attack-stopped", "status": "attack-stopped",
"bytes-dropped": "0", "bytes-dropped": "0",
"bps-dropped": "0", "bps-dropped": "0",
"pkts-dropped": "0", "pkts-dropped": "0",
"pps-dropped": "0" "pps-dropped": "0"
} }
] ]
} }
} }
Figure 13: Response Body to a GET Request Figure 14: Response Body to a GET Request
The mitigation status parameters are described below: The mitigation status parameters are described below:
mitigation-start: Mitigation start time is expressed in seconds mitigation-start: Mitigation start time is expressed in seconds
relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of relative to 1970-01-01T00:00Z in UTC time (Section 2.4.1 of
[RFC7049]). The CBOR encoding is modified so that the leading tag [RFC7049]). The CBOR encoding is modified so that the leading tag
1 (epoch-based date/time) MUST be omitted. 1 (epoch-based date/time) MUST be omitted.
This is a mandatory attribute when an attack mitigation is active. This is a mandatory attribute when an attack mitigation is active.
skipping to change at page 33, line 21 skipping to change at page 34, line 21
A DOTS client that is no longer interested in receiving notifications A DOTS client that is no longer interested in receiving notifications
from the DOTS server can simply "forget" the observation. When the from the DOTS server can simply "forget" the observation. When the
DOTS server sends the next notification, the DOTS client will not DOTS server sends the next notification, the DOTS client will not
recognize the token in the message and thus will return a Reset recognize the token in the message and thus will return a Reset
message. This causes the DOTS server to remove the associated entry. message. This causes the DOTS server to remove the associated entry.
Alternatively, the DOTS client can explicitly deregister itself by Alternatively, the DOTS client can explicitly deregister itself by
issuing a GET request that has the Token field set to the token of issuing a GET request that has the Token field set to the token of
the observation to be cancelled and includes an Observe Option with the observation to be cancelled and includes an Observe Option with
the value set to '1' (deregister). The latter is RECOMMENDED. the value set to '1' (deregister). The latter is RECOMMENDED.
Figure 14 shows an example of a DOTS client requesting a DOTS server Figure 15 shows an example of a DOTS client requesting a DOTS server
to send notifications related to a mitigation request. Note that for to send notifications related to a mitigation request. Note that for
mitigations with pre-configured scopes (i.e., 'trigger-mitigation' mitigations with pre-configured scopes (i.e., 'trigger-mitigation'
set to 'false'), the state will need to transition from 3 (attack- set to 'false'), the state will need to transition from 3 (attack-
stopped) to 8 (attack-mitigation-signal-loss). stopped) to 8 (attack-mitigation-signal-loss).
+-----------+ +-----------+ +-----------+ +-----------+
|DOTS client| |DOTS server| |DOTS client| |DOTS server|
+-----------+ +-----------+ +-----------+ +-----------+
| | | |
| GET /<mid> | | GET /<mid> |
skipping to change at page 34, line 34 skipping to change at page 35, line 34
| | | |
|<-----------------------------------------+ |<-----------------------------------------+
| 2.05 Content | | 2.05 Content |
| Token: 0x4a | Notification upon | Token: 0x4a | Notification upon
| Observe: 60 | a state change | Observe: 60 | a state change
| status: "attack-stopped" | | status: "attack-stopped" |
|<-----------------------------------------+ |<-----------------------------------------+
| | | |
... ...
Figure 14: Notifications of Attack Mitigation Status Figure 15: Notifications of Attack Mitigation Status
4.4.2.2. DOTS Clients Polling for Mitigation Status 4.4.2.2. DOTS Clients Polling for Mitigation Status
The DOTS client can send the GET request at frequent intervals The DOTS client can send the GET request at frequent intervals
without the Observe Option to retrieve the configuration data of the without the Observe Option to retrieve the configuration data of the
mitigation request and non-configuration data (i.e., the attack mitigation request and non-configuration data (i.e., the attack
status). The frequency of polling the DOTS server to get the status). The frequency of polling the DOTS server to get the
mitigation status SHOULD follow the transmission guidelines in mitigation status SHOULD follow the transmission guidelines in
Section 3.1.3 of [RFC8085]. Section 3.1.3 of [RFC8085].
skipping to change at page 35, line 37 skipping to change at page 36, line 37
may send a PUT request to convey an efficacy update to the DOTS may send a PUT request to convey an efficacy update to the DOTS
server followed by a DELETE request to withdraw the mitigation server followed by a DELETE request to withdraw the mitigation
request, but the DELETE request arrives at the DOTS server before the request, but the DELETE request arrives at the DOTS server before the
PUT request. To handle out-of-order delivery of requests, if an If- PUT request. To handle out-of-order delivery of requests, if an If-
Match Option is present in the PUT request and the 'mid' in the Match Option is present in the PUT request and the 'mid' in the
request matches a mitigation request from that DOTS client, the request matches a mitigation request from that DOTS client, the
request is processed by the DOTS server. If no match is found, the request is processed by the DOTS server. If no match is found, the
PUT request is silently ignored by the DOTS server. PUT request is silently ignored by the DOTS server.
An example of an efficacy update message, which includes an If-Match An example of an efficacy update message, which includes an If-Match
Option with an empty value, is depicted in Figure 15. Option with an empty value, is depicted in Figure 16.
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: "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:
{ {
skipping to change at page 36, line 41 skipping to change at page 37, line 41
], ],
"target-protocol": [ "target-protocol": [
6 6
], ],
"attack-status": "under-attack" "attack-status": "under-attack"
} }
] ]
} }
} }
Figure 15: An Example of Efficacy Update Figure 16: An Example of Efficacy Update
The 'attack-status' parameter is a mandatory attribute when The 'attack-status' parameter is a mandatory attribute when
performing an efficacy update. The various possible values contained performing an efficacy update. The various possible values contained
in the 'attack-status' parameter are described in Table 3. in the 'attack-status' parameter are described in Table 3.
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Parameter | Description | | Parameter | Description |
| value | | | value | |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 1 | The DOTS client determines that it is still under | | 1 | The DOTS client determines that it is still under |
skipping to change at page 37, line 30 skipping to change at page 38, line 30
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. As specified in [RFC7252], 5.03 uses Max-Age option the mitigation. As specified in [RFC7252], 5.03 uses Max-Age option
to indicate the number of seconds after which to retry. to indicate the number of seconds after which to retry.
4.4.4. Withdraw a Mitigation 4.4.4. Withdraw a Mitigation
DELETE requests are used to withdraw DOTS mitigation requests from DELETE requests are used to withdraw DOTS mitigation requests from
DOTS servers (Figure 16). DOTS servers (Figure 17).
'cuid' and 'mid' are mandatory Uri-Path parameters for DELETE 'cuid' and 'mid' are mandatory Uri-Path parameters for DELETE
requests. requests.
The same considerations for manipulating 'cdid' parameter by DOTS The same considerations for manipulating 'cdid' parameter by DOTS
gateways, as specified in Section 4.4.1, MUST be followed for DELETE gateways, as specified in Section 4.4.1, MUST be followed for DELETE
requests. Uri-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: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
Figure 16: Withdraw a DOTS Mitigation Figure 17: Withdraw a DOTS Mitigation
If the DELETE request does not include 'cuid' and 'mid' parameters, If the DELETE request does not include 'cuid' and 'mid' parameters,
the DOTS server MUST reply with a 4.00 (Bad Request). the DOTS server MUST reply with a 4.00 (Bad Request).
Once the request is validated, the DOTS server immediately Once the request is validated, the DOTS server immediately
acknowledges a DOTS client's request to withdraw the DOTS signal acknowledges a DOTS client's request to withdraw the DOTS signal
using 2.02 (Deleted) response code with no response payload. A 2.02 using 2.02 (Deleted) response code with no response payload. A 2.02
(Deleted) Response Code is returned even if the 'mid' parameter value (Deleted) Response Code is returned even if the 'mid' parameter value
conveyed in the DELETE request does not exist in its configuration conveyed in the DELETE request does not exist in its configuration
data before the request. data before the request.
skipping to change at page 40, line 24 skipping to change at page 41, line 24
more details). more details).
4.5.1. Discover Configuration Parameters 4.5.1. Discover Configuration Parameters
A GET request is used to obtain acceptable (e.g., minimum and maximum A GET request is used to obtain acceptable (e.g., minimum and maximum
values) and current configuration parameters on the DOTS server for values) and current configuration parameters on the DOTS server for
DOTS signal channel session configuration. This procedure occurs DOTS signal channel session configuration. This procedure occurs
between a DOTS client and its immediate peer DOTS server. As such, between a DOTS client and its immediate peer DOTS server. As such,
this GET request MUST NOT be relayed by a DOTS gateway. this GET request MUST NOT be relayed by a DOTS gateway.
Figure 17 shows how to obtain acceptable configuration parameters for Figure 18 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: "config" Uri-Path: "config"
Figure 17: GET to Retrieve Configuration Figure 18: GET to Retrieve Configuration
The DOTS server in the 2.05 (Content) response conveys the current, The DOTS server in the 2.05 (Content) response conveys the current,
minimum, and maximum attribute values acceptable by the DOTS server minimum, and maximum attribute values acceptable by the DOTS server
(Figure 18). (Figure 19).
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": number, "max-value": number,
"min-value": number, "min-value": number,
"current-value": number "current-value": number
}, },
skipping to change at page 41, line 49 skipping to change at page 42, line 49
}, },
"ack-random-factor": { "ack-random-factor": {
"max-value-decimal": "string", "max-value-decimal": "string",
"min-value-decimal": "string", "min-value-decimal": "string",
"current-value-decimal": "string" "current-value-decimal": "string"
} }
} }
} }
} }
Figure 18: GET Configuration Response Body Schema Figure 19: GET Configuration Response Body Schema
The parameters in Figure 18 are described below: The parameters in Figure 19 are described below:
mitigating-config: Set of configuration parameters to use when a mitigating-config: Set of configuration parameters to use when a
mitigation is active. The following parameters may be included: mitigation is active. The following parameters may be included:
heartbeat-interval: Time interval in seconds between two heartbeat-interval: Time interval in seconds between two
consecutive heartbeat messages. consecutive heartbeat messages.
'0' is used to disable the heartbeat mechanism. '0' is used to disable the heartbeat mechanism.
This is an optional attribute. This is an optional attribute.
skipping to change at page 42, line 42 skipping to change at page 43, line 42
ack-random-factor: Random factor used to influence the timing of ack-random-factor: Random factor used to influence the timing of
retransmissions (referred to as ACK_RANDOM_FACTOR parameter in retransmissions (referred to as ACK_RANDOM_FACTOR parameter in
CoAP). CoAP).
This is an optional attribute. This is an optional attribute.
idle-config: Set of configuration parameters to use when no idle-config: Set of configuration parameters to use when no
mitigation is active. This attribute has the same structure as mitigation is active. This attribute has the same structure as
'mitigating-config'. 'mitigating-config'.
Figure 19 shows an example of acceptable and current configuration Figure 20 shows an example of acceptable and current configuration
parameters on a DOTS server for DOTS signal channel session parameters on a DOTS server for DOTS signal channel session
configuration. The same acceptable configuration is used during configuration. The same acceptable configuration is used during
mitigation and idle times. mitigation and idle times.
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": 240, "max-value": 240,
skipping to change at page 44, line 10 skipping to change at page 45, line 10
}, },
"ack-random-factor": { "ack-random-factor": {
"max-value-decimal": "4.00", "max-value-decimal": "4.00",
"min-value-decimal": "1.10", "min-value-decimal": "1.10",
"current-value-decimal": "1.50" "current-value-decimal": "1.50"
} }
} }
} }
} }
Figure 19: Example of a Configuration Response Body Figure 20: Example of a Configuration Response Body
4.5.2. Convey DOTS Signal Channel Session Configuration 4.5.2. Convey DOTS Signal Channel Session Configuration
A PUT request (Figures 20 and 21) is used to convey the configuration A PUT request (Figures 21 and 22) is used to convey the configuration
parameters for the signal channel (e.g., heartbeat interval, maximum parameters for the signal channel (e.g., heartbeat interval, maximum
retransmissions). Message transmission parameters for CoAP are retransmissions). Message transmission parameters for CoAP are
defined in Section 4.8 of [RFC7252]. The RECOMMENDED values of defined in Section 4.8 of [RFC7252]. The RECOMMENDED values of
transmission parameter values are ack-timeout (2 seconds), max- transmission parameter values are ack-timeout (2 seconds), max-
retransmit (3), ack-random-factor (1.5). In addition to those retransmit (3), ack-random-factor (1.5). In addition to those
parameters, the RECOMMENDED specific DOTS transmission parameter parameters, the RECOMMENDED specific DOTS transmission parameter
values are 'heartbeat-interval' (30 seconds) and 'missing-hb-allowed' values are 'heartbeat-interval' (30 seconds) and 'missing-hb-allowed'
(5). (5).
Note: heartbeat-interval should be tweaked to also assist DOTS Note: heartbeat-interval should be tweaked to also assist DOTS
skipping to change at page 45, line 40 skipping to change at page 46, line 40
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: "config" Uri-Path: "config"
Uri-Path: "sid=123" Uri-Path: "sid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
... ...
} }
Figure 20: PUT to Convey the DOTS Signal Channel Session Figure 21: PUT to Convey the DOTS Signal Channel Session
Configuration Data Configuration Data
The additional Uri-Path parameter to those defined in Table 1 is as The additional Uri-Path parameter to those defined in Table 1 is as
follows: follows:
sid: Session Identifier is an identifier for the DOTS signal channel sid: Session Identifier is an identifier for the DOTS signal channel
session configuration data represented as an integer. This session configuration data represented as an integer. This
identifier MUST be generated by DOTS clients. 'sid' values MUST identifier MUST be generated by DOTS clients. 'sid' values MUST
increase monotonically (when a new PUT is generated by a DOTS increase monotonically (when a new PUT is generated by a DOTS
client to convey the configuration parameters for the signal client to convey the configuration parameters for the signal
skipping to change at page 46, line 47 skipping to change at page 47, line 47
"ack-timeout": { "ack-timeout": {
"current-value-decimal": "string" "current-value-decimal": "string"
}, },
"ack-random-factor": { "ack-random-factor": {
"current-value-decimal": "string" "current-value-decimal": "string"
} }
} }
} }
} }
Figure 21: PUT to Convey the DOTS Signal Channel Session Figure 22: PUT to Convey the DOTS Signal Channel Session
Configuration Data (Message Body Schema) Configuration Data (Message Body Schema)
The meaning of the parameters in the CBOR body (Figure 21) is defined The meaning of the parameters in the CBOR body (Figure 22) is defined
in Section 4.5.1. in Section 4.5.1.
At least one of the attributes 'heartbeat-interval', 'missing-hb- At least one of the attributes 'heartbeat-interval', 'missing-hb-
allowed', 'max-retransmit', 'ack-timeout', and 'ack-random-factor' allowed', 'max-retransmit', 'ack-timeout', and 'ack-random-factor'
MUST be present in the PUT request. Note that 'heartbeat-interval', MUST be present in the PUT request. Note that 'heartbeat-interval',
'missing-hb-allowed', 'max-retransmit', 'ack-timeout', and 'ack- 'missing-hb-allowed', 'max-retransmit', 'ack-timeout', and 'ack-
random-factor', if present, do not need to be provided for both random-factor', if present, do not need to be provided for both
'mitigating-config', and 'idle-config' in a PUT request. 'mitigating-config', and 'idle-config' in a PUT request.
The PUT request with a higher numeric 'sid' value overrides the DOTS The PUT request with a higher numeric 'sid' value overrides the DOTS
signal channel session configuration data installed by a PUT request signal channel session configuration data installed by a PUT request
with a lower numeric 'sid' value. To avoid maintaining a long list with a lower numeric 'sid' value. To avoid maintaining a long list
of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be
automatically deleted and no longer available at the DOTS server. automatically deleted and no longer available at the DOTS server.
Figure 22 shows a PUT request example to convey the configuration Figure 23 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: "config" Uri-Path: "config"
Uri-Path: "sid=123" Uri-Path: "sid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
skipping to change at page 48, line 47 skipping to change at page 49, line 47
"ack-timeout": { "ack-timeout": {
"current-value-decimal": "2.00" "current-value-decimal": "2.00"
}, },
"ack-random-factor": { "ack-random-factor": {
"current-value-decimal": "1.50" "current-value-decimal": "1.50"
} }
} }
} }
} }
Figure 22: PUT to Convey the Configuration Parameters Figure 23: PUT to Convey the Configuration Parameters
The DOTS server indicates the result of processing the PUT request The DOTS server indicates the result of processing the PUT request
using CoAP response codes: using CoAP response codes:
o If the request is missing a mandatory attribute, does not include o If the request is missing a mandatory attribute, does not include
a 'sid' Uri-Path, or contains one or more invalid or unknown a 'sid' Uri-Path, or contains one or more invalid or unknown
parameters, 4.00 (Bad Request) MUST be returned in the response. parameters, 4.00 (Bad Request) MUST be returned in the response.
o If the DOTS server does not find the 'sid' parameter value o If the DOTS server does not find the 'sid' parameter value
conveyed in the PUT request in its configuration data and if the conveyed in the PUT request in its configuration data and if the
skipping to change at page 50, line 30 skipping to change at page 51, line 30
If a DOTS server detects that a misbehaving DOTS client does not If a DOTS server detects that a misbehaving DOTS client does not
contact the DOTS server after the expiry of Max-Age and retrieve the contact the DOTS server after the expiry of Max-Age and retrieve the
signal channel configuration data, it MAY terminate the (D)TLS signal channel configuration data, it MAY terminate the (D)TLS
session. A (D)TLS session is terminated by the receipt of an session. A (D)TLS session is terminated by the receipt of an
authenticated message that closes the connection (e.g., a fatal alert authenticated message that closes the connection (e.g., a fatal alert
(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 23). session configuration data (Figure 24).
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: "config" Uri-Path: "config"
Uri-Path: "sid=123" Uri-Path: "sid=123"
Figure 23: Delete Configuration Figure 24: Delete Configuration
The DOTS server resets the DOTS signal channel session configuration The DOTS server resets the DOTS signal channel session configuration
back to the default values and acknowledges a DOTS client's request back to the default values and acknowledges a DOTS client's request
to remove the DOTS signal channel session configuration using 2.02 to remove the DOTS signal channel session configuration using 2.02
(Deleted) response code. (Deleted) response code.
Upon bootstrapping or reboot, a DOTS client MAY send a DELETE request Upon bootstrapping or reboot, a DOTS client MAY send a DELETE request
to set the configuration parameters to default values. Such a to set the configuration parameters to default values. Such a
request does not include any 'sid'. request does not include any 'sid'.
skipping to change at page 51, line 21 skipping to change at page 52, line 21
DOTS server for a signal session, then the response code 5.03 DOTS server for a signal session, then the response code 5.03
(Service Unavailable) will be returned in the response to the DOTS (Service Unavailable) will be returned in the response to the DOTS
client. client.
The DOTS server can return the error response code 5.03 in response The DOTS server can return the error response code 5.03 in response
to a request from the DOTS client or convey the error response code to a request from the DOTS client or convey the error response code
5.03 in a unidirectional notification response from the DOTS server. 5.03 in a unidirectional notification response from the DOTS server.
The DOTS server in the error response conveys the alternate DOTS The DOTS server in the error response conveys the alternate DOTS
server's FQDN, and the alternate DOTS server's IP address(es) values server's FQDN, and the alternate DOTS server's IP address(es) values
in the CBOR body (Figure 24). in the CBOR body (Figure 25).
{ {
"ietf-dots-signal-channel:redirected-signal": { "ietf-dots-signal-channel:redirected-signal": {
"alt-server": "string", "alt-server": "string",
"alt-server-record": [ "alt-server-record": [
"string" "string"
] ]
} }
Figure 24: Redirected Server Error Response Body Schema Figure 25: Redirected Server Error Response Body Schema
The parameters are described below: The parameters are described below:
alt-server: FQDN of an alternate DOTS server. alt-server: FQDN of an alternate DOTS server.
This is a mandatory attribute. This is a mandatory attribute.
alt-server-record: A list of IP addresses of an alternate DOTS alt-server-record: A list of IP addresses of an alternate DOTS
server. server.
skipping to change at page 52, line 20 skipping to change at page 53, line 20
If the alternate DOTS server TTL has expired, the DOTS client MUST If the alternate DOTS server TTL has expired, the DOTS client MUST
use the DOTS server(s), that was provisioned using means discussed in use the DOTS server(s), that was provisioned using means discussed in
Section 4.1. This fall back mechanism is triggered immediately upon Section 4.1. This fall back mechanism is triggered immediately upon
expiry of the TTL, except when a DDoS attack is active. expiry of the TTL, except when a DDoS attack is active.
Requests issued by misbehaving DOTS clients which do not honor the Requests issued by misbehaving DOTS clients which do not honor the
TTL conveyed in the Max-Age Option or react to explicit re-direct TTL conveyed in the Max-Age Option or react to explicit re-direct
messages can be rejected by DOTS servers. messages can be rejected by DOTS servers.
Figure 25 shows a 5.03 response example to convey the DOTS alternate Figure 26 shows a 5.03 response example to convey the DOTS alternate
server 'alt-server.example' together with its IP addresses server 'alt-server.example' together with its IP addresses
2001:db8:6401::1 and 2001:db8:6401::2. 2001:db8:6401::1 and 2001:db8:6401::2.
{ {
"ietf-dots-signal-channel:redirected-signal": { "ietf-dots-signal-channel:redirected-signal": {
"alt-server": "alt-server.example", "alt-server": "alt-server.example",
"alt-server-record": [ "alt-server-record": [
"2001:db8:6401::1", "2001:db8:6401::1",
"2001:db8:6401::2" "2001:db8:6401::2"
] ]
} }
Figure 25: Example of Redirected Server Error Response Body Figure 26: Example of Redirected Server Error Response Body
When the DOTS client receives 5.03 response with an alternate server When the DOTS client receives 5.03 response with an alternate server
included, it considers the current request as failed, but SHOULD try included, it considers the current request as failed, but SHOULD try
re-sending the request to the alternate DOTS server. During a DDoS re-sending the request to the alternate DOTS server. During a DDoS
attack, the DNS server may be the target of another DDoS attack, attack, the DNS server may be the target of another DDoS attack,
alternate DOTS server's IP addresses conveyed in the 5.03 response alternate DOTS server's IP addresses conveyed in the 5.03 response
help the DOTS client skip DNS lookup of the alternate DOTS server, at help the DOTS client skip DNS lookup of the alternate DOTS server, at
the cost of trusting the first DOTS server to provide accurate the cost of trusting the first DOTS server to provide accurate
information. The DOTS client can then try to establish a UDP or a information. The DOTS client can then try to establish a UDP or a
TCP session with the alternate DOTS server. The DOTS client MAY TCP session with the alternate DOTS server. The DOTS client MAY
skipping to change at page 64, line 46 skipping to change at page 65, line 46
list acl-list { list acl-list {
when "../../conflict-cause = 'conflict-with-acceptlist'"; 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-data:dots-data/ietf-data:dots-client/" path "/ietf-data:dots-data/ietf-data:dots-client/"
+"ietf-data:acls/ietf-data:acl/ietf-data: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-data:dots-data/ietf-data:dots-client/" path "/ietf-data:dots-data/ietf-data:dots-client/"
+ietf-data:acls/ietf-data:acl/ietf-data: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 75, line 51 skipping to change at page 76, line 51
the DOTS client for each configuration request (Section 4.5.2), the DOTS client for each configuration request (Section 4.5.2),
attackers replaying configuration requests with lower numeric attackers replaying configuration requests with lower numeric
'sid' values will be rejected by the DOTS server if it maintains a 'sid' values will be rejected by the DOTS server if it maintains a
higher numeric 'sid' value for this DOTS client. higher numeric 'sid' value for this DOTS client.
Owing to the aforementioned protections, all DOTS signal channel Owing to the aforementioned protections, all DOTS signal channel
requests are safe to transmit in TLS 1.3 as early data. Refer to requests are safe to transmit in TLS 1.3 as early data. Refer to
[I-D.boucadair-dots-earlydata] for more details. [I-D.boucadair-dots-earlydata] for more details.
A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request A simplified TLS 1.3 handshake with 0-RTT DOTS mitigation request
message exchange is shown in Figure 26. message exchange is shown in Figure 27.
DOTS Client DOTS Server DOTS Client DOTS Server
ClientHello ClientHello
(0-RTT DOTS signal message) (0-RTT DOTS signal message)
--------> -------->
ServerHello ServerHello
{EncryptedExtensions} {EncryptedExtensions}
{Finished} {Finished}
<-------- [DOTS signal message] <-------- [DOTS signal message]
(end_of_early_data) (end_of_early_data)
{Finished} --------> {Finished} -------->
[DOTS signal message] <-------> [DOTS signal message] [DOTS signal message] <-------> [DOTS signal message]
Note that: Note that:
() Indicates messages protected 0-RTT keys () Indicates messages protected 0-RTT keys
{} Indicates messages protected using handshake keys {} Indicates messages protected using handshake keys
[] Indicates messages protected using 1-RTT keys [] Indicates messages protected using 1-RTT keys
Figure 26: A Simplified TLS 1.3 Handshake with 0-RTT Figure 27: A Simplified TLS 1.3 Handshake with 0-RTT
7.3. DTLS MTU and Fragmentation 7.3. DTLS MTU and Fragmentation
To avoid DOTS signal message fragmentation and the subsequent To avoid DOTS signal message fragmentation and the subsequent
decreased probability of message delivery, DOTS agents MUST ensure decreased probability of message delivery, DOTS agents MUST ensure
that the DTLS record MUST fit within a single datagram. If the path that the DTLS record MUST fit within a single datagram. If the path
MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD
be assumed. The DOTS client must consider the amount of record be assumed. The DOTS client must consider the amount of record
expansion expected by the DTLS processing when calculating the size expansion expected by the DTLS processing when calculating the size
of CoAP message that fits within the path MTU. Path MTU MUST be of CoAP message that fits within the path MTU. Path MTU MUST be
skipping to change at page 77, line 49 skipping to change at page 78, line 49
| +--------------+ | | | | | | +--------------+ | | | | |
| +----+--------+ | +---------------+ | +----+--------+ | +---------------+
| ^ | | ^ |
| | | | | |
| +----------------+ | | | +----------------+ | |
| | DDoS detector | | | | | DDoS detector | | |
| | (DOTS client) +<---------------+ | | | (DOTS client) +<---------------+ |
| +----------------+ | | +----------------+ |
+-----------------------------------------------+ +-----------------------------------------------+
Figure 27: Example of Authentication and Authorization of DOTS Agents Figure 28: Example of Authentication and Authorization of DOTS Agents
In the example depicted in Figure 27, the DOTS gateway and DOTS In the example depicted in Figure 28, the DOTS gateway and DOTS
clients within the 'example.com' domain mutually authenticate. After clients within the 'example.com' domain mutually authenticate. After
the DOTS gateway validates the identity of a DOTS client, it the DOTS gateway validates the identity of a DOTS client, it
communicates with the AAA server in the 'example.com' domain to communicates with the AAA server in the 'example.com' domain to
determine if the DOTS client is authorized to request DDoS determine if the DOTS client is authorized to request DDoS
mitigation. If the DOTS client is not authorized, a 4.01 mitigation. If the DOTS client is not authorized, a 4.01
(Unauthorized) is returned in the response to the DOTS client. In (Unauthorized) is returned in the response to the DOTS client. In
this example, the DOTS gateway only allows the application server and this example, the DOTS gateway only allows the application server and
DDoS attack detector to request DDoS mitigation, but does not permit DDoS attack detector to request DDoS mitigation, but does not permit
the user of type 'guest' to request DDoS mitigation. the user of type 'guest' to request DDoS mitigation.
Also, DOTS gateways and servers located in different domains must Also, DOTS gateways and servers located in different domains must
perform mutual authentication (e.g., using certificates). A DOTS perform mutual authentication (e.g., using certificates). A DOTS
server will only allow a DOTS gateway with a certificate for a server will only allow a DOTS gateway with a certificate for a
particular domain to request mitigation for that domain. In particular domain to request mitigation for that domain. In
reference to Figure 27, the DOTS server only allows the DOTS gateway reference to Figure 28, 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
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
skipping to change at page 88, line 42 skipping to change at page 89, line 42
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel URI: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel
Registrant Contact: IANA. Registrant Contact: IANA.
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 modules in This document requests IANA to register the following YANG modules in
the "YANG Module Names" subregistry [RFC7950] within the "YANG the "YANG Module Names" subregistry [RFC7950] within the "YANG
Parameters" registry. 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
maintained by IANA: N Maintained by IANA: N
prefix: signal Prefix: signal
reference: RFC XXXX Reference: RFC XXXX
name: iana-signal Name: iana-signal
namespace: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel Namespace: urn:ietf:params:xml:ns:yang:iana-dots-signal-channel
maintained by IANA: Y Maintained by IANA: Y
prefix: iana-signal Prefix: iana-signal
reference: RFC XXXX Reference: RFC XXXX
This document defines the initial version of the IANA-maintained This document defines the initial version of the IANA-maintained
iana-dots-signal-channel YANG module. IANA is requested to add this iana-dots-signal-channel YANG module. IANA is requested to add this
note: note:
Status, conflict status, conflict cause, and attack status values Status, conflict status, conflict cause, and attack status values
must not be directly added to the iana-dots-signal-channel YANG must not be directly added to the iana-dots-signal-channel YANG
module. They must instead be respectively added to the "DOTS module. They must instead be respectively added to the "DOTS
Status Codes", "DOTS Conflict Status Codes", "DOTS Conflict Cause Status Codes", "DOTS Conflict Status Codes", "DOTS Conflict Cause
Codes", and "DOTS Attack Status Codes" registries. Codes", and "DOTS Attack Status Codes" registries.
skipping to change at page 90, line 28 skipping to change at page 91, line 28
misbehaving DOTS client from within the client's domain which uses misbehaving DOTS client from within the client's domain which uses
the 'cuid' of another DOTS client of the domain to delete or alter the 'cuid' of another DOTS client of the domain to delete or alter
active mitigations. For this attack vector to happen, the active mitigations. For this attack vector to happen, the
misbehaving client needs to pass the security validation checks by misbehaving client needs to pass the security validation checks by
the DOTS server, and eventually the checks of a client-domain DOTS the DOTS server, and eventually the checks of a client-domain DOTS
gateway. gateway.
A similar attack can be achieved by a compromised DOTS client which A similar attack can be achieved by a compromised DOTS client which
can sniff the TLS 1.2 handshake, use the client certificate to can sniff the TLS 1.2 handshake, use the client certificate to
identify the 'cuid' used by another DOTS client. This attack is not identify the 'cuid' used by another DOTS client. This attack is not
possible with TLS 1.3 because most of the TLS handshake is encrypted possible if algorithms such as [RFC4122] are used to generate the
and the client certificate is not visible to eavesdroppers. 'cuid'. Likewise, this attack is not possible with TLS 1.3 because
most of the TLS handshake is encrypted and the client certificate is
not visible to eavesdroppers.
Rate-limiting DOTS requests, including those with new 'cuid' values, Rate-limiting DOTS requests, including those with new 'cuid' values,
from the same DOTS client defends against DoS attacks that would from the same DOTS client defends against DoS attacks that would
result in varying the 'cuid' to exhaust DOTS server resources. Rate- result in varying the 'cuid' to exhaust DOTS server resources. Rate-
limit policies SHOULD be enforced on DOTS gateways (if deployed) and limit policies SHOULD be enforced on DOTS gateways (if deployed) and
DOTS servers. DOTS servers.
In order to prevent leaking internal information outside a client- In order to prevent leaking internal information outside a client-
domain, DOTS gateways located in the client-domain SHOULD NOT reveal domain, DOTS gateways located in the client-domain SHOULD NOT reveal
the identification information that pertains to internal DOTS clients the identification information that pertains to internal DOTS clients
skipping to change at page 91, line 9 skipping to change at page 92, line 9
trigger actions on a given IP prefix. That is, only actions on IP trigger actions on a given IP prefix. That is, only actions on IP
resources that belong to the DOTS client' domain MUST be authorized resources that belong to the DOTS client' domain MUST be authorized
by a DOTS server. The exact mechanism for the DOTS servers to by a DOTS server. The exact mechanism for the DOTS servers to
validate that the target prefixes are within the scope of the DOTS validate that the target prefixes are within the scope of the DOTS
client domain is deployment-specific. client domain is deployment-specific.
The presence of DOTS gateways may lead to infinite forwarding loops, The presence of DOTS gateways may lead to infinite forwarding loops,
which is undesirable. To prevent and detect such loops, this which is undesirable. To prevent and detect such loops, this
document uses the Hop-Limit Option. document uses the Hop-Limit Option.
When FQDNs are used as targets, the DOTS server MUST rely upon DNS
privacy enabling protocols (e.g., DNS over TLS [RFC7858], DoH
[RFC8484]) to prevent eavesdroppers from possibly identifying the
target resources protected by the DDoS mitigation service and means
to ensure the target FQDN resolution is authentic (e.g., DNSSEC
[RFC4034]).
CoAP-specific security considerations are discussed in Section 11 of CoAP-specific security considerations are discussed in Section 11 of
[RFC7252], while CBOR-related security considerations are discussed [RFC7252], while CBOR-related security considerations are discussed
in Section 8 of [RFC7049]. in Section 8 of [RFC7049].
11. Contributors 11. Contributors
The following individuals have contributed to this document: The following individuals have contributed to this document:
o Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.trust o Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.trust
skipping to change at page 91, line 31 skipping to change at page 92, line 38
o Robert Moskowitz, HTT Consulting Oak Park, MI 42837 United States, o Robert Moskowitz, HTT Consulting Oak Park, MI 42837 United States,
Email: rgm@htt-consult.com Email: rgm@htt-consult.com
o Dan Wing, Email: dwing-ietf@fuggles.com o Dan Wing, Email: dwing-ietf@fuggles.com
12. Acknowledgements 12. Acknowledgements
Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw, Thanks to Christian Jacquenet, Roland Dobbins, Roman D. Danyliw,
Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang Michael Richardson, Ehud Doron, Kaname Nishizuka, Dave Dolson, Liang
Xia, Gilbert Clark, Xialiang Frank, Jim Schaad, Klaus Hartke and Xia, Gilbert Clark, Xialiang Frank, Jim Schaad, Klaus Hartke,
Nesredien Suleiman for the discussion and comments. Nesredien Suleiman, and Stephen Farrell for the discussion and
comments.
The authors would like to give special thanks to Kaname Nishizuka and The authors would like to give special thanks to Kaname Nishizuka and
Jon Shallow for their efforts in implementing the protocol and Jon Shallow for their efforts in implementing the protocol and
performing interop testing at IETF Hackathons. performing interop testing at IETF Hackathons.
Thanks to the core WG for the recommendations on Hop-Limit and Thanks to the core WG for the recommendations on Hop-Limit and
redirect signaling. redirect signaling.
Special thanks to Benjamin Kaduk for the detailed AD review. Special thanks to Benjamin Kaduk for the detailed AD review.
skipping to change at page 95, line 8 skipping to change at page 96, line 19
progress), October 2018. progress), October 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-04 (work in Management Interface", draft-ietf-core-comi-04 (work in
progress), November 2018. progress), November 2018.
[I-D.ietf-core-hop-limit] [I-D.ietf-core-hop-limit]
Boucadair, M., K, R., and J. Shallow, "Constrained Boucadair, M., K, R., and J. Shallow, "Constrained
Application Protocol (CoAP) Hop Limit Option", draft-ietf- Application Protocol (CoAP) Hop Limit Option", draft-ietf-
core-hop-limit-02 (work in progress), December 2018. core-hop-limit-03 (work in progress), February 2019.
[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-07 (work in progress), September 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., K, R., Teague, N., Compton, Mortensen, A., Andreasen, F., K, R., Teague, N., Compton,
R., and c. christopher_gray3@cable.comcast.com, R., and c. christopher_gray3@cable.comcast.com,
skipping to change at page 95, line 32 skipping to change at page 96, line 43
[I-D.ietf-dots-data-channel] [I-D.ietf-dots-data-channel]
Boucadair, M. and R. K, "Distributed Denial-of-Service Boucadair, M. and R. K, "Distributed Denial-of-Service
Open Threat Signaling (DOTS) Data Channel Specification", Open Threat Signaling (DOTS) Data Channel Specification",
draft-ietf-dots-data-channel-27 (work in progress), draft-ietf-dots-data-channel-27 (work in progress),
February 2019. February 2019.
[I-D.ietf-dots-requirements] [I-D.ietf-dots-requirements]
Mortensen, A., K, R., and R. Moskowitz, "Distributed Mortensen, A., K, R., and R. Moskowitz, "Distributed
Denial of Service (DDoS) Open Threat Signaling Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-20 (work in Requirements", draft-ietf-dots-requirements-22 (work in
progress), February 2019. progress), March 2019.
[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-17 (work Open Threat Signaling", draft-ietf-dots-use-cases-17 (work
in progress), January 2019. in progress), January 2019.
[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-30 (work in progress), 1.3", draft-ietf-tls-dtls13-31 (work in progress), March
November 2018. 2019.
[IANA.CBOR.Tags] [IANA.CBOR.Tags]
IANA, "Concise Binary Object Representation (CBOR) Tags", IANA, "Concise Binary Object Representation (CBOR) Tags",
<http://www.iana.org/assignments/cbor-tags/ <http://www.iana.org/assignments/cbor-tags/
cbor-tags.xhtml>. cbor-tags.xhtml>.
[IANA.CoAP.Content-Formats] [IANA.CoAP.Content-Formats]
IANA, "CoAP Content-Formats", IANA, "CoAP Content-Formats",
<http://www.iana.org/assignments/core-parameters/ <http://www.iana.org/assignments/core-parameters/
core-parameters.xhtml#content-formats>. core-parameters.xhtml#content-formats>.
skipping to change at page 96, line 32 skipping to change at page 97, line 43
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001, DOI 10.17487/RFC3022, January 2001,
<https://www.rfc-editor.org/info/rfc3022>. <https://www.rfc-editor.org/info/rfc3022>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>. <https://www.rfc-editor.org/info/rfc4122>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006, DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>. <https://www.rfc-editor.org/info/rfc4340>.
skipping to change at page 98, line 35 skipping to change at page 99, line 49
"Architectural Considerations in Smart Object Networking", "Architectural Considerations in Smart Object Networking",
RFC 7452, DOI 10.17487/RFC7452, March 2015, RFC 7452, DOI 10.17487/RFC7452, March 2015,
<https://www.rfc-editor.org/info/rfc7452>. <https://www.rfc-editor.org/info/rfc7452>.
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
NETCONF Protocol over Transport Layer Security (TLS) with NETCONF Protocol over Transport Layer Security (TLS) with
Mutual X.509 Authentication", RFC 7589, Mutual X.509 Authentication", RFC 7589,
DOI 10.17487/RFC7589, June 2015, DOI 10.17487/RFC7589, June 2015,
<https://www.rfc-editor.org/info/rfc7589>. <https://www.rfc-editor.org/info/rfc7589>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
Authors' Addresses Authors' Addresses
Tirumaleswar Reddy (editor) Tirumaleswar Reddy (editor)
McAfee, Inc. McAfee, Inc.
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore, Karnataka 560071 Bangalore, Karnataka 560071
India India
Email: kondtir@gmail.com Email: kondtir@gmail.com
Mohamed Boucadair (editor) Mohamed Boucadair (editor)
Orange Orange
 End of changes. 62 change blocks. 
110 lines changed or deleted 173 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/