| < 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/ | ||||