< draft-ietf-dots-signal-channel-18.txt   draft-ietf-dots-signal-channel-19.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 21, 2018 Orange Expires: October 11, 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.
March 20, 2018 April 9, 2018
Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel Specification Channel Specification
draft-ietf-dots-signal-channel-18 draft-ietf-dots-signal-channel-19
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 20 skipping to change at page 2, line 20
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 21, 2018. This Internet-Draft will expire on October 11, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions and Terminology . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6
4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 8 4. DOTS Signal Channel: Messages & Behaviors . . . . . . . . . . 8
4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 8 4.1. DOTS Server(s) Discovery . . . . . . . . . . . . . . . . 8
4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. CoAP URIs . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 9 4.3. Happy Eyeballs for DOTS Signal Channel . . . . . . . . . 9
4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 10 4.4. DOTS Mitigation Methods . . . . . . . . . . . . . . . . . 10
4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 11 4.4.1. Request Mitigation . . . . . . . . . . . . . . . . . 11
4.4.2. Retrieve Information Related to a Mitigation . . . . 25 4.4.2. Retrieve Information Related to a Mitigation . . . . 25
4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 33 4.4.3. Efficacy Update from DOTS Clients . . . . . . . . . . 33
4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 35 4.4.4. Withdraw a Mitigation . . . . . . . . . . . . . . . . 35
4.5. DOTS Signal Channel Session Configuration . . . . . . . . 36 4.5. DOTS Signal Channel Session Configuration . . . . . . . . 36
4.5.1. Discover Configuration Parameters . . . . . . . . . . 38 4.5.1. Discover Configuration Parameters . . . . . . . . . . 38
4.5.2. Convey DOTS Signal Channel Session Configuration . . 42 4.5.2. Convey DOTS Signal Channel Session Configuration . . 42
4.5.3. Configuration Freshness and Notifications . . . . . . 47 4.5.3. Configuration Freshness and Notifications . . . . . . 47
4.5.4. Delete DOTS Signal Channel Session Configuration . . 48 4.5.4. Delete DOTS Signal Channel Session Configuration . . 48
4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 49 4.6. Redirected Signaling . . . . . . . . . . . . . . . . . . 49
4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 50 4.7. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 51
5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . . . 52 5. DOTS Signal Channel YANG Module . . . . . . . . . . . . . . . 52
5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 52 5.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 52
5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 54 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 54
6. Mapping Parameters to CBOR . . . . . . . . . . . . . . . . . 67 6. Mapping Parameters to CBOR . . . . . . . . . . . . . . . . . 68
7. (D)TLS Protocol Profile and Performance Considerations . . . 69 7. (D)TLS Protocol Profile and Performance Considerations . . . 70
7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 69 7.1. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . 70
7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 71 7.2. (D)TLS 1.3 Considerations . . . . . . . . . . . . . . . . 71
7.3. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 72 7.3. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 73
8. Mutual Authentication of DOTS Agents & Authorization of DOTS 8. Mutual Authentication of DOTS Agents & Authorization of DOTS
Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 74 9.1. DOTS Signal Channel UDP and TCP Port Number . . . . . . . 75
9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 74 9.2. Well-Known 'dots' URI . . . . . . . . . . . . . . . . . . 75
9.3. CoAP Response Code . . . . . . . . . . . . . . . . . . . 75 9.3. CoAP Response Code . . . . . . . . . . . . . . . . . . . 75
9.4. CoAP Option Number . . . . . . . . . . . . . . . . . . . 75 9.4. CoAP Option Number . . . . . . . . . . . . . . . . . . . 76
9.5. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 75 9.5. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 76
9.5.1. Registration Template . . . . . . . . . . . . . . . . 76 9.5.1. Registration Template . . . . . . . . . . . . . . . . 76
9.5.2. Initial Registry Content . . . . . . . . . . . . . . 76 9.5.2. Initial Registry Content . . . . . . . . . . . . . . 77
9.6. DOTS Signal Channel YANG Module . . . . . . . . . . . . . 77 9.6. DOTS Signal Channel YANG Module . . . . . . . . . . . . . 78
10. Security Considerations . . . . . . . . . . . . . . . . . . . 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 78
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 79 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 79
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 79 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 79
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 79 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 80
13.1. Normative References . . . . . . . . . . . . . . . . . . 79 13.1. Normative References . . . . . . . . . . . . . . . . . . 80
13.2. Informative References . . . . . . . . . . . . . . . . . 81 13.2. Informative References . . . . . . . . . . . . . . . . . 82
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86
1. Introduction 1. Introduction
A distributed denial-of-service (DDoS) attack is an attempt to make A distributed denial-of-service (DDoS) attack is an attempt to make
machines or network resources unavailable to their intended users. machines or network resources unavailable to their intended users.
In most cases, sufficient scale can be achieved by compromising In most cases, sufficient scale can be achieved by compromising
enough end-hosts and using those infected hosts to perpetrate and enough end-hosts and using those infected hosts to perpetrate and
amplify the attack. The victim in this attack can be an application amplify the attack. The victim in this attack can be an application
server, a host, a router, a firewall, or an entire network. server, a host, a router, a firewall, or an entire network.
skipping to change at page 5, line 40 skipping to change at page 5, line 40
[I-D.ietf-dots-architecture]. The requirements for DOTS signal [I-D.ietf-dots-architecture]. The requirements for DOTS signal
channel protocol are documented in [I-D.ietf-dots-requirements]. channel protocol are documented in [I-D.ietf-dots-requirements].
This document satisfies all the use cases discussed in This document satisfies all the use cases discussed in
[I-D.ietf-dots-use-cases]. [I-D.ietf-dots-use-cases].
This document focuses on the DOTS signal channel. This is a This document focuses on the DOTS signal channel. This is a
companion document of the DOTS data channel specification companion document of the DOTS data channel specification
[I-D.ietf-dots-data-channel] that defines a configuration and a bulk [I-D.ietf-dots-data-channel] that defines a configuration and a bulk
data exchange mechanism supporting the DOTS signal channel. data exchange mechanism supporting the DOTS signal channel.
2. Notational Conventions and Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
(D)TLS is used for statements that apply to both Transport Layer (D)TLS is used for statements that apply to both Transport Layer
Security [RFC5246] and Datagram Transport Layer Security [RFC6347]. Security [RFC5246] and Datagram Transport Layer Security [RFC6347].
Specific terms are used for any statement that applies to either Specific terms are used for any statement that applies to either
protocol alone. protocol alone.
skipping to change at page 19, line 7 skipping to change at page 19, line 4
Only single-valued 'cdid' are defined in this document. Only single-valued 'cdid' are defined in this document.
This is an optional Uri-Path. When present, 'cdid' MUST be This is an optional Uri-Path. When present, 'cdid' MUST be
positioned before 'cuid'. positioned before 'cuid'.
A DOTS gateway may add the following CoAP option: A DOTS gateway may add the following CoAP option:
hop-limit: This option (see Section 9.4) is used to detect and hop-limit: This option (see Section 9.4) is used to detect and
prevent infinite loops. This option is typically inserted by a prevent infinite loops. This option is typically inserted by a
DOTS gateway. DOTS gateway. Only one single instance of the option is allowed
in a message.
The length of the hop-limit option is 1 byte. The length of the hop-limit option is 1 byte.
The value of the hop-limit option is encoded as an unsigned The value of the hop-limit option is encoded as an unsigned
integer (see Section 3.2 of [RFC7252]). integer (see Section 3.2 of [RFC7252]).
Each intermediate DOTS agent involved in the handling of a DOTS Each intermediate DOTS agent involved in the handling of a DOTS
message MUST decrement the hop-limit option value by 1 prior to message MUST decrement the hop-limit option value by 1 prior to
forwarding upstream if this parameter exists. DOTS messages MUST forwarding upstream if this parameter exists. DOTS messages MUST
NOT be forwarded if the hop-limit option is set to '0' after NOT be forwarded if the hop-limit option is set to '0' after
decrement. Messages that cannot be forwarded because of exhausted decrement. Messages that cannot be forwarded because of exhausted
hop-limit SHOULD be logged with a 5.06 (Hop Limit Reached) error hop-limit SHOULD be logged with a 5.06 (Hop Limit Reached) error
message sent back to the DOTS peer. It is RECOMMENDED that DOTS message sent back to the DOTS peer. It is RECOMMENDED that DOTS
clients and gateways support means to alert administrators about clients and gateways support means to alert administrators about
loop errors so that appropriate actions are undertaken. loop errors so that appropriate actions are undertaken.
To ease debugging and troubleshooting, the DOTS gateway which
detects a loop SHOULD include its information (e.g., server name,
alias, IP address) in the diagnostic payload under the conditions
detailed in Section 5.5.2 of [RFC7252]. Each intermediate DOTS
gateway involved in relaying a 5.06 (Hop Limit Reached) error
message SHOULD prepend its own information in the diagnostic
payload with a space character used as separator. Only one
information per DOTS gateway MUST appear in the diagnostic
payload. The ultimate DOTS gateway MAY remove the diagnostic
payload before forwarding the 5.06 (Hop Limit Reached) error
message to a DOTS client domain.
The initial hop-limit value SHOULD be configurable. If no initial The initial hop-limit value SHOULD be configurable. If no initial
value is explicitly provided, the default initial hop-limit value value is explicitly provided, the default initial hop-limit value
of 16 MUST be used. of 16 MUST be used.
Because forwarding errors may occur if inadequate hop-limit values Because forwarding errors may occur if inadequate hop-limit values
are used, DOTS agents at the boundaries of an administrative are used, DOTS agents at the boundaries of an administrative
domain MAY be instructed to rewrite the value of hop-limit carried domain MAY be instructed to rewrite the value of hop-limit carried
in received messages (that is, ignore the value of hop-limit in received messages (that is, ignore the value of hop-limit
received in a message). received in a message).
This is an optional option. This is an optional CoAP option.
Because of the complexity to handle partial failure cases, this Because of the complexity to handle partial failure cases, this
specification does not allow for including multiple mitigation specification does not allow for including multiple mitigation
requests in the same PUT request. Concretely, a DOTS client MUST NOT requests in the same PUT request. Concretely, a DOTS client MUST NOT
include multiple 'scope' parameters in the same PUT request. include multiple 'scope' parameters in the same PUT request.
FQDN and URI mitigation scopes may be thought of as a form of scope FQDN and URI mitigation scopes may be thought of as a form of scope
alias, in which the addresses associated with the domain name or URI alias, in which the addresses associated with the domain name or URI
represent the full scope of the mitigation. represent the full scope of the mitigation.
skipping to change at page 41, line 22 skipping to change at page 41, line 22
"max-value": 9, "max-value": 9,
"min-value": 3, "min-value": 3,
"current-value": 5 "current-value": 5
}, },
"max-retransmit": { "max-retransmit": {
"max-value": 15, "max-value": 15,
"min-value": 2, "min-value": 2,
"current-value": 3 "current-value": 3
}, },
"ack-timeout": { "ack-timeout": {
"max-value-decimal": 30, "max-value-decimal": 30.0,
"min-value-decimal": 1, "min-value-decimal": 1.0,
"current-value-decimal": 2 "current-value-decimal": 2.0
}, },
"ack-random-factor": { "ack-random-factor": {
"max-value-decimal": 4.0, "max-value-decimal": 4.0,
"min-value-decimal": 1.1, "min-value-decimal": 1.1,
"current-value-decimal": 1.5 "current-value-decimal": 1.5
} }
}, },
"idle-config": { "idle-config": {
"heartbeat-interval": { "heartbeat-interval": {
"max-value": 240, "max-value": 240,
skipping to change at page 41, line 49 skipping to change at page 41, line 49
"max-value": 9, "max-value": 9,
"min-value": 3, "min-value": 3,
"current-value": 5 "current-value": 5
}, },
"max-retransmit": { "max-retransmit": {
"max-value": 15, "max-value": 15,
"min-value": 2, "min-value": 2,
"current-value": 3 "current-value": 3
}, },
"ack-timeout": { "ack-timeout": {
"max-value-decimal": 30, "max-value-decimal": 30.0,
"min-value-decimal": 1, "min-value-decimal": 1.0,
"current-value-decimal": 2 "current-value-decimal": 2.0
}, },
"ack-random-factor": { "ack-random-factor": {
"max-value-decimal": 4.0, "max-value-decimal": 4.0,
"min-value-decimal": 1.1, "min-value-decimal": 1.1,
"current-value-decimal": 1.5 "current-value-decimal": 1.5
} }
}, },
"trigger-mitigation": true "trigger-mitigation": true
} }
skipping to change at page 46, line 23 skipping to change at page 46, line 23
{ {
"ietf-dots-signal-channel:signal-config": { "ietf-dots-signal-channel:signal-config": {
"mitigating-config": { "mitigating-config": {
"heartbeat-interval": { "heartbeat-interval": {
"current-value": 91 "current-value": 91
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
"current-value": 3 "current-value": 3
}, },
"max-retransmit": { "max-retransmit": {
"current-value": 7 "current-value": 3
}, },
"ack-timeout": { "ack-timeout": {
"current-value-decimal": 5 "current-value-decimal": 2.0
}, },
"ack-random-factor": { "ack-random-factor": {
"current-value-decimal": 1.5 "current-value-decimal": 1.5
} }
}, },
"idle-config": { "idle-config": {
"heartbeat-interval": { "heartbeat-interval": {
"current-value": 0 "current-value": 0
}, },
"max-retransmit": { "max-retransmit": {
"current-value": 7 "current-value": 3
}, },
"ack-timeout": { "ack-timeout": {
"current-value-decimal": 5 "current-value-decimal": 2.0
}, },
"ack-random-factor": { "ack-random-factor": {
"current-value-decimal": 1.5 "current-value-decimal": 1.5
} }
}, },
"trigger-mitigation": false "trigger-mitigation": false
} }
} }
Figure 20: PUT to Convey the Configuration Parameters Figure 20: PUT to Convey the Configuration Parameters
skipping to change at page 47, line 33 skipping to change at page 47, line 33
retransmit', 'target-protocol', 'ack-timeout', and 'ack-random- retransmit', 'target-protocol', 'ack-timeout', and 'ack-random-
factor' attribute values are not acceptable to the DOTS server, factor' attribute values are not acceptable to the DOTS server,
4.22 (Unprocessable Entity) MUST be returned in the response. 4.22 (Unprocessable Entity) MUST be returned in the response.
Upon receipt of this error code, the DOTS client SHOULD request Upon receipt of this error code, the DOTS client SHOULD request
the maximum and minimum attribute values acceptable to the DOTS the maximum and minimum attribute values acceptable to the DOTS
server (Section 4.5.1). server (Section 4.5.1).
The DOTS client may re-try and send the PUT request with updated The DOTS client may re-try and send the PUT request with updated
attribute values acceptable to the DOTS server. attribute values acceptable to the DOTS server.
A DOTS client may issue a GET message with 'sid' Uri-Path parameter
to retrieve the negotiated configuration. The response does not need
to include 'sid' in its message body.
4.5.3. Configuration Freshness and Notifications 4.5.3. Configuration Freshness and Notifications
Max-Age Option (Section 5.10.5 of [RFC7252]) SHOULD be returned by a Max-Age Option (Section 5.10.5 of [RFC7252]) SHOULD be returned by a
DOTS server to associate a validity time with a configuration it DOTS server to associate a validity time with a configuration it
sends. This feature allows the update of the configuration data if a sends. This feature allows the update of the configuration data if a
change occurs at the DOTS server side. For example, the new change occurs at the DOTS server side. For example, the new
configuration may instruct a DOTS client to cease heartbeats or configuration may instruct a DOTS client to cease heartbeats or
reduce heartbeat frequency. reduce heartbeat frequency.
It is NOT RECOMMENDED to return a Max-Age Option set to 0. It is NOT RECOMMENDED to return a Max-Age Option set to 0.
skipping to change at page 49, line 16 skipping to change at page 49, line 16
Redirected DOTS signaling is discussed in detail in Section 3.2.2 of Redirected DOTS signaling is discussed in detail in Section 3.2.2 of
[I-D.ietf-dots-architecture]. [I-D.ietf-dots-architecture].
If a DOTS server wants to redirect a DOTS client to an alternative If a DOTS server wants to redirect a DOTS client to an alternative
DOTS server for a signal session, then the response code 3.00 DOTS server for a signal session, then the response code 3.00
(alternate server) will be returned in the response to the DOTS (alternate server) will be returned in the response to the DOTS
client. client.
The DOTS server can return the error response code 3.00 in response The DOTS server can return the error response code 3.00 in response
to a PUT request from the DOTS client or convey the error response to a request from the DOTS client or convey the error response code
code 3.00 in a unidirectional notification response from the DOTS 3.00 in a unidirectional notification response from the DOTS server.
server.
The DOTS server in the error response conveys the alternate DOTS The DOTS server in the error response conveys the alternate DOTS
server's FQDN, and the alternate DOTS server's IP address(es) and server's FQDN, and the alternate DOTS server's IP address(es) and
time to live values in the CBOR body (Figure 22). time to live values in the CBOR body (Figure 22).
{ {
"ietf-dots-signal-channel:redirected-signal": { "ietf-dots-signal-channel:redirected-signal": {
"alt-server": "string", "alt-server": "string",
"alt-server-record": [ "alt-server-record": [
{ "string"
"addr": "string", ],
"ttl" : integer "alt-server-ttl": integer
}
]
}
} }
Figure 22: Redirected Server Error Response Body Figure 22: Redirected Server Error Response Body
The parameters are described below: The parameters are described below:
alt-server: FQDN of an alternate DOTS server. alt-server: FQDN of an alternate DOTS server.
addr: IP address of an alternate DOTS server. This is a mandatory attribute.
ttl: Time to live (TTL) represented as an integer number of seconds. alt-server-record: A list of IP addresses of an alternate DOTS
server.
This is an optional attribute.
alt-server-ttl: Time to live (TTL) of the alternate DOTS server,
represented as an integer number of seconds. That is, the time
interval that the alternate DOTS server may be cached for use by a
DOTS client.
A value of negative one (-1) indicates indefinite TTL. This value
means that the alternate DOTS server is to be used until the
alternate DOTS server redirects the traffic with another 3.00
response.
If no 'alt-server-ttl' is returned in a redirect response, this is
equivalent to returning a 'alt-server-ttl' parameter set to '-1'.
A 'alt-server-ttl' parameter set to '0' may be returned for
redirecting mitigation requests. Such value means that the
redirection applies only for the mitigation request in progress.
Returning short 'alt-server-ttl' may adversely impact DOTS clients
on slow links. Returning short values should be avoided under
such conditions.
If the alternate DOTS server TTL has expired, the DOTS client MUST
use the DOTS server(s), that was provisioned using means discussed
in Section 4.1. This fall back mechanism is triggered immediately
upon expiry of the TTL, except when a DDoS attack is active.
Requests issued by misbehaving DOTS clients which do not honor the
TTL or react to explicit re-direct messages can be rejected by
DOTS servers.
This is an optional attribute.
Figure 23 shows a 3.00 response example to convey the DOTS alternate Figure 23 shows a 3.00 response example to convey the DOTS alternate
server 'alt-server.example', its IP addresses 2001:db8:6401::1 and server 'alt-server.example', its IP addresses 2001:db8:6401::1 and
2001:db8:6401::2, and TTL values 3600 and 1800. 2001:db8:6401::2, and 'alt-server-ttl' value 3600.
{ {
"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",
"ttl" : 3600, "2001:db8:6401::2"
"addr": "2001:db8:6401::1" ],
}, "alt-server-ttl": 3600
{
"ttl" : 1800,
"addr": "2001:db8:6401::2"
}
]
}
} }
Figure 23: Example of Redirected Server Error Response Body Figure 23: Example of Redirected Server Error Response Body
When the DOTS client receives 3.00 response, it considers the current When the DOTS client receives 3.00 response, it considers the current
request as failed, but SHOULD try re-sending the request to the request as failed, but SHOULD try re-sending the request to the
alternate DOTS server. During a DDoS attack, the DNS server may be alternate DOTS server. During a DDoS attack, the DNS server may be
the target of another DDoS attack, alternate DOTS server's IP the target of another DDoS attack, alternate DOTS server's IP
addresses conveyed in the 3.00 response help the DOTS client skip DNS addresses conveyed in the 3.00 response help the DOTS client skip DNS
lookup of the alternate DOTS server. The DOTS client can then try to lookup of the alternate DOTS server. The DOTS client can then try to
establish a UDP or a TCP session with the alternate DOTS server. The establish a UDP or a TCP session with the alternate DOTS server. The
DOTS client SHOULD implement a DNS64 function to handle the scenario DOTS client SHOULD implement a DNS64 function to handle the scenario
where an IPv6-only DOTS client communicates with an IPv4-only where an IPv6-only DOTS client communicates with an IPv4-only
alternate DOTS server. alternate DOTS server.
If the DOTS client has been redirected to a DOTS server to which it
has already communicated with within the last five (5) minutes, it
MUST ignore the redirection and try to contact other DOTS servers
listed in the local configuration or discovered using dynamic means
such as DHCP or SRV procedures. It is RECOMMENDED that DOTS clients
support means to alert administrators about redirect loops.
4.7. Heartbeat Mechanism 4.7. Heartbeat Mechanism
To provide an indication of signal health and distinguish an 'idle' To provide an indication of signal health and distinguish an 'idle'
signal channel from a 'disconnected' or 'defunct' session, the DOTS signal channel from a 'disconnected' or 'defunct' session, the DOTS
agent sends a heartbeat over the signal channel to maintain its half agent sends a heartbeat over the signal channel to maintain its half
of the channel. The DOTS agent similarly expects a heartbeat from of the channel. The DOTS agent similarly expects a heartbeat from
its peer DOTS agent, and may consider a session terminated in the its peer DOTS agent, and may consider a session terminated in the
prolonged absence of a peer agent heartbeat. prolonged absence of a peer agent heartbeat.
While the communication between the DOTS agents is quiescent, the While the communication between the DOTS agents is quiescent, the
skipping to change at page 54, line 14 skipping to change at page 54, line 43
| | | +--ro max-value-decimal? decimal64 | | | +--ro max-value-decimal? decimal64
| | | +--ro min-value-decimal? decimal64 | | | +--ro min-value-decimal? decimal64
| | | +--rw current-value-decimal? decimal64 | | | +--rw current-value-decimal? decimal64
| | +--rw ack-random-factor | | +--rw ack-random-factor
| | +--ro max-value-decimal? decimal64 | | +--ro max-value-decimal? decimal64
| | +--ro min-value-decimal? decimal64 | | +--ro min-value-decimal? decimal64
| | +--rw current-value-decimal? decimal64 | | +--rw current-value-decimal? decimal64
| +--rw trigger-mitigation? boolean | +--rw trigger-mitigation? boolean
+--:(redirected-signal) +--:(redirected-signal)
+--ro alt-server string +--ro alt-server string
+--ro alt-server-record* [addr] +--ro alt-server-record* inet:ip-address
+--ro addr inet:ip-address +--ro alt-server-ttl? uint32
+--ro ttl? uint32
5.2. YANG Module 5.2. YANG Module
<CODE BEGINS> file "ietf-dots-signal-channel@2018-03-15.yang" <CODE BEGINS> file "ietf-dots-signal-channel@2018-04-09.yang"
module ietf-dots-signal-channel { module ietf-dots-signal-channel {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel"; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel";
prefix signal; prefix signal;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
import ietf-yang-types { import ietf-yang-types {
skipping to change at page 55, line 27 skipping to change at page 56, line 6
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2018-03-15 { revision 2018-04-09 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Distributed Denial-of-Service Open Threat "RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
} }
/* /*
* Groupings * Groupings
*/ */
skipping to change at page 66, line 34 skipping to change at page 67, line 13
grouping redirected-signal { grouping redirected-signal {
description description
"Grouping for the redirected signaling."; "Grouping for the redirected signaling.";
leaf alt-server { leaf alt-server {
type string; type string;
config false; config false;
mandatory true; mandatory true;
description description
"FQDN of an alternate server."; "FQDN of an alternate server.";
} }
list alt-server-record { leaf-list alt-server-record {
key "addr"; type inet:ip-address;
config false; config false;
description description
"List of records for the alternate server."; "List of records for the alternate server.";
leaf addr { }
type inet:ip-address; leaf alt-server-ttl {
description type uint32;
"An IPv4 or IPv6 address identifying the server."; config false;
} description
leaf ttl { "TTL associated with alt-server records.
type uint32;
description A value of negative one (-1) indicates indefinite
"TTL associated with this record."; TTL. This value means that the alternate
} DOTS server is to be used until the alternate DOTS
server redirects the traffic with another
3.00 response.";
} }
} }
/* /*
* Main Container for DOTS Signal Channel * Main Container for DOTS Signal Channel
*/ */
container dots-signal { container dots-signal {
description description
"Main container for DOTS signal message. "Main container for DOTS signal message.
skipping to change at page 69, line 26 skipping to change at page 70, line 7
| min-value-decimal | decimal64 | 42 | 6 tag 4 | | | min-value-decimal | decimal64 | 42 | 6 tag 4 | |
| | | | [-2, integer]| String | | | | | [-2, integer]| String |
| current-value-decimal| decimal64 | 43 | 6 tag 4 | | | current-value-decimal| decimal64 | 43 | 6 tag 4 | |
| | | | [-2, integer]| String | | | | | [-2, integer]| String |
| idle-config | container | 44 | 5 map | Object | | idle-config | container | 44 | 5 map | Object |
| trigger-mitigation | boolean | 45 | 7 bits 20 | False | | trigger-mitigation | boolean | 45 | 7 bits 20 | False |
| | | | 7 bits 21 | True | | | | | 7 bits 21 | True |
| ietf-dots-signal-cha | | | | | | ietf-dots-signal-cha | | | | |
|nnel:redirected-signal| container | 46 | 5 map | Object | |nnel:redirected-signal| container | 46 | 5 map | Object |
| alt-server | string | 47 | 3 text string | String | | alt-server | string | 47 | 3 text string | String |
| alt-server-record | list | 48 | 4 array | Array | | alt-server-record | leaf-list | 48 | 4 array | Array |
| addr | inet: | | | | | | inet: | | | |
| | ip-address | 49 | 3 text string | String | | | ip-address | | 3 text string | String |
| ttl | uint32 | 50 | 0 unsigned | Number | | alt-server-ttl | uint32 | 49 | 0 unsigned | Number |
| | | | 1 negative | Number |
+----------------------+-------------+-----+---------------+--------+ +----------------------+-------------+-----+---------------+--------+
Table 4: CBOR Mappings Used in DOTS Signal Channel Messages Table 4: CBOR Mappings Used in DOTS Signal Channel Messages
7. (D)TLS Protocol Profile and Performance Considerations 7. (D)TLS Protocol Profile and Performance Considerations
7.1. (D)TLS Protocol Profile 7.1. (D)TLS Protocol Profile
This section defines the (D)TLS protocol profile of DOTS signal This section defines the (D)TLS protocol profile of DOTS signal
channel over (D)TLS and DOTS data channel over TLS. channel over (D)TLS and DOTS data channel over TLS.
skipping to change at page 72, line 35 skipping to change at page 73, line 16
To avoid DOTS signal message fragmentation and the subsequent To avoid DOTS signal message fragmentation and the subsequent
decreased probability of message delivery, DOTS agents MUST ensure decreased probability of message delivery, DOTS agents MUST ensure
that the DTLS record MUST fit within a single datagram. If the path that the DTLS record MUST fit within a single datagram. If the path
MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD
be assumed. If UDP is used to convey the DOTS signal messages then be assumed. If UDP is used to convey the DOTS signal messages then
the DOTS client must consider the amount of record expansion expected the DOTS client must consider the amount of record expansion expected
by the DTLS processing when calculating the size of CoAP message that by the DTLS processing when calculating the size of CoAP message that
fits within the path MTU. Path MTU MUST be greater than or equal to fits within the path MTU. Path MTU MUST be greater than or equal to
[CoAP message size + DTLS overhead of 13 octets + authentication [CoAP message size + DTLS overhead of 13 octets + authentication
overhead of the negotiated DTLS cipher suite + block padding overhead of the negotiated DTLS cipher suite + block padding]
(Section 4.1.1.1 of [RFC6347]). If the request size exceeds the path (Section 4.1.1.1 of [RFC6347]). If the request size exceeds the path
MTU then the DOTS client MUST split the DOTS signal into separate MTU then the DOTS client MUST split the DOTS signal into separate
messages, for example the list of addresses in the 'target-prefix' messages, for example the list of addresses in the 'target-prefix'
parameter could be split into multiple lists and each list conveyed parameter could be split into multiple lists and each list conveyed
in a new PUT request. in a new PUT request.
Implementation Note: DOTS choice of message size parameters works Implementation Note: DOTS choice of message size parameters works
well with IPv6 and with most of today's IPv4 paths. However, with well with IPv6 and with most of today's IPv4 paths. However, with
IPv4, it is harder to safely make sure that there is no IP IPv4, it is harder to safely make sure that there is no IP
fragmentation. If IPv4 path MTU is unknown, implementations may want fragmentation. If IPv4 path MTU is unknown, implementations may want
skipping to change at page 77, line 39 skipping to change at page 78, line 15
| min-value-decimal | 41 | 6tag4 | IESG | [RFCXXXX] | | min-value-decimal | 41 | 6tag4 | IESG | [RFCXXXX] |
| max-value-decimal | 42 | 6tag4 | IESG | [RFCXXXX] | | max-value-decimal | 42 | 6tag4 | IESG | [RFCXXXX] |
| current-value- | 43 | 6tag4 | IESG | [RFCXXXX] | | current-value- | 43 | 6tag4 | IESG | [RFCXXXX] |
| decimal | | | | | | decimal | | | | |
| idle-config | 44 | 5 | IESG | [RFCXXXX] | | idle-config | 44 | 5 | IESG | [RFCXXXX] |
| trigger-mitigation | 45 | 7 | IESG | [RFCXXXX] | | trigger-mitigation | 45 | 7 | IESG | [RFCXXXX] |
| ietf-dots-signal-chan| 46 | 5 | IESG | [RFCXXXX] | | ietf-dots-signal-chan| 46 | 5 | IESG | [RFCXXXX] |
| nel:redirected-signal| | | | | | nel:redirected-signal| | | | |
| alt-server | 47 | 3 | IESG | [RFCXXXX] | | alt-server | 47 | 3 | IESG | [RFCXXXX] |
| alt-server-record | 48 | 4 | IESG | [RFCXXXX] | | alt-server-record | 48 | 4 | IESG | [RFCXXXX] |
| addr | 49 | 3 | IESG | [RFCXXXX] | | alt-server-ttl | 49 | 0/1 | IESG | [RFCXXXX] |
| ttl | 50 | 0 | IESG | [RFCXXXX] |
+----------------------+-------+-------+------------+---------------+ +----------------------+-------+-------+------------+---------------+
Table 8: Initial DOTS Signal Channel CBOR Mappings Registry Table 8: Initial DOTS Signal Channel CBOR Mappings Registry
9.6. DOTS Signal Channel YANG Module 9.6. DOTS Signal Channel YANG Module
This document requests IANA to register the following URI in the This document requests IANA to register the following URI in the
"IETF XML Registry" [RFC3688]: "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-channel
skipping to change at page 79, line 16 skipping to change at page 79, line 37
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's domain is deployment-specific. client's domain is deployment-specific.
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 Mike Geller, Cisco Systems, Inc. 3250 Florida 33309 USA, Email: o Mike Geller, Cisco Systems, Inc. 3250 Florida 33309 USA, Email:
mgeller@cisco.com mgeller@cisco.com
o Robert Moskowitz, HTT Consulting Oak Park, MI 42837 United States, o Robert Moskowitz, HTT Consulting Oak Park, MI 42837 United States,
Email: rgm@htt-consult.com Email: rgm@htt-consult.com
o Dan Wing, Email: dwing-ietf@fuggles.com o Dan Wing, Email: dwing-ietf@fuggles.com
o Jon Shallow, NCC Group, Email: jon.shallow@nccgroup.trust
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, and Nesredien Suleiman for the discussion and Xia, Gilbert Clark, and Nesredien Suleiman for the discussion and
comments. comments.
Special thanks to Jon Shallow for the careful reviews and inputs that Special thanks to Jon Shallow for the careful reviews and inputs that
enhanced this specification. enhanced this specification.
skipping to change at page 82, line 16 skipping to change at page 82, line 35
Mortensen, A., Andreasen, F., Reddy, T., Mortensen, A., Andreasen, F., Reddy, T.,
christopher_gray3@cable.comcast.com, c., Compton, R., and christopher_gray3@cable.comcast.com, c., Compton, R., and
N. Teague, "Distributed-Denial-of-Service Open Threat N. Teague, "Distributed-Denial-of-Service Open Threat
Signaling (DOTS) Architecture", draft-ietf-dots- Signaling (DOTS) Architecture", draft-ietf-dots-
architecture-06 (work in progress), March 2018. architecture-06 (work in progress), March 2018.
[I-D.ietf-dots-data-channel] [I-D.ietf-dots-data-channel]
Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil, Reddy, T., Boucadair, M., Nishizuka, K., Xia, L., Patil,
P., Mortensen, A., and N. Teague, "Distributed Denial-of- P., Mortensen, A., and N. Teague, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Data Channel Service Open Threat Signaling (DOTS) Data Channel
Specification", draft-ietf-dots-data-channel-13 (work in Specification", draft-ietf-dots-data-channel-14 (work in
progress), January 2018. progress), March 2018.
[I-D.ietf-dots-requirements] [I-D.ietf-dots-requirements]
Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed
Denial of Service (DDoS) Open Threat Signaling Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-14 (work in Requirements", draft-ietf-dots-requirements-14 (work in
progress), February 2018. progress), February 2018.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
Open Threat Signaling", draft-ietf-dots-use-cases-09 (work Open Threat Signaling", draft-ietf-dots-use-cases-11 (work
in progress), November 2017. in progress), March 2018.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-26 (work in progress), March 1.3", draft-ietf-tls-dtls13-26 (work in progress), March
2018. 2018.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-27 (work in progress), Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018. March 2018.
[proto_numbers] [proto_numbers]
"IANA, "Protocol Numbers"", 2011, "IANA, "Protocol Numbers"", 2011,
<http://www.iana.org/assignments/protocol-numbers>. <http://www.iana.org/assignments/protocol-numbers>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
 End of changes. 43 change blocks. 
87 lines changed or deleted 136 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/