< draft-ietf-dots-signal-channel-33.txt   draft-ietf-dots-signal-channel-34.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: November 11, 2019 Orange Expires: November 17, 2019 Orange
P. Patil P. Patil
Cisco Cisco
A. Mortensen A. Mortensen
Arbor Networks, Inc. Arbor Networks, Inc.
N. Teague N. Teague
Verisign, Inc. Iron Mountain Data Centers
May 10, 2019 May 16, 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-33 draft-ietf-dots-signal-channel-34
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 November 11, 2019. This Internet-Draft will expire on November 17, 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 9, line 33 skipping to change at page 9, line 33
This document assumes that DOTS clients are provisioned with the This document assumes that DOTS clients are provisioned with the
reachability information of their DOTS server(s) using any of a reachability information of their DOTS server(s) using any of a
variety of means (e.g., local configuration, or dynamic means such as variety of means (e.g., local configuration, or dynamic means such as
DHCP [I-D.ietf-dots-server-discovery]). The description of such DHCP [I-D.ietf-dots-server-discovery]). The description of such
means is out of scope of this document. means is out of scope of this document.
Likewise, it is out of scope of this document to specify the behavior Likewise, it is out of scope of this document to specify the behavior
to be followed by a DOTS client to send DOTS requests when multiple to be followed by a DOTS client to send DOTS requests when multiple
DOTS servers are provisioned (e.g., contact all DOTS servers, select DOTS servers are provisioned (e.g., contact all DOTS servers, select
one DOTS server among the list). Such behavior is specified in other one DOTS server among the list). Such behavior is specified in other
documents (e.g. [I-D.ietf-dots-multihoming]). documents (e.g., [I-D.ietf-dots-multihoming]).
4.2. CoAP URIs 4.2. CoAP URIs
The DOTS server MUST support the use of the path-prefix of "/.well- The DOTS server MUST support the use of the path-prefix of "/.well-
known/" as defined in [RFC5785] and the registered name of "dots". known/" as defined in [RFC5785] and the registered name of "dots".
Each DOTS operation is indicated by a path-suffix that indicates the Each DOTS operation is indicated by a path-suffix that indicates the
intended operation. The operation path (Table 1) is appended to the intended operation. The operation path (Table 1) is appended to the
path-prefix to form the URI used with a CoAP request to perform the path-prefix to form the URI used with a CoAP request to perform the
desired DOTS operation. desired DOTS operation.
skipping to change at page 13, line 49 skipping to change at page 13, line 49
} }
Figure 5: PUT to Convey DOTS Mitigation Requests Figure 5: PUT to Convey DOTS Mitigation Requests
The order of the Uri-Path options is important as it defines the CoAP The order of the Uri-Path options is important as it defines the CoAP
resource. In particular, 'mid' MUST follow 'cuid'. resource. In particular, 'mid' MUST follow 'cuid'.
The additional Uri-Path parameters to those defined in Section 4.2 The additional Uri-Path parameters to those defined in Section 4.2
are as follows: are as follows:
cuid: Stands for Client Unique Identifier. A globally unique cuid: Stands for Client Unique Identifier. A globally unique
identifier that is meant to prevent collisions among DOTS clients, identifier that is meant to prevent collisions among DOTS
especially those from the same domain. It MUST be generated by clients, especially those from the same domain. It MUST be
DOTS clients. generated by DOTS clients.
For the reasons discussed in Appendix A, implementations SHOULD For the reasons discussed in Appendix A, implementations SHOULD
set 'cuid' to the output of a cryptographic hash algorithm whose set 'cuid' to the output of a cryptographic hash algorithm
input is the Distinguished Encoding Rules (DER)-encoded Abstract whose input is the Distinguished Encoding Rules (DER)-encoded
Syntax Notation One (ASN.1) representation of the Subject Public Abstract Syntax Notation One (ASN.1) representation of the
Key Info (SPKI) of the DOTS client X.509 certificate [RFC5280], Subject Public Key Info (SPKI) of the DOTS client X.509
the DOTS client raw public key [RFC7250], or the "Pre-Shared Key certificate [RFC5280], the DOTS client raw public key
(PSK) identity" used by the DOTS client in the TLS [RFC7250], or the "Pre-Shared Key (PSK) identity" used by the
ClientKeyExchange message. In this version of the specification, DOTS client in the TLS ClientKeyExchange message. In this
the cryptographic hash algorithm used is SHA-256 [RFC6234]. The version of the specification, the cryptographic hash algorithm
output of the cryptographic hash algorithm is truncated to 16 used is SHA-256 [RFC6234]. The output of the cryptographic
bytes; truncation is done by stripping off the final 16 bytes. hash algorithm is truncated to 16 bytes; truncation is done by
The truncated output is base64url encoded (Section 5 of [RFC4648]) stripping off the final 16 bytes. The truncated output is
with the trailing "=" removed from the encoding. base64url encoded (Section 5 of [RFC4648]) with the trailing
"=" removed from the encoding.
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
NOT change over time. Distinct 'cuid' values MAY be used by a SHOULD NOT change over time. Distinct 'cuid' values MAY be
single DOTS client per DOTS server. used by a single DOTS client per DOTS server.
If a DOTS client has to change its 'cuid' for some reason, it MUST If a DOTS client has to change its 'cuid' for some reason, it
NOT do so when mitigations are still active for the old 'cuid'. MUST NOT do so when mitigations are still active for the old
The 'cuid' SHOULD be 22 characters to avoid DOTS signal message 'cuid'. The 'cuid' SHOULD be 22 characters to avoid DOTS
fragmentation over UDP. Furthermore, if that DOTS client created signal message fragmentation over UDP. Furthermore, if that
aliases and filtering entries at the DOTS server by means of the DOTS client created aliases and filtering entries at the DOTS
DOTS data channel, it MUST delete all the entries bound to the old server by means of the DOTS data channel, it MUST delete all
'cuid' and re-install them using the new 'cuid'. 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
to notify that the 'cuid' is already in-use by another DOTS peer to notify that the 'cuid' is already in-use by another
client. Upon receipt of that error code, a new 'cuid' MUST be DOTS client. Upon receipt of that error code, a new 'cuid'
generated by the DOTS peer (e.g., using [RFC4122]). MUST be 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
and it is RECOMMENDED that 'cuid' collision is handled directly by directly and it is RECOMMENDED that 'cuid' collision is handled
server-domain DOTS gateways. directly by 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.
Triggers for such rewriting are out of scope. Triggers for such rewriting are out of scope.
This is a mandatory Uri-Path parameter. This is a mandatory Uri-Path parameter.
mid: Identifier for the mitigation request represented with an mid: Identifier for the mitigation request represented with an
integer. This identifier MUST be unique for each mitigation integer. This identifier MUST be unique for each mitigation
request bound to the DOTS client, i.e., the 'mid' parameter value request bound to the DOTS client, i.e., the 'mid' parameter
in the mitigation request needs to be unique (per 'cuid' and DOTS value in the mitigation request needs to be unique (per 'cuid'
server) relative to the 'mid' parameter values of active and DOTS server) relative to the 'mid' parameter values of
mitigation requests conveyed from the DOTS client to the DOTS active mitigation requests conveyed from the DOTS client to the
server. DOTS server.
In order to handle out-of-order delivery of mitigation requests, In order to handle out-of-order delivery of mitigation
'mid' values MUST increase monotonically. requests, 'mid' values MUST increase monotonically.
If the 'mid' value has reached 3/4 of (2**32 - 1) (i.e., If the 'mid' value has reached 3/4 of (2**32 - 1) (i.e.,
3221225471) and no attack is detected, the DOTS client MUST reset 3221225471) and no attack is detected, the DOTS client MUST
'mid' to 0 to handle 'mid' rollover. If the DOTS client maintains reset 'mid' to 0 to handle 'mid' rollover. If the DOTS client
mitigation requests with pre-configured scopes, it MUST re-create maintains mitigation requests with pre-configured scopes, it
them with the 'mid' restarting at 0. MUST re-create them with the 'mid' restarting at 0.
This identifier MUST be generated by the DOTS client. This identifier MUST be generated by the DOTS client.
This is a mandatory Uri-Path parameter. This is a mandatory Uri-Path parameter.
'cuid' and 'mid' MUST NOT appear in the PUT request message body 'cuid' and 'mid' MUST NOT appear in the PUT request message body
(Figure 6). The schema in Figure 6 uses the types defined in (Figure 6). The schema in Figure 6 uses the types defined in
Section 6. Note that this figure (and other similar figures Section 6. Note that this figure (and other similar figures
depicting a schema) are non-normative sketches of the structure of depicting a schema) are non-normative sketches of the structure of
the message. the message.
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
skipping to change at page 19, line 44 skipping to change at page 19, line 44
{ {
... ...
} }
Figure 7: PUT for DOTS Mitigation Request as Relayed by a DOTS Figure 7: PUT for DOTS Mitigation Request as Relayed by a DOTS
Gateway Gateway
A server-domain DOTS gateway SHOULD add the following Uri-Path A server-domain DOTS gateway SHOULD add the following Uri-Path
parameter: parameter:
cdid: Stands for Client Domain Identifier. The 'cdid' is conveyed cdid: Stands for Client Domain Identifier. The 'cdid' is conveyed by
by a server-domain DOTS gateway to propagate the source domain a server-domain DOTS gateway to propagate the source domain
identity from the gateway's client-facing-side to the gateway's identity from the gateway's client-facing-side to the gateway's
server-facing-side, and from the gateway's server-facing-side to server-facing-side, and from the gateway's server-facing-side
the DOTS server. 'cdid' may be used by the final DOTS server for to the DOTS server. 'cdid' may be used by the final DOTS server
policy enforcement purposes (e.g., enforce a quota on filtering for policy enforcement purposes (e.g., enforce a quota on
rules). These policies are deployment-specific. filtering rules). These policies are deployment-specific.
Server-domain DOTS gateways SHOULD support a configuration option Server-domain DOTS gateways SHOULD support a configuration
to instruct whether 'cdid' parameter is to be inserted. option to instruct whether 'cdid' parameter is to be inserted.
In order to accommodate deployments that require enforcing per- In order to accommodate deployments that require enforcing per-
client policies, per-client domain policies, or a combination client policies, per-client domain policies, or a combination
thereof, server-domain DOTS gateways instructed to insert the thereof, server-domain DOTS gateways instructed to insert the
'cdid' parameter MUST supply the SPKI hash of the DOTS client 'cdid' parameter MUST supply the SPKI hash of the DOTS client
X.509 certificate, the DOTS client raw public key, or the hash of X.509 certificate, the DOTS client raw public key, or the hash
the "PSK identity" in the 'cdid', following the same rules for of the "PSK identity" in the 'cdid', following the same rules
generating the hash conveyed in 'cuid', which is then used by the for generating the hash conveyed in 'cuid', which is then used
ultimate DOTS server to determine the corresponding client's by the ultimate DOTS server to determine the corresponding
domain. The 'cdid' generated by a server-domain gateway is likely client's domain. The 'cdid' generated by a server-domain
to be the same as the 'cuid' except if the DOTS message was gateway is likely to be the same as the 'cuid' except if the
relayed by a client-domain DOTS gateway or the 'cuid' was DOTS message was relayed by a client-domain DOTS gateway or the
generated from a rogue DOTS client. 'cuid' was generated from a rogue DOTS client.
If a DOTS client is provisioned, for example, with distinct If a DOTS client is provisioned, for example, with distinct
certificates as a function of the peer server-domain DOTS gateway, certificates as a function of the peer server-domain DOTS
distinct 'cdid' values may be supplied by a server-domain DOTS gateway, distinct 'cdid' values may be supplied by a server-
gateway. The ultimate DOTS server MUST treat those 'cdid' values domain DOTS gateway. The ultimate DOTS server MUST treat those
as equivalent. 'cdid' values as equivalent.
The 'cdid' attribute MUST NOT be generated and included by DOTS The 'cdid' attribute MUST NOT be generated and included by DOTS
clients. clients.
DOTS servers MUST ignore 'cdid' attributes that are directly DOTS servers MUST ignore 'cdid' attributes that are directly
supplied by source DOTS clients or client-domain DOTS gateways. supplied by source DOTS clients or client-domain DOTS gateways.
This implies that first server-domain DOTS gateways MUST strip This implies that first server-domain DOTS gateways MUST strip
'cdid' attributes supplied by DOTS clients. DOTS servers SHOULD 'cdid' attributes supplied by DOTS clients. DOTS servers
support a configuration parameter to identify DOTS gateways that SHOULD support a configuration parameter to identify DOTS
are trusted to supply 'cdid' attributes. gateways that are trusted to supply 'cdid' attributes.
Only single-valued 'cdid' are defined in this document. That is, Only single-valued 'cdid' are defined in this document. That
only the first on-path server-domain DOTS gateway can insert a is, only the first on-path server-domain DOTS gateway can
'cdid' value. This specification does not allow multiple server- insert a 'cdid' value. This specification does not allow
domain DOTS gateways, whenever involved in the path, to insert a multiple server-domain DOTS gateways, whenever involved in the
'cdid' value for each server-domain gateway. 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
include multiple entries in the 'scope' array of the same PUT include multiple entries in the 'scope' array of the same PUT
request. request.
skipping to change at page 27, line 50 skipping to change at page 27, line 50
mitigation request before the expiry of this timer is likely to mitigation request before the expiry of this timer is likely to
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. conflicting mitigation request.
If the DOTS server decides to maintain a state for the If the DOTS server decides to maintain a state for the
deactivated mitigation request, the DOTS server updates the deactivated mitigation request, the DOTS server updates the
lifetime of the deactivated mitigation request to (retry-timer lifetime of the deactivated mitigation request to (retry-timer
+ 45 seconds), so that the DOTS client can refresh the + 45 seconds) so that the DOTS client can refresh the
deactivated mitigation request after 'retry-timer' seconds, but deactivated mitigation request after 'retry-timer' seconds, but
before the expiry of the lifetime, and check if the conflict is before the expiry of the lifetime, and check if the conflict is
resolved. resolved.
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=7eeaf349529eb55ed50113" Uri-Path: "cuid=7eeaf349529eb55ed50113"
Uri-Path: "mid=12" Uri-Path: "mid=12"
(1) Request with a conflicting 'cuid' (1) Request with a conflicting 'cuid'
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"conflict-information": { "conflict-information": {
"conflict-cause": "cuid-collision" "conflict-cause": "cuid-collision"
} }
} }
] ]
} }
} }
(2) Message body of the 4.09 (Conflict) response (2) Message body of the 4.09 (Conflict) response
from the DOTS server from the DOTS server
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=f30d281ce6b64fc5a0b91e" Uri-Path: "cuid=f30d281ce6b64fc5a0b91e"
Uri-Path: "mid=12" Uri-Path: "mid=12"
(3) Request with a new 'cuid' (3) Request with a new 'cuid'
Figure 11: Example of Generating 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
skipping to change at page 30, line 11 skipping to change at page 30, line 11
mitigation requests associated with the DOTS client does not fit mitigation requests associated with the DOTS client does not fit
within a single datagram, the DOTS server MUST use the Block2 Option within a single datagram, the DOTS server MUST use the Block2 Option
with NUM = 0 in the GET response. The Size2 Option may be conveyed with NUM = 0 in the GET response. The Size2 Option may be conveyed
in the response to indicate the total size of the resource in the response to indicate the total size of the resource
representation. The DOTS client retrieves the rest of the representation. The DOTS client retrieves the rest of the
representation by sending additional GET requests with Block2 Options representation by sending additional GET requests with Block2 Options
containing NUM values greater than zero. The DOTS client MUST adhere containing NUM values greater than zero. The DOTS client MUST adhere
to the block size preferences indicated by the DOTS server in the to the block size preferences indicated by the DOTS server in the
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 12 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.
skipping to change at page 48, line 49 skipping to change at page 48, line 49
{ {
... ...
} }
Figure 21: 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
channel). channel).
This is a mandatory attribute. This is a mandatory attribute.
{ {
"ietf-dots-signal-channel:signal-config": { "ietf-dots-signal-channel:signal-config": {
"mitigating-config": { "mitigating-config": {
"heartbeat-interval": { "heartbeat-interval": {
"current-value": number "current-value": number
}, },
"missing-hb-allowed": { "missing-hb-allowed": {
"current-value": number "current-value": number
}, },
skipping to change at page 56, line 34 skipping to change at page 56, line 34
receiving heartbeat probes from peer DOTS clients. As a reminder, it receiving heartbeat probes from peer DOTS clients. As a reminder, it
is the responsibility of DOTS clients to ensure that on-path is the responsibility of DOTS clients to ensure that on-path
translators/firewalls are maintaining a binding so that the same translators/firewalls are maintaining a binding so that the same
external IP address and/or port number is retained for the DOTS external IP address and/or port number is retained for the DOTS
signal channel session. signal channel session.
In case of a massive DDoS attack that saturates the incoming link(s) In case of a massive DDoS attack that saturates the incoming link(s)
to the DOTS client, all traffic from the DOTS server to the DOTS to the DOTS client, all traffic from the DOTS server to the DOTS
client will likely be dropped, although the DOTS server receives client will likely be dropped, although the DOTS server receives
heartbeat requests in addition to DOTS messages sent by the DOTS heartbeat requests in addition to DOTS messages sent by the DOTS
client. In this scenario, the DOTS agents MUST behave differently to client. In this scenario, DOTS clients MUST behave differently to
handle message transmission and DOTS signal channel session handle message transmission and DOTS signal channel session
liveliness during link saturation: liveliness during link saturation:
o The DOTS client MUST NOT consider the DOTS signal channel session The DOTS client MUST NOT consider the DOTS signal channel session
terminated even after a maximum 'missing-hb-allowed' threshold is terminated even after a maximum 'missing-hb-allowed' threshold is
reached. The DOTS client SHOULD keep on using the current DOTS reached. The DOTS client SHOULD keep on using the current DOTS
signal channel session to send heartbeat requests over it, so that signal channel session to send heartbeat requests over it, so that
the DOTS server knows the DOTS client has not disconnected the the DOTS server knows the DOTS client has not disconnected the
DOTS signal channel session. DOTS signal channel session.
After the maximum 'missing-hb-allowed' threshold is reached, the After the maximum 'missing-hb-allowed' threshold is reached, the
DOTS client SHOULD try to resume the (D)TLS session. The DOTS DOTS client SHOULD try to resume the (D)TLS session. The DOTS
client SHOULD send mitigation requests over the current DOTS client SHOULD send mitigation requests over the current DOTS
signal channel session, and in parallel, for example, try to signal channel session, and in parallel, for example, try to
resume the (D)TLS session or use 0-RTT mode in DTLS 1.3 to resume the (D)TLS session or use 0-RTT mode in DTLS 1.3 to
piggyback the mitigation request in the ClientHello message. piggyback the mitigation request in the ClientHello message.
As soon as the link is no longer saturated, if traffic from the As soon as the link is no longer saturated, if traffic from the
DOTS server reaches the DOTS client over the current DOTS signal DOTS server reaches the DOTS client over the current DOTS signal
channel session, the DOTS client can stop (D)TLS session channel session, the DOTS client can stop (D)TLS session
resumption or if (D)TLS session resumption is successful then resumption or if (D)TLS session resumption is successful then
disconnect the current DOTS signal channel session. disconnect the current DOTS signal channel session.
o If the DOTS server receives traffic from the peer DOTS client If the DOTS server receives traffic from the peer DOTS client (e.g.,
(e.g., peer DOTS client initiated heartbeats) but maximum peer DOTS client initiated heartbeats) but maximum 'missing-hb-
'missing-hb-allowed' threshold is reached, the DOTS server MUST allowed' threshold is reached, the DOTS server MUST NOT consider the
NOT consider the DOTS signal channel session disconnected. The DOTS signal channel session disconnected. The DOTS server MUST keep
DOTS server MUST keep on using the current DOTS signal channel on using the current DOTS signal channel session so that the DOTS
session so that the DOTS client can send mitigation requests over client can send mitigation requests over the current DOTS signal
the current DOTS signal channel session. In this case, the DOTS channel session. In this case, the DOTS server can identify the DOTS
server can identify the DOTS client is under attack and the client is under attack and the inbound link to the DOTS client
inbound link to the DOTS client (domain) is saturated. (domain) is saturated. Furthermore, if the DOTS server does not
Furthermore, if the DOTS server does not receive a mitigation receive a mitigation request from the DOTS client, it implies the
request from the DOTS client, it implies the DOTS client has not DOTS client has not detected the attack or, if an attack mitigation
detected the attack or, if an attack mitigation is in progress, it is in progress, it implies the applied DDoS mitigation actions are
implies the applied DDoS mitigation actions are not yet effective not yet effective to handle the DDoS attack volume.
to handle the DDoS attack volume.
o If the DOTS server does not receive any traffic from the peer DOTS If the DOTS server does not receive any traffic from the peer DOTS
client, then the DOTS server sends heartbeat requests to the DOTS client, then the DOTS server sends heartbeat requests to the DOTS
client and after maximum 'missing-hb-allowed' threshold is client and after maximum 'missing-hb-allowed' threshold is reached,
reached, the DOTS server concludes the session is disconnected. the DOTS server concludes the session is disconnected. The DOTS
The DOTS server can then trigger pre-configured mitigation server can then trigger pre-configured mitigation requests for this
requests for this DOTS client (if any). DOTS client (if any).
In DOTS over UDP, heartbeat messages MUST be exchanged between the In DOTS over UDP, heartbeat messages MUST be exchanged between the
DOTS agents using the "CoAP Ping" mechanism defined in Section 4.2 of DOTS agents using the "CoAP Ping" mechanism defined in Section 4.2 of
[RFC7252]. [RFC7252].
In DOTS over TCP, heartbeat messages MUST be exchanged between the In DOTS over TCP, heartbeat messages MUST be exchanged between the
DOTS agents using the Ping and Pong messages specified in Section 5.4 DOTS agents using the Ping and Pong messages specified in Section 5.4
of [RFC8323]. That is, the DOTS agent sends a Ping message and the of [RFC8323]. That is, the DOTS agent sends a Ping message and the
peer DOTS agent would respond by sending a single Pong message. peer DOTS agent would respond by sending a single Pong message.
skipping to change at page 81, line 9 skipping to change at page 81, line 9
The DOTS server should support certificate-based client The DOTS server should support certificate-based client
authentication. The DOTS client should respond to the DOTS server's authentication. The DOTS client should respond to the DOTS server's
TLS CertificateRequest message with the PKIX certificate held by the TLS CertificateRequest message with the PKIX certificate held by the
DOTS client. DOTS client certificate validation must be performed as DOTS client. DOTS client certificate validation must be performed as
per [RFC5280] and the DOTS client certificate must conform to the per [RFC5280] and the DOTS client certificate must conform to the
[RFC5280] certificate profile. If a DOTS client does not support TLS [RFC5280] certificate profile. If a DOTS client does not support TLS
client certificate authentication, it must support pre-shared key client certificate authentication, it must support pre-shared key
based or raw public key based client authentication. based or raw public key based client authentication.
+-----------------------------------------------+ +---------------------------------------------+
| example.com domain +---------+ | | example.com domain +---------+ |
| | AAA | | | | AAA | |
| +---------------+ | Server | | | +---------------+ | Server | |
| | Application | +------+--+ | | | Application | +------+--+ |
| | server +<-----------------+ ^ | | | server +<---------------+ ^ |
| | (DOTS client) | | | | | | (DOTS client) | | | |
| +---------------+ | | | | +---------------+ | | |
| V V | example.net domain | V V | example.net domain
| +-----+----+--+ | +---------------+ | +-----+----+--+ | +---------------+
| +--------------+ | | | | | | +--------------+ | | | | |
| | Guest +<-----x----->+ DOTS +<------>+ DOTS | | | Guest +<----x---->+ DOTS +<------>+ DOTS |
| | (DOTS client)| | gateway | | | server | | | (DOTS client)| | gateway | | | server |
| +--------------+ | | | | | | +--------------+ | | | | |
| +----+--------+ | +---------------+ | +----+--------+ | +---------------+
| ^ | | ^ |
| | | | | |
| +----------------+ | | | +----------------+ | |
| | DDoS detector | | | | | DDoS detector | | |
| | (DOTS client) +<---------------+ | | | (DOTS client) +<-------------+ |
| +----------------+ | | +----------------+ |
+-----------------------------------------------+ +---------------------------------------------+
Figure 28: Example of Authentication and Authorization of DOTS Agents Figure 28: Example of Authentication and Authorization of DOTS Agents
In the example depicted in Figure 28, 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
skipping to change at page 104, line 18 skipping to change at page 104, line 18
Andrew Mortensen Andrew Mortensen
Arbor Networks, Inc. Arbor Networks, Inc.
2727 S. State St 2727 S. State St
Ann Arbor, MI 48104 Ann Arbor, MI 48104
United States United States
Email: andrew@moretension.com Email: andrew@moretension.com
Nik Teague Nik Teague
Verisign, Inc. Iron Mountain Data Centers
United States United Kingdom
Email: nteague@verisign.com Email: nteague@ironmountain.co.uk
 End of changes. 41 change blocks. 
169 lines changed or deleted 170 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/