< draft-ietf-dots-telemetry-24.txt   draft-ietf-dots-telemetry-25.txt >
DOTS M. Boucadair, Ed. DOTS M. Boucadair, Ed.
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track T. Reddy.K, Ed. Intended status: Standards Track T. Reddy.K, Ed.
Expires: 27 August 2022 Akamai Expires: 22 September 2022 Akamai
E. Doron E. Doron
Radware Ltd. Radware Ltd.
M. Chen M. Chen
CMCC CMCC
J. Shallow J. Shallow
23 February 2022 21 March 2022
Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
draft-ietf-dots-telemetry-24 draft-ietf-dots-telemetry-25
Abstract Abstract
This document aims to enrich the DOTS signal channel protocol with This document aims to enrich the DOTS signal channel protocol with
various telemetry attributes, allowing for optimal Distributed various telemetry attributes, allowing for optimal Distributed
Denial-of-Service (DDoS) attack mitigation. It specifies the normal Denial-of-Service (DDoS) attack mitigation. It specifies the normal
traffic baseline and attack traffic telemetry attributes a DOTS traffic baseline and attack traffic telemetry attributes a DOTS
client can convey to its DOTS server in the mitigation request, the client can convey to its DOTS server in the mitigation request, the
mitigation status telemetry attributes a DOTS server can communicate mitigation status telemetry attributes a DOTS server can communicate
to a DOTS client, and the mitigation efficacy telemetry attributes a to a DOTS client, and the mitigation efficacy telemetry attributes a
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 27 August 2022. This Internet-Draft will expire on 22 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 21, line 27 skipping to change at page 21, line 27
"current-config": { "current-config": {
"low-percentile": "5.00", "low-percentile": "5.00",
"mid-percentile": "65.00", "mid-percentile": "65.00",
"high-percentile": "95.00" "high-percentile": "95.00"
} }
} }
] ]
} }
} }
Figure 4: PUT to Convey the DOTS Telemetry Configuration Figure 4: PUT to Convey the DOTS Telemetry Configuration,
depicted as per Section 5.6
'cuid' is a mandatory Uri-Path parameter for PUT requests. 'cuid' is a mandatory Uri-Path parameter for PUT requests.
The following additional Uri-Path parameter is defined: The following additional Uri-Path parameter is defined:
tsid: Telemetry Setup Identifier is an identifier for the DOTS tsid: Telemetry Setup Identifier is an identifier for the DOTS
telemetry setup configuration data represented as an integer. telemetry setup configuration data represented as an integer.
This identifier MUST be generated by DOTS clients. 'tsid' This identifier MUST be generated by DOTS clients. 'tsid'
values MUST increase monotonically whenever new configuration values MUST increase monotonically whenever new configuration
parameters (not just for changed values) need to be conveyed by parameters (not just for changed values) need to be conveyed by
skipping to change at page 23, line 27 skipping to change at page 23, line 27
"current-config": { "current-config": {
"low-percentile": "0.00", "low-percentile": "0.00",
"mid-percentile": "0.00", "mid-percentile": "0.00",
"high-percentile": "95.00" "high-percentile": "95.00"
} }
} }
] ]
} }
} }
Figure 5: PUT to Disable Low- and Mid-Percentiles Figure 5: PUT to Disable Low- and Mid-Percentiles, depicted as
per Section 5.6
DOTS clients can also configure the unit class(es) to be used for DOTS clients can also configure the unit class(es) to be used for
traffic-related telemetry data among the following supported unit traffic-related telemetry data among the following supported unit
classes: packets per second, bits per second, and bytes per second. classes: packets per second, bits per second, and bytes per second.
Supplying both bits per second and bytes per second unit-classes is Supplying both bits per second and bytes per second unit-classes is
allowed for a given telemetry data. However, receipt of conflicting allowed for a given telemetry data. However, receipt of conflicting
values is treated as invalid parameters and rejected with 4.00 (Bad values is treated as invalid parameters and rejected with 4.00 (Bad
Request). Request).
DOTS clients that are interested to receive pre or ongoing mitigation DOTS clients that are interested to receive pre or ongoing mitigation
skipping to change at page 24, line 26 skipping to change at page 24, line 26
{ {
"current-config": { "current-config": {
"server-originated-telemetry": true "server-originated-telemetry": true
} }
} }
] ]
} }
} }
Figure 6: PUT to Enable Pre-or-ongoing-mitigation Telemetry from Figure 6: PUT to Enable Pre-or-ongoing-mitigation Telemetry from
the DOTS server the DOTS server, depicted as per Section 5.6
7.1.3. Retrieve Installed DOTS Telemetry Configuration 7.1.3. Retrieve Installed DOTS Telemetry Configuration
A DOTS client may issue a GET message with 'tsid' Uri-Path parameter A DOTS client may issue a GET message with 'tsid' Uri-Path parameter
to retrieve the current DOTS telemetry configuration. An example of to retrieve the current DOTS telemetry configuration. An example of
such a request is depicted in Figure 7. such a request is depicted in Figure 7.
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
skipping to change at page 28, line 5 skipping to change at page 28, line 5
"link-id": "link1", "link-id": "link1",
"capacity": "500", "capacity": "500",
"unit": "megabit-ps" "unit": "megabit-ps"
} }
] ]
} }
] ]
} }
} }
Figure 11: Example of a PUT Request to Convey Pipe Information Figure 11: Example of a PUT Request to Convey Pipe Information
(Single Homed) (Single Homed), depicted as per Section 5.6
DOTS clients may be instructed to signal a link aggregate instead of DOTS clients may be instructed to signal a link aggregate instead of
individual links. For example, a DOTS client that manages a DOTS individual links. For example, a DOTS client that manages a DOTS
client domain having two interconnection links with an upstream ISP client domain having two interconnection links with an upstream ISP
(Figure 12) can send a PUT request (shown in Figure 13) to (Figure 12) can send a PUT request (shown in Figure 13) to
communicate the aggregate link capacity with its ISP. Signaling communicate the aggregate link capacity with its ISP. Signaling
individual or aggregate link capacity is deployment specific. individual or aggregate link capacity is deployment specific.
,--,--,--. ,--,--,--. ,--,--,--. ,--,--,--.
,-' `-.===== ,-' `-. ,-' `-.===== ,-' `-.
skipping to change at page 28, line 47 skipping to change at page 28, line 47
"capacity": "700", "capacity": "700",
"unit": "megabit-ps" "unit": "megabit-ps"
} }
] ]
} }
] ]
} }
} }
Figure 13: Example of a PUT Request to Convey Pipe Information Figure 13: Example of a PUT Request to Convey Pipe Information
(Aggregated Link) (Aggregated Link), depicted as per Section 5.6
Now consider that the DOTS client domain was upgraded to connect to Now consider that the DOTS client domain was upgraded to connect to
an additional ISP (e.g., ISP#B of Figure 14); the DOTS client can an additional ISP (e.g., ISP#B of Figure 14); the DOTS client can
inform a DOTS server that is not hosted with ISP#A and ISP#B domains inform a DOTS server that is not hosted with ISP#A and ISP#B domains
about this update by sending the PUT request depicted in Figure 15. about this update by sending the PUT request depicted in Figure 15.
This request also includes information related to "link1" even if This request also includes information related to "link1" even if
that link is not upgraded. Upon receipt of this request, the DOTS that link is not upgraded. Upon receipt of this request, the DOTS
server removes the request with 'tsid=126' and updates its server removes the request with 'tsid=126' and updates its
configuration base to maintain two links (link#1 and link#2). configuration base to maintain two links (link#1 and link#2).
skipping to change at page 30, line 35 skipping to change at page 30, line 35
"capacity": "500", "capacity": "500",
"unit": "megabit-ps" "unit": "megabit-ps"
} }
] ]
} }
] ]
} }
} }
Figure 15: Example of a PUT Request to Convey Pipe Information Figure 15: Example of a PUT Request to Convey Pipe Information
(Multi-Homed) (Multi-Homed), depicted as per Section 5.6
A DOTS client can delete a link by sending a PUT request with the A DOTS client can delete a link by sending a PUT request with the
'capacity' attribute set to "0" if other links are still active for 'capacity' attribute set to "0" if other links are still active for
the same DOTS client domain (see Section 7.2.3 for other delete the same DOTS client domain (see Section 7.2.3 for other delete
cases). For example, if a DOTS client domain re-homes (that is, it cases). For example, if a DOTS client domain re-homes (that is, it
changes its ISP), the DOTS client can inform its DOTS server about changes its ISP), the DOTS client can inform its DOTS server about
this update (e.g., from the network configuration in Figure 10 to the this update (e.g., from the network configuration in Figure 10 to the
one shown in Figure 16) by sending the PUT request depicted in one shown in Figure 16) by sending the PUT request depicted in
Figure 17. Upon receipt of this request, and assuming no error is Figure 17. Upon receipt of this request, and assuming no error is
encountered when processing the request, the DOTS server removes encountered when processing the request, the DOTS server removes
skipping to change at page 31, line 50 skipping to change at page 31, line 50
"capacity": "500", "capacity": "500",
"unit": "megabit-ps" "unit": "megabit-ps"
} }
] ]
} }
] ]
} }
} }
Figure 17: Example of a PUT Request to Convey Pipe Information Figure 17: Example of a PUT Request to Convey Pipe Information
(Multi-Homed) (Multi-Homed), depicted as per Section 5.6
7.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity 7.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity
A GET request with 'tsid' Uri-Path parameter is used to retrieve a A GET request with 'tsid' Uri-Path parameter is used to retrieve a
specific installed DOTS client domain pipe related information. The specific installed DOTS client domain pipe related information. The
same procedure as defined in Section 7.1.3 is followed. same procedure as defined in Section 7.1.3 is followed.
To retrieve all pipe information bound to a DOTS client, the DOTS To retrieve all pipe information bound to a DOTS client, the DOTS
client proceeds as specified in Section 7.1.1. client proceeds as specified in Section 7.1.1.
skipping to change at page 37, line 37 skipping to change at page 37, line 37
"peak-g": "60" "peak-g": "60"
} }
] ]
} }
] ]
} }
] ]
} }
} }
Figure 19: PUT to Conveying the DOTS Traffic Baseline Figure 19: PUT to Conveying the DOTS Traffic Baseline, depicted
as per Section 5.6
The DOTS client may share protocol specific baseline information The DOTS client may share protocol specific baseline information
(e.g., TCP and UDP) as shown in Figure 20. (e.g., TCP and UDP) as shown in Figure 20.
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: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=130" Uri-Path: "tsid=130"
skipping to change at page 38, line 43 skipping to change at page 38, line 43
"peak-g": "10" "peak-g": "10"
} }
] ]
} }
] ]
} }
] ]
} }
} }
Figure 20: PUT to Convey the DOTS Traffic Baseline (2) Figure 20: PUT to Convey the DOTS Traffic Baseline (2), depicted
as per Section 5.6
The normal traffic baseline information should be updated to reflect The normal traffic baseline information should be updated to reflect
legitimate overloads (e.g., flash crowds) to prevent unnecessary legitimate overloads (e.g., flash crowds) to prevent unnecessary
mitigation. mitigation.
7.3.2. Retrieve Installed Normal Traffic Baseline 7.3.2. Retrieve Installed Normal Traffic Baseline
A GET request with 'tsid' Uri-Path parameter is used to retrieve a A GET request with 'tsid' Uri-Path parameter is used to retrieve a
specific installed DOTS client domain baseline traffic information. specific installed DOTS client domain baseline traffic information.
The same procedure as defined in Section 7.1.3 is followed. The same procedure as defined in Section 7.1.3 is followed.
skipping to change at page 50, line 35 skipping to change at page 50, line 35
attack-id: Unique identifier assigned for the attack by a vendor. attack-id: Unique identifier assigned for the attack by a vendor.
This parameter MUST be present independent of whether 'attack- This parameter MUST be present independent of whether 'attack-
description' is included or not. description' is included or not.
description-lang: Indicates the language tag that is used for the description-lang: Indicates the language tag that is used for the
text that is included in the 'attack-description' attribute. The text that is included in the 'attack-description' attribute. The
attribute is encoded following the rules in Section 2.1 of attribute is encoded following the rules in Section 2.1 of
[RFC5646]. The default language tag is "en-US". [RFC5646]. The default language tag is "en-US".
attack-description: Textual representation of the attack attack-description: Textual representation of the attack
description. Natural Language Processing techniques (e.g., word description. This description is related to the class of attack
embedding) might provide some utility in mapping the attack rather than a specific instance of it. Natural Language
description to an attack type. Textual representation of attack Processing techniques (e.g., word embedding) might provide some
solves two problems: (a) avoids the need to create mapping tables utility in mapping the attack description to an attack type.
manually between vendors and (b) avoids the need to standardize Textual representation of attack solves two problems: (a) avoids
attack types which keep evolving. the need to create mapping tables manually between vendors and (b)
avoids the need to standardize attack types which keep evolving.
attack-severity: Attack severity level. This attribute takes one of attack-severity: Attack severity level. This attribute takes one of
the values defined in Section 3.12.2 of [RFC7970]. the values defined in Section 3.12.2 of [RFC7970].
start-time: The time the attack started. The attack's start time is start-time: The time the attack started. The attack's start time is
expressed in seconds relative to 1970-01-01T00:00Z (Section 3.4.2 expressed in seconds relative to 1970-01-01T00:00Z (Section 3.4.2
of [RFC8949]). The CBOR encoding is modified so that the leading of [RFC8949]). The CBOR encoding is modified so that the leading
tag 1 (epoch-based date/time) MUST be omitted. tag 1 (epoch-based date/time) MUST be omitted.
end-time: The time the attack ended. The attack end time is end-time: The time the attack ended. The attack end time is
skipping to change at page 58, line 42 skipping to change at page 58, line 42
"attack-id": 77, "attack-id": 77,
"start-time": "1608336568", "start-time": "1608336568",
"attack-severity": "high" "attack-severity": "high"
} }
] ]
} }
] ]
} }
} }
Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry,
depicted as per Section 5.6
'cuid' is a mandatory Uri-Path parameter for DOTS PUT requests. 'cuid' is a mandatory Uri-Path parameter for DOTS PUT requests.
The following additional Uri-Path parameter is defined: The following additional Uri-Path parameter is defined:
tmid: Telemetry Identifier is an identifier for the DOTS pre-or- tmid: Telemetry Identifier is an identifier for the DOTS pre-or-
ongoing-mitigation telemetry data represented as an integer. ongoing-mitigation telemetry data represented as an integer.
This identifier MUST be generated by DOTS clients. 'tmid' values This identifier MUST be generated by DOTS clients. 'tmid' values
MUST increase monotonically whenever a DOTS client needs to MUST increase monotonically whenever a DOTS client needs to
convey new set of pre-or-ongoing-mitigation telemetry. convey new set of pre-or-ongoing-mitigation telemetry.
skipping to change at page 61, line 27 skipping to change at page 61, line 31
"target": { "target": {
"target-prefix": [ "target-prefix": [
"2001:db8::/32" "2001:db8::/32"
] ]
} }
} }
] ]
} }
} }
Figure 39: PUT to Request Pre-or-Ongoing-Mitigation Telemetry Figure 39: PUT to Request Pre-or-Ongoing-Mitigation Telemetry,
depicted as per Section 5.6
DOTS clients of the same domain can request to receive pre-or- DOTS clients of the same domain can request to receive pre-or-
ongoing-mitigation telemetry bound to the same target without being ongoing-mitigation telemetry bound to the same target without being
considered to be "overlapping" and in conflict. considered to be "overlapping" and in conflict.
Once the PUT request to instantiate request state on the server has Once the PUT request to instantiate request state on the server has
succeeded, the DOTS client issues a GET request to receive ongoing succeeded, the DOTS client issues a GET request to receive ongoing
telemtry updates. The client uses the Observe Option, set to '0' telemtry updates. The client uses the Observe Option, set to '0'
(register), in the GET request to receive asynchronous notifications (register), in the GET request to receive asynchronous notifications
carrying pre-or-ongoing-mitigation telemetry data from the DOTS carrying pre-or-ongoing-mitigation telemetry data from the DOTS
skipping to change at page 64, line 38 skipping to change at page 64, line 38
"start-time": "1618339785", "start-time": "1618339785",
"attack-severity": "high" "attack-severity": "high"
} }
] ]
} }
] ]
} }
} }
Figure 43: Message Body of a Pre-or-Ongoing-Mitigation Telemetry Figure 43: Message Body of a Pre-or-Ongoing-Mitigation Telemetry
Notification from the DOTS Server Notification from the DOTS Server, depicted as per Section 5.6
A DOTS server sends the aggregate data for a target using 'total- A DOTS server sends the aggregate data for a target using 'total-
attack-traffic' attribute. The aggregate assumes that Uri-Query attack-traffic' attribute. The aggregate assumes that Uri-Query
filters are applied on the target. The DOTS server MAY include more filters are applied on the target. The DOTS server MAY include more
fine-grained data when needed (that is, 'total-attack-traffic- fine-grained data when needed (that is, 'total-attack-traffic-
protocol' and 'total-attack-traffic-port'). If a port filter (or protocol' and 'total-attack-traffic-port'). If a port filter (or
protocol filter) is included in a request, 'total-attack-traffic- protocol filter) is included in a request, 'total-attack-traffic-
protocol' (or 'total-attack-traffic-port') conveys the data with the protocol' (or 'total-attack-traffic-port') conveys the data with the
port (or protocol) filter applied. port (or protocol) filter applied.
skipping to change at page 67, line 38 skipping to change at page 67, line 38
"unit": "megabit-ps", "unit": "megabit-ps",
"mid-percentile-g": "900" "mid-percentile-g": "900"
} }
] ]
} }
] ]
} }
} }
Figure 45: An Example of Mitigation Efficacy Update with Figure 45: An Example of Mitigation Efficacy Update with
Telemetry Attributes Telemetry Attributes, depicted as per Section 5.6
9.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry 9.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry
Attributes Attributes
The mitigation status telemetry attributes can be signaled from the The mitigation status telemetry attributes can be signaled from the
DOTS server to the DOTS client as part of the periodic mitigation DOTS server to the DOTS client as part of the periodic mitigation
status update (Section 4.4.2 of [RFC9132]). In particular, DOTS status update (Section 4.4.2 of [RFC9132]). In particular, DOTS
clients can receive asynchronous notifications of the attack details clients can receive asynchronous notifications of the attack details
from DOTS servers using the Observe option defined in [RFC7641]. from DOTS servers using the Observe option defined in [RFC7641].
skipping to change at page 70, line 50 skipping to change at page 70, line 50
"peak-g": "12683" "peak-g": "12683"
} }
} }
] ]
} }
] ]
} }
} }
Figure 47: Response Body of a Mitigation Status With Telemetry Figure 47: Response Body of a Mitigation Status With Telemetry
Attributes Attributes, depicted as per Section 5.6
DOTS clients can filter out the asynchronous notifications from the DOTS clients can filter out the asynchronous notifications from the
DOTS server by indicating one or more Uri-Query options in its GET DOTS server by indicating one or more Uri-Query options in its GET
request. A Uri-Query option can include the following parameters: request. A Uri-Query option can include the following parameters:
'target-prefix', 'target-port', 'target-protocol', 'target-fqdn', 'target-prefix', 'target-port', 'target-protocol', 'target-fqdn',
'target-uri', 'alias-name', and 'c' (content) (Section 5.4). The 'target-uri', 'alias-name', and 'c' (content) (Section 5.4). The
considerations discussed in Section 8.3 MUST be followed to include considerations discussed in Section 8.3 MUST be followed to include
multiple query values, ranges ('target-port', 'target-protocol'), and multiple query values, ranges ('target-port', 'target-protocol'), and
wildcard names ('target-fqdn', 'target-uri'). wildcard names ('target-fqdn', 'target-uri').
 End of changes. 19 change blocks. 
24 lines changed or deleted 31 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/