< draft-ietf-dots-telemetry-06.txt   draft-ietf-dots-telemetry-07.txt >
DOTS M. Boucadair, Ed. DOTS M. Boucadair, Ed.
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track T. Reddy, Ed. Intended status: Standards Track T. Reddy, Ed.
Expires: October 9, 2020 McAfee Expires: October 17, 2020 McAfee
E. Doron E. Doron
Radware Ltd. Radware Ltd.
M. Chen M. Chen
CMCC CMCC
April 7, 2020 April 15, 2020
Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
draft-ietf-dots-telemetry-06 draft-ietf-dots-telemetry-07
Abstract Abstract
This document aims to enrich DOTS signal channel protocol with This document aims to enrich DOTS signal channel protocol with
various telemetry attributes allowing optimal DDoS attack mitigation. various telemetry attributes allowing optimal DDoS attack mitigation.
It specifies the normal traffic baseline and attack traffic telemetry It specifies the normal traffic baseline and attack traffic telemetry
attributes a DOTS client can convey to its DOTS server in the attributes a DOTS client can convey to its DOTS server in the
mitigation request, the mitigation status telemetry attributes a DOTS mitigation request, the mitigation status telemetry attributes a DOTS
server can communicate to a DOTS client, and the mitigation efficacy server can communicate to a DOTS client, and the mitigation efficacy
telemetry attributes a DOTS client can communicate to a DOTS server. telemetry attributes a DOTS client can communicate to a DOTS server.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 October 9, 2020. This Internet-Draft will expire on October 17, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 3, line 11 skipping to change at page 3, line 11
7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 39 7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 39
7.1.4. Total Attack Connections . . . . . . . . . . . . . . 41 7.1.4. Total Attack Connections . . . . . . . . . . . . . . 41
7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 42 7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 42
7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 44 7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 44
7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 47 7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 47
8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 51 8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 51
8.1. DOTS Clients to Servers Mitigation Efficacy DOTS 8.1. DOTS Clients to Servers Mitigation Efficacy DOTS
Telemetry Attributes . . . . . . . . . . . . . . . . . . 51 Telemetry Attributes . . . . . . . . . . . . . . . . . . 51
8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry 8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry
Attributes . . . . . . . . . . . . . . . . . . . . . . . 52 Attributes . . . . . . . . . . . . . . . . . . . . . . . 53
9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 56 9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 57
10. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 81 10. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 83
11. IANA Considerationsr . . . . . . . . . . . . . . . . . . . . 85 11. IANA Considerationsr . . . . . . . . . . . . . . . . . . . . 87
11.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 85 11.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 87
11.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 89 11.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 91
11.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 90 11.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 91
12. Security Considerations . . . . . . . . . . . . . . . . . . . 90 12. Security Considerations . . . . . . . . . . . . . . . . . . . 91
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 90 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 91
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 92
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 92
15.1. Normative References . . . . . . . . . . . . . . . . . . 91 15.1. Normative References . . . . . . . . . . . . . . . . . . 92
15.2. Informative References . . . . . . . . . . . . . . . . . 92 15.2. Informative References . . . . . . . . . . . . . . . . . 93
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94
1. Introduction 1. Introduction
Distributed Denial of Service (DDoS) attacks have become more Distributed Denial of Service (DDoS) attacks have become more
sophisticated. IT organizations and service providers are facing sophisticated. IT organizations and service providers are facing
DDoS attacks that fall into two broad categories: DDoS attacks that fall into two broad categories:
1. Network/Transport layer attacks target the victim's 1. Network/Transport layer attacks target the victim's
infrastructure. These attacks are not necessarily aimed at infrastructure. These attacks are not necessarily aimed at
taking down the actual delivered services, but rather to taking down the actual delivered services, but rather to
skipping to change at page 10, line 19 skipping to change at page 10, line 19
[I-D.ietf-dots-signal-channel] to control the size of a response when [I-D.ietf-dots-signal-channel] to control the size of a response when
the data to be returned does not fit within a single datagram. the data to be returned does not fit within a single datagram.
DOTS clients can also use Block1 Option in a PUT request (see DOTS clients can also use Block1 Option in a PUT request (see
Section 2.5 of [RFC7959]) to initiate large transfers, but these Section 2.5 of [RFC7959]) to initiate large transfers, but these
Block1 transfers will fail if the inbound "pipe" is running full, so Block1 transfers will fail if the inbound "pipe" is running full, so
consideration needs to be made to try to fit this PUT into a single consideration needs to be made to try to fit this PUT into a single
transfer, or to separate out the PUT into several discrete PUTs where transfer, or to separate out the PUT into several discrete PUTs where
each of them fits into a single packet. each of them fits into a single packet.
Block3 and Block 4 options that are similar to the CoAP Block1 and
Block2 options, but enable faster transmissions of big blocks of data
with less packet interchanges, are defined in
[I-D.bosh-core-new-block]. DOTS implementations can consider the use
of Block3 and Block 4 options.
4.6. DOTS Multi-homing Considerations 4.6. DOTS Multi-homing Considerations
Multi-homed DOTS clients are assumed to follow the recommendations in Multi-homed DOTS clients are assumed to follow the recommendations in
[I-D.ietf-dots-multihoming] to select which DOTS server to contact [I-D.ietf-dots-multihoming] to select which DOTS server to contact
and which IP prefixes to include in a telemetry message to a given and which IP prefixes to include in a telemetry message to a given
peer DOTS server. For example, if each upstream network exposes a peer DOTS server. For example, if each upstream network exposes a
DOTS server and the DOTS client maintains DOTS channels with all of DOTS server and the DOTS client maintains DOTS channels with all of
them, only the information related to prefixes assigned by an them, only the information related to prefixes assigned by an
upstream network to the DOTS client domain will be signaled via the upstream network to the DOTS client domain will be signaled via the
DOTS channel established with the DOTS server of that upstream DOTS channel established with the DOTS server of that upstream
network. Considerations related to whether (and how) a DOTS client network. Considerations related to whether (and how) a DOTS client
gleans some telemetry information (e.g., attack details) it receives gleans some telemetry information (e.g., attack details) it receives
from a first DOTS server and share it with a second DOTS server are from a first DOTS server and share it with a second DOTS server are
implementation- and deployment-specific. implementation and deployment-specific.
4.7. YANG Considerations 4.7. YANG Considerations
Messages exchanged between DOTS agents are serialized using Concise Messages exchanged between DOTS agents are serialized using Concise
Binary Object Representation (CBOR). CBOR-encoded payloads are used Binary Object Representation (CBOR). CBOR-encoded payloads are used
to carry signal channel-specific payload messages which convey to carry signal channel-specific payload messages which convey
request parameters and response information such as errors request parameters and response information such as errors
[I-D.ietf-dots-signal-channel]. [I-D.ietf-dots-signal-channel].
This document specifies a YANG module for representing DOTS telemetry This document specifies a YANG module for representing DOTS telemetry
skipping to change at page 12, line 39 skipping to change at page 12, line 39
A DOTS client can reset all installed DOTS telemetry setup A DOTS client can reset all installed DOTS telemetry setup
configuration data following the considerations detailed in configuration data following the considerations detailed in
Section 6.4. Section 6.4.
A DOTS server may detect conflicts when processing requests related A DOTS server may detect conflicts when processing requests related
to DOTS client domain pipe capacity or telemetry traffic baseline to DOTS client domain pipe capacity or telemetry traffic baseline
with requests from other DOTS clients of the same DOTS client domain. with requests from other DOTS clients of the same DOTS client domain.
More details are included in Section 6.5. More details are included in Section 6.5.
Telemetry setup configuration is bound to a DOTS client domain. DOTS Telemetry setup configuration is bound to a DOTS client domain. DOTS
serves MUST NOT expect DOTS clients to send regular requests to servers MUST NOT expect DOTS clients to send regular requests to
refresh the telemetry setup configuration. Any available telemetry refresh the telemetry setup configuration. Any available telemetry
setup configuration has a validity timeout of the DOTS session with a setup configuration has a validity timeout of the DOTS association
DOTS client domain. DOTS clients update their telemetry setup with a DOTS client domain. DOTS servers MUST NOT reset 'tsid'
configuration upon change of a parameter that may impact attack because a session failed with a DOTS client. DOTS clients update
mitigation. their telemetry setup configuration upon change of a parameter that
may impact attack mitigation.
DOTS telemetry setup configuration request and response messages are DOTS telemetry setup configuration request and response messages are
marked as Confirmable messages. marked as Confirmable messages.
6.1. Telemetry Configuration 6.1. Telemetry Configuration
A DOTS client can negotiate with its server(s) a set of telemetry A DOTS client can negotiate with its server(s) a set of telemetry
configuration parameters to be used for telemetry. Such parameters configuration parameters to be used for telemetry. Such parameters
include: include:
skipping to change at page 14, line 4 skipping to change at page 14, line 4
acceptable by the DOTS server. The tree structure of the response acceptable by the DOTS server. The tree structure of the response
message body is provided in Figure 3. Note that the response also message body is provided in Figure 3. Note that the response also
includes any pipe (Section 6.2) and baseline information includes any pipe (Section 6.2) and baseline information
(Section 6.3) maintained by the DOTS server for this DOTS client. (Section 6.3) maintained by the DOTS server for this DOTS client.
DOTS servers that support the capability of sending telemetry DOTS servers that support the capability of sending telemetry
information to DOTS clients prior or during a mitigation information to DOTS clients prior or during a mitigation
(Section 8.2) sets 'server-originated-telemetry' under 'max-config- (Section 8.2) sets 'server-originated-telemetry' under 'max-config-
values' to 'true' ('false' is used otherwise). If 'server- values' to 'true' ('false' is used otherwise). If 'server-
originated-telemetry' is not present in a response, this is originated-telemetry' is not present in a response, this is
equivalent to receiving a request with 'server-originated-telemetry'' equivalent to receiving a request with 'server-originated-telemetry'
set to 'false'. set to 'false'.
augment /ietf-signal:dots-signal/ietf-signal:message-type: augment /ietf-signal:dots-signal/ietf-signal:message-type:
+--:(telemetry-setup) {dots-telemetry}? +--:(telemetry-setup) {dots-telemetry}?
| +--ro max-config-values | +--ro max-config-values
| | +--ro measurement-interval? interval | | +--ro measurement-interval? interval
| | +--ro measurement-sample? sample | | +--ro measurement-sample? sample
| | +--ro low-percentile? percentile | | +--ro low-percentile? percentile
| | +--ro mid-percentile? percentile | | +--ro mid-percentile? percentile
| | +--ro high-percentile? percentile | | +--ro high-percentile? percentile
skipping to change at page 15, line 25 skipping to change at page 15, line 25
| +--ro min-config-values | +--ro min-config-values
| | +--ro measurement-interval? interval | | +--ro measurement-interval? interval
| | +--ro measurement-sample? sample | | +--ro measurement-sample? sample
| | +--ro low-percentile? percentile | | +--ro low-percentile? percentile
| | +--ro mid-percentile? percentile | | +--ro mid-percentile? percentile
| | +--ro high-percentile? percentile | | +--ro high-percentile? percentile
| | +--ro telemetry-notify-interval? uint32 | | +--ro telemetry-notify-interval? uint32
| +--ro supported-units | +--ro supported-units
| | +--ro unit-config* [unit] | | +--ro unit-config* [unit]
| | +--ro unit unit-type | | +--ro unit unit-type
| | +--ro unit-status? boolean | | +--ro unit-status boolean
| +--rw telemetry* [cuid tsid] | +--rw telemetry* [cuid tsid]
| +--rw cuid string | +--rw cuid string
| +--rw cdid? string | +--rw cdid? string
| +--rw tsid uint32 | +--rw tsid uint32
| +--rw (setup-type)? | +--rw (setup-type)?
| +--:(telemetry-config) | +--:(telemetry-config)
| | +--rw current-config | | +--rw current-config
| | +--rw measurement-interval? interval | | +--rw measurement-interval? interval
| | +--rw measurement-sample? sample | | +--rw measurement-sample? sample
| | +--rw low-percentile? percentile | | +--rw low-percentile? percentile
| | +--rw mid-percentile? percentile | | +--rw mid-percentile? percentile
| | +--rw high-percentile? percentile | | +--rw high-percentile? percentile
| | +--rw unit-config* [unit] | | +--rw unit-config* [unit]
| | | +--rw unit unit-type | | | +--rw unit unit-type
| | | +--rw unit-status? boolean | | | +--rw unit-status boolean
| | +--rw server-originated-telemetry? boolean | | +--rw server-originated-telemetry? boolean
| | +--rw telemetry-notify-interval? uint32 | | +--rw telemetry-notify-interval? uint32
| +--:(pipe) | +--:(pipe)
| ... | ...
| +--:(baseline) | +--:(baseline)
| ... | ...
+--:(telemetry) {dots-telemetry}? +--:(telemetry) {dots-telemetry}?
+--rw pre-or-ongoing-mitigation* [cuid tmid] +--rw pre-or-ongoing-mitigation* [cuid tmid]
... ...
skipping to change at page 16, line 20 skipping to change at page 16, line 20
6.1.2. Convey DOTS Telemetry Configuration 6.1.2. Convey DOTS Telemetry Configuration
PUT request is used to convey the configuration parameters for the PUT request is used to convey the configuration parameters for the
telemetry data (e.g., low, mid, or high percentile values). For telemetry data (e.g., low, mid, or high percentile values). For
example, a DOTS client may contact its DOTS server to change the example, a DOTS client may contact its DOTS server to change the
default percentile values used as baseline for telemetry data. default percentile values used as baseline for telemetry data.
Figure 3 lists the attributes that can be set by a DOTS client in Figure 3 lists the attributes that can be set by a DOTS client in
such PUT request. An example of a DOTS client that modifies all such PUT request. An example of a DOTS client that modifies all
percentile reference values is shown in Figure 4. percentile reference values is shown in Figure 4.
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=123" Uri-Path: "tsid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
{ {
"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
'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'
skipping to change at page 18, line 13 skipping to change at page 18, line 13
indicates that the DOTS client is not interested in receiving low- indicates that the DOTS client is not interested in receiving low-
percentiles. Likewise, setting 'mid-percentile' (or 'high- percentiles. Likewise, setting 'mid-percentile' (or 'high-
percentile') to the same value as 'low-percentile' (or 'mid- percentile') to the same value as 'low-percentile' (or 'mid-
percentile') indicates that the DOTS client is not interested in percentile') indicates that the DOTS client is not interested in
receiving mid-percentiles (or high-percentiles). For example, a DOTS receiving mid-percentiles (or high-percentiles). For example, a DOTS
client can send the request depicted in Figure 5 to inform the server client can send the request depicted in Figure 5 to inform the server
that it is interested in receiving only high-percentiles. This that it is interested in receiving only high-percentiles. This
assumes that the client will only use that percentile type when assumes that the client will only use that percentile type when
sharing telemetry data with the server. sharing telemetry data with the 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: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=569" Uri-Path: "tsid=569"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
{ {
"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
DOTS clients can also configure the unit type(s) to be used for DOTS clients can also configure the unit type(s) to be used for
traffic-related telemetry data. Typically, the supported unit types traffic-related telemetry data. Typically, the supported unit types
are: packets per second, bits per second, and bytes per second. are: packets per second, bits per second, and bytes per second.
DOTS clients that are interested to receive pre- or onoing mitigation DOTS clients that are interested to receive pre- or ongoing
telemetry (pre-or-ongoing-mitigation) information from a DOTS server mitigation telemetry (pre-or-ongoing-mitigation) information from a
(Section 8.2) MUST set 'server-originated-telemetry' to 'true'. If DOTS server (Section 8.2) MUST set 'server-originated-telemetry' to
'server-originated-telemetry' is not present in a PUT request, this 'true'. If 'server-originated-telemetry' is not present in a PUT
is equivalent to receiving a request with 'server-originated- request, this is equivalent to receiving a request with 'server-
telemetry'' set to 'false'. An example of a request to enable pre- originated-telemetry' set to 'false'. An example of a request to
or-ongoing-mitigation telemetry from DOTS servers is shown in enable pre-or-ongoing-mitigation telemetry from DOTS servers is shown
Figure 6. in Figure 6.
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=569" Uri-Path: "tsid=569"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
{ {
"current-config": { "current-config": {
"server-originated-telemetry": true "server-originated-telemetry": true
} }
} }
] ]
}
} }
}
Figure 6: PUT to Enable Pre-or-ongoing-mitigation Telemetry from the Figure 6: PUT to Enable Pre-or-ongoing-mitigation Telemetry from the
DOTS server DOTS server
6.1.3. Retrieve Installed DOTS Telemetry Configuration 6.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 request is depicted in Figure 7. such request is depicted in Figure 7.
skipping to change at page 20, line 5 skipping to change at page 20, line 5
If the DOTS server does not find the 'tsid' Uri-Path value conveyed If the DOTS server does not find the 'tsid' Uri-Path value conveyed
in the GET request in its configuration data for the requesting DOTS in the GET request in its configuration data for the requesting DOTS
client, it MUST respond with a 4.04 (Not Found) error response code. client, it MUST respond with a 4.04 (Not Found) error response code.
6.1.4. Delete DOTS Telemetry Configuration 6.1.4. Delete DOTS Telemetry Configuration
A DELETE request is used to delete the installed DOTS telemetry A DELETE request is used to delete the installed DOTS telemetry
configuration data (Figure 8). 'cuid' and 'tsid' are mandatory Uri- configuration data (Figure 8). 'cuid' and 'tsid' are mandatory Uri-
Path parameters for such DELETE requests. Path parameters for such DELETE requests.
Header: DELETE (Code=0.04) Header: DELETE (Code=0.04)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=123" Uri-Path: "tsid=123"
Figure 8: Delete Telemetry Configuration Figure 8: Delete Telemetry Configuration
The DOTS server resets the DOTS telemetry configuration back to the The DOTS server resets the DOTS telemetry configuration back to the
default values and acknowledges a DOTS client's request to remove the default values and acknowledges a DOTS client's request to remove the
DOTS telemetry configuration using 2.02 (Deleted) response code. A DOTS telemetry configuration using 2.02 (Deleted) response code. A
2.02 (Deleted) Response Code is returned even if the 'tsid' parameter 2.02 (Deleted) Response Code is returned even if the 'tsid' parameter
value conveyed in the DELETE request does not exist in its value conveyed in the DELETE request does not exist in its
configuration data before the request. configuration data before the request.
skipping to change at page 22, line 5 skipping to change at page 22, line 5
capacity of "link1" used to connect to its ISP. capacity of "link1" used to connect to its ISP.
,--,--,--. ,--,--,--. ,--,--,--. ,--,--,--.
,-' `-. ,-' `-. ,-' `-. ,-' `-.
( DOTS Client )=====( ISP#A ) ( DOTS Client )=====( ISP#A )
`-. Domain ,-' link1 `-. ,-' `-. Domain ,-' link1 `-. ,-'
`--'--'--' `--'--'--' `--'--'--' `--'--'--'
Figure 10: Single Homed DOTS Client Domain Figure 10: Single Homed DOTS Client Domain
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=457" Uri-Path: "tsid=457"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
{ {
"total-pipe-capacity": [ "total-pipe-capacity": [
{ {
"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)
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 managing a DOTS client individual links. For example, a DOTS client managing a DOTS client
domain having two interconnection links with an upstream ISP 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. Signalling communicate the aggregate link capacity with its ISP. Signalling
individual or aggregate link capacity is deployment-specific. individual or aggregate link capacity is deployment-specific.
,--,--,--. ,--,--,--. ,--,--,--. ,--,--,--.
,-' `-.===== ,-' `-. ,-' `-.===== ,-' `-.
( DOTS Client ) ( ISP#C ) ( DOTS Client ) ( ISP#C )
`-. Domain ,-'====== `-. ,-' `-. Domain ,-'====== `-. ,-'
`--'--'--' `--'--'--' `--'--'--' `--'--'--'
Figure 12: DOTS Client Domain with Two Interconnection Links Figure 12: DOTS Client Domain with Two Interconnection Links
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=896" Uri-Path: "tsid=896"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
{ {
"total-pipe-capacity": [ "total-pipe-capacity": [
{ {
"link-id": "aggregate", "link-id": "aggregate",
"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)
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 (ISP#B of Figure 14), the DOTS client can inform a an additional ISP (ISP#B of Figure 14), the DOTS client can inform a
third-party DOTS server (that is, not hosted with ISP#A and ISP#B third-party DOTS server (that is, not hosted with ISP#A and ISP#B
domains) about this update by sending the PUT request depicted in domains) about this update by sending the PUT request depicted in
Figure 15. This request also includes information related to "link1" Figure 15. This request also includes information related to "link1"
even if that link is not upgraded. Upon receipt of this request, the even if that link is not upgraded. Upon receipt of this request, the
skipping to change at page 24, line 20 skipping to change at page 24, line 20
|| ||
|| link2 || link2
,--,--,--. ,--,--,--. ,--,--,--. ,--,--,--.
,-' `-. ,-' `-. ,-' `-. ,-' `-.
( DOTS Client )=====( ISP#A ) ( DOTS Client )=====( ISP#A )
`-. Domain ,-' link1 `-. ,-' `-. Domain ,-' link1 `-. ,-'
`--'--'--' `--'--'--' `--'--'--' `--'--'--'
Figure 14: Multi-Homed DOTS Client Domain Figure 14: Multi-Homed DOTS Client Domain
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=458" Uri-Path: "tsid=458"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
{ {
"total-pipe-capacity": [ "total-pipe-capacity": [
{ {
"link-id": "link1", "link-id": "link1",
"capacity": "500", "capacity": "500",
"unit": "megabit-ps" "unit": "megabit-ps"
}, },
{ {
"link-id": "link2", "link-id": "link2",
"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)
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 6.2.3 for other delete the same DOTS client domain (see Section 6.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
skipping to change at page 26, line 5 skipping to change at page 26, line 5
|| ||
|| link2 || link2
,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
( DOTS Client ) ( DOTS Client )
`-. Domain ,-' `-. Domain ,-'
`--'--'--' `--'--'--'
Figure 16: Multi-Homed DOTS Client Domain Figure 16: Multi-Homed DOTS Client Domain
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=459" Uri-Path: "tsid=459"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry-setup": { "ietf-dots-telemetry:telemetry-setup": {
"telemetry": [ "telemetry": [
{ {
"total-pipe-capacity": [ "total-pipe-capacity": [
{ {
"link-id": "link1", "link-id": "link1",
"capacity": "0", "capacity": "0",
"unit": "megabit-ps" "unit": "megabit-ps"
}, },
{ {
"link-id": "link2", "link-id": "link2",
"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)
6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity 6.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 6.1.3) is followed. same procedure as defined in (Section 6.1.3) is followed.
skipping to change at page 30, line 19 skipping to change at page 30, line 19
The relative order of two PUT requests carrying DOTS client domain The relative order of two PUT requests carrying DOTS client domain
baseline attributes from a DOTS client is determined by comparing baseline attributes from a DOTS client is determined by comparing
their respective 'tsid' values. If such two requests have their respective 'tsid' values. If such two requests have
overlapping targets, the PUT request with higher numeric 'tsid' overlapping targets, the PUT request with higher numeric 'tsid'
value will override the request with a lower numeric 'tsid' value. value will override the request with a lower numeric 'tsid' value.
The overlapped lower numeric 'tsid' MUST be automatically deleted The overlapped lower numeric 'tsid' MUST be automatically deleted
and no longer be available. and no longer be available.
Two PUT requests from a DOTS client have overlapping targets if there Two PUT requests from a DOTS client have overlapping targets if there
is a common IP address, IP prefix, FQDN, or URI. is a common IP address, IP prefix, FQDN, URI, or alias-name. Also,
two PUT requests from a DOTS client have overlapping targets if the
addresses associated with the FQDN, URI, or alias are overlapping
with each other or with target-prefix.
DOTS clients SHOULD minimize the number of active 'tsids' used for DOTS clients SHOULD minimize the number of active 'tsids' used for
baseline information. Typically, in order to avoid maintaining a baseline information. Typically, in order to avoid maintaining a
long list of 'tsids' for baseline information, it is RECOMMENDED that long list of 'tsids' for baseline information, it is RECOMMENDED that
DOTS clients include in a request to update information related to a DOTS clients include in a request to update information related to a
given target, the information of other targets (already communicated given target, the information of other targets (already communicated
using a lower 'tsid' value) (assuming this fits within one single using a lower 'tsid' value) (assuming this fits within one single
datagram). This update request will override these existing requests datagram). This update request will override these existing requests
and hence optimize the number of 'tsid' request per DOTS client. and hence optimize the number of 'tsid' request per DOTS client.
If no target clause in included in the request, this is an indication If no target clause in included in the request, this is an indication
that the baseline information applies for the DOTS client domain as a that the baseline information applies for the DOTS client domain as a
whole. whole.
An example of a PUT request to convey the baseline information is An example of a PUT request to convey the baseline information is
shown in Figure 19. shown in Figure 19.
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=126" Uri-Path: "tsid=126"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry-setup": {
{ "telemetry": [
"ietf-dots-telemetry:telemetry-setup": { {
"telemetry": [ "baseline": [
{ {
"baseline": { "id": 1,
"id": 1, "target-prefix": [
"target-prefix": [ "2001:db8:6401::1/128",
"2001:db8:6401::1/128", "2001:db8:6401::2/128"
"2001:db8:6401::2/128" ],
], "total-traffic-normal": [
"total-traffic-normal": [{ {
"unit": "megabit-ps", "unit": "megabit-ps",
"peak-g": "60" "peak-g": "60"
}] }
} ]
} }
] ]
} }
]
} }
}
Figure 19: PUT to Convey the DOTS Traffic Baseline Figure 19: PUT to Convey the DOTS Traffic Baseline
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 19. (e.g., TCP and UDP) as shown in Figure 19.
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=128" Uri-Path: "tsid=128"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry-setup": {
{ "telemetry": [
"ietf-dots-telemetry:telemetry-setup": { {
"telemetry": [ "baseline": [
{ {
"baseline": { "id": 1,
"id": 1, "target-prefix": [
"target-prefix": [ "2001:db8:6401::1/128",
"2001:db8:6401::1/128", "2001:db8:6401::2/128"
"2001:db8:6401::2/128" ],
], "total-traffic-normal-per-protocol": [
"total-traffic-normal-per-protocol": [ {
{
"unit": "megabit-ps", "unit": "megabit-ps",
"protocol": 6, "protocol": 6,
"peak-g": "50" "peak-g": "50"
}, },
{ {
"unit": "megabit-ps", "unit": "megabit-ps",
"protocol": 17, "protocol": 17,
"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)
The traffic baseline information should be updated to reflect The 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.
6.3.2. Retrieve Installed Normal Traffic Baseline 6.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
skipping to change at page 33, line 28 skipping to change at page 33, line 28
(Section 6.1.4) is followed. (Section 6.1.4) is followed.
6.4. Reset Installed Telemetry Setup 6.4. Reset Installed Telemetry Setup
Upon bootstrapping (or reboot or any other event that may alter the Upon bootstrapping (or reboot or any other event that may alter the
DOTS client setup), a DOTS client MAY send a DELETE request to set DOTS client setup), a DOTS client MAY send a DELETE request to set
the telemetry parameters to default values. Such a request does not the telemetry parameters to default values. Such a request does not
include any 'tsid'. An example of such request is depicted in include any 'tsid'. An example of such request is depicted in
Figure 21. Figure 21.
Header: DELETE (Code=0.04) Header: DELETE (Code=0.04)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm-setup" Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Figure 21: Delete Telemetry Configuration Figure 21: Delete Telemetry Configuration
6.5. Conflict with Other DOTS Clients of the Same Domain 6.5. Conflict with Other DOTS Clients of the Same Domain
A DOTS server may detect conflicts between requests to convey pipe A DOTS server may detect conflicts between requests to convey pipe
and baseline information received from DOTS clients of the same DOTS and baseline information received from DOTS clients of the same DOTS
client domain. 'conflict-information' is used to report the conflict client domain. 'conflict-information' is used to report the conflict
to the DOTS client following similar conflict handling discussed in to the DOTS client following similar conflict handling discussed in
Section 4.4.1 of [I-D.ietf-dots-signal-channel]. The conflict cause Section 4.4.1 of [I-D.ietf-dots-signal-channel]. The conflict cause
skipping to change at page 34, line 10 skipping to change at page 34, line 10
1: Overlapping targets (already defined in 1: Overlapping targets (already defined in
[I-D.ietf-dots-signal-channel]). [I-D.ietf-dots-signal-channel]).
TBA: Overlapping pipe scope (see Section 11). TBA: Overlapping pipe scope (see Section 11).
7. DOTS Pre-or-Ongoing Mitigation Telemetry 7. DOTS Pre-or-Ongoing Mitigation Telemetry
There are two broad types of DDoS attacks, one is bandwidth consuming There are two broad types of DDoS attacks, one is bandwidth consuming
attack, the other is target resource consuming attack. This section attack, the other is target resource consuming attack. This section
outlines the set of DOTS telemetry attributes (Section 7.1) that outlines the set of DOTS telemetry attributes (Section 7.1) that
covers both the types of attacks. The ultimate objective of these covers both the types of attacks. The objective of these attributes
attributes is to allow for the complete knowledge of attacks and the is to allow for the complete knowledge of attacks and the various
various particulars that can best characterize attacks. particulars that can best characterize attacks.
The "ietf-dots-telemetry" YANG module (Section 9) augments the "ietf- The "ietf-dots-telemetry" YANG module (Section 9) augments the "ietf-
dots-signal" with a new message type called "telemetry". The tree dots-signal" with a new message type called "telemetry". The tree
structure of the "telemetry" message type is shown Figure 24. structure of the "telemetry" message type is shown Figure 24.
The pre-or-ongoing-mitigation telemetry attributes are indicated by The pre-or-ongoing-mitigation telemetry attributes are indicated by
the path-suffix '/tm'. The '/tm' is appended to the path-prefix to the path-suffix '/tm'. The '/tm' is appended to the path-prefix to
form the URI used with a CoAP request to signal the DOTS telemetry. form the URI used with a CoAP request to signal the DOTS telemetry.
Pre-or-ongoing-mitigation telemetry attributes specified in Pre-or-ongoing-mitigation telemetry attributes specified in
Section 7.1 can be signaled between DOTS agents. Section 7.1 can be signaled between DOTS agents.
skipping to change at page 35, line 18 skipping to change at page 35, line 18
| | | |
|<=============== Telemetry (target-prefix)=============| |<=============== Telemetry (target-prefix)=============|
| | | |
|=========Mitigation Request (target-prefix)===========>| |=========Mitigation Request (target-prefix)===========>|
| | | |
Figure 23: Example of Request Correlation using Target Prefix Figure 23: Example of Request Correlation using Target Prefix
DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry
messages to the same peer more frequently than once every 'telemetry- messages to the same peer more frequently than once every 'telemetry-
notify-interval' (Section 6.1). notify-interval' (Section 6.1). If a telemetry notification is sent
using a block-like transfer mechanism (e.g.,
[I-D.bosh-core-new-block]), this rate limit policy MUST NOT consider
these individual blocks as separate notifications, but as a single
notification.
DOTS pre-or-ongoing-mitigation telemetry request and response DOTS pre-or-ongoing-mitigation telemetry request and response
messages MUST be marked as Non-Confirmable messages. messages MUST be marked as Non-Confirmable messages.
augment /ietf-signal:dots-signal/ietf-signal:message-type: augment /ietf-signal:dots-signal/ietf-signal:message-type:
+--:(telemetry-setup) {dots-telemetry}? +--:(telemetry-setup) {dots-telemetry}?
| +--rw telemetry* [cuid tsid] | +--rw telemetry* [cuid tsid]
| ... | ...
+--:(telemetry) {dots-telemetry}? +--:(telemetry) {dots-telemetry}?
+--rw pre-or-ongoing-mitigation* [cuid tmid] +--rw pre-or-ongoing-mitigation* [cuid tmid]
skipping to change at page 36, line 48 skipping to change at page 36, line 48
The description and motivation behind each attribute are presented in The description and motivation behind each attribute are presented in
Section 3. DOTS telemetry attributes are optionally signaled and Section 3. DOTS telemetry attributes are optionally signaled and
therefore MUST NOT be treated as mandatory fields in the DOTS signal therefore MUST NOT be treated as mandatory fields in the DOTS signal
channel protocol. channel protocol.
7.1.1. Target 7.1.1. Target
A target resource (Figure 25) is identified using the attributes A target resource (Figure 25) is identified using the attributes
'target-prefix', 'target-port-range', 'target-protocol', 'target- 'target-prefix', 'target-port-range', 'target-protocol', 'target-
fqdn', 'target-uri', or 'alias-name' defined in the base DOTS signal fqdn', 'target-uri', 'alias-name', or a pointer to a mitigation
channel protocol. request ('mid-list').
+--:(telemetry) {dots-telemetry}? +--:(telemetry) {dots-telemetry}?
+--rw pre-or-ongoing-mitigation* [cuid tmid] +--rw pre-or-ongoing-mitigation* [cuid tmid]
+--rw cuid string +--rw cuid string
+--rw cdid? string +--rw cdid? string
+--rw tmid uint32 +--rw tmid uint32
+--rw target +--rw target
| +--rw target-prefix* inet:ip-prefix | +--rw target-prefix* inet:ip-prefix
| +--rw target-port-range* [lower-port] | +--rw target-port-range* [lower-port]
| | +--rw lower-port inet:port-number | | +--rw lower-port inet:port-number
skipping to change at page 45, line 15 skipping to change at page 45, line 15
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" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=123" Uri-Path: "tmid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": { "pre-or-ongoing-mitigation": [
"target": { {
{ "target": {
"target-prefix": [ "target-prefix": [
"2001:db8::1/128" "2001:db8::1/128"
],
"total-attack-traffic-protocol": [
{
"protocol": 17,
"unit": "megabit-ps",
"mid-percentile-g": "900"
}
],
"attack-detail": [
{
"attack-id": "an-id";
"start-time": "1957811234",
"attack-severity": "emergency"
}
] ]
} },
} "total-attack-traffic-protocol": [
} {
"protocol": 17,
"unit": "megabit-ps",
"mid-percentile-g": "900"
}
],
"attack-detail": [
{
"attack-id": "an-id",
"start-time": "1957811234",
"attack-severity": "emergency"
}
]
}
]
} }
} }
Figure 30: PUT to Send Pre-or-Ongoing-Mitigation Telemetry Figure 30: PUT to Send Pre-or-Ongoing-Mitigation Telemetry
'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:
tmid: Telemetry Identifier is an identifier for the DOTS pre-or- tmid: Telemetry Identifier is an identifier for the DOTS pre-or-
skipping to change at page 46, line 42 skipping to change at page 46, line 42
DOTS server as a function of the updates received from the peer DOTS DOTS server as a function of the updates received from the peer DOTS
client. client.
A DOTS client that lost the state of its active 'tmids' or has to set A DOTS client that lost the state of its active 'tmids' or has to set
'tmid' back to zero (e.g., crash or restart) MUST send a GET request 'tmid' back to zero (e.g., crash or restart) MUST send a GET request
to the DOTS server to retrieve the list of active 'tmid'. The DOTS to the DOTS server to retrieve the list of active 'tmid'. The DOTS
client may then delete 'tmids' that should not be active anymore client may then delete 'tmids' that should not be active anymore
(Figure 31). Sending a DELETE with no 'tmid' indicates that all (Figure 31). Sending a DELETE with no 'tmid' indicates that all
'tmids' must be deactivated (Figure 32). 'tmids' must be deactivated (Figure 32).
Header: DELETE (Code=0.04) Header: DELETE (Code=0.04)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=123" Uri-Path: "tmid=123"
Figure 31: Delete a Pre-or-Ongoing-Mitigation Telemetry Figure 31: Delete a Pre-or-Ongoing-Mitigation Telemetry
Header: DELETE (Code=0.04) Header: DELETE (Code=0.04)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "tm" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Figure 32: Delete All Pre-or-Ongoing-Mitigation Telemetry Figure 32: Delete All Pre-or-Ongoing-Mitigation Telemetry
7.3. From DOTS Servers to DOTS Clients 7.3. From DOTS Servers to DOTS Clients
The pre-or-ongoing-mitigation (attack details, in particular) can The pre-or-ongoing-mitigation (attack details, in particular) can
also be signaled from DOTS servers to DOTS clients. For example, the also be signaled from DOTS servers to DOTS clients. For example, the
DOTS server co-located with a DDoS detector collects monitoring DOTS server co-located with a DDoS detector collects monitoring
information from the target network, identifies DDoS attack using information from the target network, identifies DDoS attack using
statistical analysis or deep learning techniques, and signals the statistical analysis or deep learning techniques, and signals the
skipping to change at page 48, line 15 skipping to change at page 48, line 15
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" Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=123" Uri-Path: "tmid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": { "pre-or-ongoing-mitigation": [
"target": { {
{ "target": {
"target-prefix": [ "target-prefix": [
"2001:db8::/32" "2001:db8::/32"
] ]
} }
} }
} ]
} }
} }
Figure 33: PUT to Request Pre-or-Ongoing-Mitigation Telemetry Figure 33: PUT to Request Pre-or-Ongoing-Mitigation Telemetry
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. ongoing-mitigation telemetry bound to the same target.
The DOTS client conveys the Observe Option set to '0' in the GET The DOTS client conveys the Observe Option set to '0' in the GET
request to receive asynchronous notifications carrying pre-or- request to receive asynchronous notifications carrying pre-or-
skipping to change at page 50, line 5 skipping to change at page 50, line 5
Figure 36: GET Request to Receive Telemetry Asynchronous Figure 36: GET Request to Receive Telemetry Asynchronous
Notifications Filtered using Uri-Query Notifications Filtered using Uri-Query
The DOTS server will send asynchronous notifications to the DOTS The DOTS server will send asynchronous notifications to the DOTS
client when an attack event is detected following similar client when an attack event is detected following similar
considerations as in Section 4.4.2.1 of considerations as in Section 4.4.2.1 of
[I-D.ietf-dots-signal-channel]. An example of a pre-or-ongoing- [I-D.ietf-dots-signal-channel]. An example of a pre-or-ongoing-
mitigation telemetry notification is shown in Figure 37. mitigation telemetry notification is shown in Figure 37.
{ {
"ietf-dots-telemetry:telemetry": { "ietf-dots-telemetry:telemetry": {
"pre-or-ongoing-mitigation": { "pre-or-ongoing-mitigation": [
"target": { {
{ "tmid": 123,
"tmid": 123, "target": {
"target-prefix": [ "target-prefix": [
"2001:db8::1/128" "2001:db8::1/128"
], ]
"target-protocol": [17], },
"total-attack-traffic": [ "target-protocol": [
{ 17
"unit": "megabit-ps", ],
"mid-percentile-g": "900" "total-attack-traffic": [
} {
], "unit": "megabit-ps",
"attack-detail": [ "mid-percentile-g": "900"
{ }
"attack-id": "an-id", ],
"start-time": "1957818434", "attack-detail": [
"attack-severity": "emergency" {
} "attack-id": "an-id",
] "start-time": "1957818434",
} "attack-severity": "emergency"
} }
} ]
} }
} ]
}
}
Figure 37: Message Body of a Pre-or-Ongoing-Mitigation Telemetry Figure 37: Message Body of a Pre-or-Ongoing-Mitigation Telemetry
Notification from the DOTS Server Notification from the DOTS Server
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. It may includes more granular data when attack-traffic' attribute. The aggregate assumes that Uri-Query
needed (that is, 'total-attack-traffic-protocol' and 'total-attack- filters are applied on the target. The DOTS server MAY include more
traffic-port'). granular data when needed (that is, 'total-attack-traffic-protocol'
and 'total-attack-traffic-port'). If a port filter (or protocol
filter) is included in a request, 'total-attack-traffic-protocol' (or
'total-attack-traffic-port') conveys the data with the port (or
protocol) filter applied.
A DOTS server may aggregate pre-or-ongoing-mitigation data (e.g., A DOTS server may aggregate pre-or-ongoing-mitigation data (e.g.,
'top-talkers') for all targets of a domain, or when justified, send 'top-talkers') for all targets of a domain, or when justified, send
specific information (e.g., 'top-talkers') per individual targets. specific information (e.g., 'top-talkers') per individual targets.
The DOTS client may log pre-or-ongoing-mitigation telemetry data with The DOTS client may log pre-or-ongoing-mitigation telemetry data with
an alert sent to an administrator or a network controller. The DOTS an alert sent to an administrator or a network controller. The DOTS
client may send a mitigation request if the attack cannot be handled client may send a mitigation request if the attack cannot be handled
locally. locally.
skipping to change at page 52, line 5 skipping to change at page 53, line 5
| ... | ...
+--rw top-talker +--rw top-talker
... ...
Figure 38: Telemetry Efficacy Update Tree Structure Figure 38: Telemetry Efficacy Update Tree Structure
In order to signal telemetry data in a mitigation efficacy update, it In order to signal telemetry data in a mitigation efficacy update, it
is RECOMMENDED that the DOTS client has already established a DOTS is RECOMMENDED that the DOTS client has already established a DOTS
telemetry setup session with the server in 'idle' time. telemetry setup session with the server in 'idle' time.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
If-Match: If-Match:
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"alias-name": [ "alias-name": [
"https1", "https1",
"https2" "https2"
], ],
"attack-status": "under-attack", "attack-status": "under-attack",
"ietf-dots-telemetry:total-attack-traffic": [ "ietf-dots-telemetry:total-attack-traffic": [
{ {
"ietf-dots-telemetry:unit": "megabit-ps", "ietf-dots-telemetry:unit": "megabit-ps",
"ietf-dots-telemetry:mid-percentile-g": "900" "ietf-dots-telemetry:mid-percentile-g": "900"
} }
] ]
} }
] ]
}
} }
}
Figure 39: An Example of Mitigation Efficacy Update with Telemetry Figure 39: An Example of Mitigation Efficacy Update with Telemetry
Attributes Attributes
8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry 8.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 5.3.3 of [I-D.ietf-dots-signal-channel]). In status update (Section 5.3.3 of [I-D.ietf-dots-signal-channel]). In
skipping to change at page 55, line 5 skipping to change at page 56, line 5
+--rw high-percentile-c +--rw high-percentile-c
| ... | ...
+--rw peak-c +--rw peak-c
... ...
Figure 40 shows an example of an asynchronous notification of attack Figure 40 shows an example of an asynchronous notification of attack
mitigation status from the DOTS server. This notification signals mitigation status from the DOTS server. This notification signals
both the mid-percentile value of processed attack traffic and the both the mid-percentile value of processed attack traffic and the
peak percentile value of unique sources involved in the attack. peak percentile value of unique sources involved in the attack.
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"mid": 12332, "mid": 12332,
"mitigation-start": "1507818434", "mitigation-start": "1507818434",
"alias-name": ["https1", "https2"], "alias-name": [
"lifetime": 1600, "https1",
"status": "attack-successfully-mitigated", "https2"
"bytes-dropped": "134334555", ],
"bps-dropped": "43344", "lifetime": 1600,
"pkts-dropped": "333334444", "status": "attack-successfully-mitigated",
"pps-dropped": "432432", "bytes-dropped": "134334555",
"ietf-dots-telemetry:total-attack-traffic": [ "bps-dropped": "43344",
{ "pkts-dropped": "333334444",
"ietf-dots-telemetry:unit": "megabit-ps", "pps-dropped": "432432",
"ietf-dots-telemetry:mid-percentile-g": "900" "ietf-dots-telemetry:total-attack-traffic": [
} {
], "ietf-dots-telemetry:unit": "megabit-ps",
"ietf-dots-telemetry::attack-detail": [ "ietf-dots-telemetry:mid-percentile-g": "900"
{ }
"ietf-dots-telemetry:attack-id": "another-id", ],
"ietf-dots-telemetry:source-count": { "ietf-dots-telemetry::attack-detail": [
"ietf-dots-telemetry:peak-g": "10000" {
} "ietf-dots-telemetry:attack-id": "another-id",
} "ietf-dots-telemetry:source-count": {
] "ietf-dots-telemetry:peak-g": "10000"
} }
] }
} ]
} }
]
}
}
Figure 40: Response Body of a Mitigation Status With Telemetry Figure 40: Response Body of a Mitigation Status With Telemetry
Attributes Attributes
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, lower-port, upper-port, target-protocol, target-fqdn, target-prefix, lower-port, upper-port, target-protocol, target-fqdn,
target-uri, alias-name. An example of request to subscribe to target-uri, alias-name. An example of request to subscribe to
asynchronous notifications bound to the "http1" alias is shown in asynchronous notifications bound to the "http1" alias is shown in
Figure 41. Figure 41.
Header: GET (Code=0.01) Header: GET (Code=0.01)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=12332" Uri-Path: "mid=12332"
Uri-Query: "target-alias=https1" Uri-Query: "target-alias=https1"
Observe: 0 Observe: 0
Figure 41: GET Request to Receive Asynchronous Notifications Filtered Figure 41: GET Request to Receive Asynchronous Notifications Filtered
using Uri-Query using Uri-Query
If the target query does not match the target of the enclosed 'mid' If the target query does not match the target of the enclosed 'mid'
as maintained by the DOTS server, the latter MUST respond with a 4.04 as maintained by the DOTS server, the latter MUST respond with a 4.04
(Not Found) error response code. The DOTS server MUST NOT add a new (Not Found) error response code. The DOTS server MUST NOT add a new
observe entry if this query overlaps with an existing one. observe entry if this query overlaps with an existing one.
9. YANG Module 9. YANG Module
This module uses types defined in [RFC6991] and [RFC8345]. This module uses types defined in [RFC6991] and [RFC8345].
<CODE BEGINS> file "ietf-dots-telemetry@2020-04-03.yang" <CODE BEGINS> file "ietf-dots-telemetry@2020-04-15.yang"
module ietf-dots-telemetry { module ietf-dots-telemetry {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry"; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry";
prefix dots-telemetry; prefix dots-telemetry;
import ietf-dots-signal-channel { import ietf-dots-signal-channel {
prefix ietf-signal; prefix ietf-signal;
reference reference
"RFC SSSS: Distributed Denial-of-Service Open Threat "RFC SSSS: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
skipping to change at page 57, line 42 skipping to change at page 58, line 42
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 2020-04-03 { revision 2020-04-15 {
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) Telemetry"; Signaling (DOTS) Telemetry";
} }
feature dots-telemetry { feature dots-telemetry {
description description
"This feature means that the DOTS signal channel is able "This feature means that the DOTS signal channel is able
skipping to change at page 64, line 17 skipping to change at page 65, line 17
description description
"Controls which units are allowed when sharing telemetry "Controls which units are allowed when sharing telemetry
data."; data.";
leaf unit { leaf unit {
type unit-type; type unit-type;
description description
"Can be packet-ps, bit-ps, or byte-ps."; "Can be packet-ps, bit-ps, or byte-ps.";
} }
leaf unit-status { leaf unit-status {
type boolean; type boolean;
mandatory true;
description description
"Enable/disable the use of the measurement unit."; "Enable/disable the use of the measurement unit.";
} }
} }
} }
grouping traffic-unit { grouping traffic-unit {
description description
"Grouping of traffic as a function of measurement unit."; "Grouping of traffic as a function of measurement unit.";
leaf unit { leaf unit {
skipping to change at page 70, line 34 skipping to change at page 71, line 36
leaf attack-name { leaf attack-name {
type string; type string;
description description
"Textual representation of attack description. Natural Language "Textual representation of attack description. Natural Language
Processing techniques (e.g., word embedding) can possibly be used Processing techniques (e.g., word embedding) can possibly be used
to map the attack description to an attack type."; to map the attack description to an attack type.";
} }
leaf attack-severity { leaf attack-severity {
type attack-severity; type attack-severity;
description description
"Severity level of an attack"; "Severity level of an attack. How this level is determined
is implementation-specific.";
} }
leaf start-time { leaf start-time {
type uint64; type uint64;
description description
"The time the attack started. Start time is represented in seconds "The time the attack started. Start time is represented in seconds
relative to 1970-01-01T00:00:00Z in UTC time."; relative to 1970-01-01T00:00:00Z in UTC time.";
} }
leaf end-time { leaf end-time {
type uint64; type uint64;
description description
skipping to change at page 75, line 23 skipping to change at page 76, line 26
"Grouping for the telemetry data."; "Grouping for the telemetry data.";
list total-traffic { list total-traffic {
key "unit"; key "unit";
description description
"Total traffic."; "Total traffic.";
uses traffic-unit; uses traffic-unit;
} }
list total-traffic-protocol { list total-traffic-protocol {
key "unit protocol"; key "unit protocol";
description description
"Total traffic."; "Total traffic per protocol.";
uses traffic-unit-protocol; uses traffic-unit-protocol;
} }
list total-traffic-port { list total-traffic-port {
key "unit port"; key "unit port";
description description
"Total traffic per port."; "Total traffic per port.";
uses traffic-unit-port; uses traffic-unit-port;
} }
list total-attack-traffic { list total-attack-traffic {
key "unit"; key "unit";
skipping to change at page 75, line 49 skipping to change at page 77, line 4
key "unit protocol"; key "unit protocol";
description description
"Total attack traffic per protocol."; "Total attack traffic per protocol.";
uses traffic-unit-protocol; uses traffic-unit-protocol;
} }
list total-attack-traffic-port { list total-attack-traffic-port {
key "unit port"; key "unit port";
description description
"Total attack traffic per port."; "Total attack traffic per port.";
uses traffic-unit-port; uses traffic-unit-port;
} }
container total-attack-connection { container total-attack-connection {
description description
"Total attack connections."; "Total attack connections.";
uses connection-protocol-percentile; uses connection-protocol-percentile;
} }
container total-attack-connection-port { container total-attack-connection-port {
description description
"Total attack connections."; "Total attack connections.";
uses connection-protocol-port-percentile; uses connection-protocol-port-percentile;
} }
list attack-detail { list attack-detail {
key "attack-id"; key "attack-id";
description description
"Attack details."; "Provides a set of attack details.";
uses attack-detail; uses attack-detail;
container top-talker { container top-talker {
description description
"Top attack sources."; "Lists the top attack sources.";
uses top-talker; uses top-talker;
} }
} }
} }
augment "/ietf-signal:dots-signal/ietf-signal:message-type/" augment "/ietf-signal:dots-signal/ietf-signal:message-type/"
+ "ietf-signal:mitigation-scope/ietf-signal:scope" { + "ietf-signal:mitigation-scope/ietf-signal:scope" {
if-feature "dots-telemetry"; if-feature "dots-telemetry";
description description
"Extends mitigation scope with telemetry update data."; "Extends mitigation scope with telemetry update data.";
skipping to change at page 92, line 34 skipping to change at page 93, line 42
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>. 2018, <https://www.rfc-editor.org/info/rfc8345>.
15.2. Informative References 15.2. Informative References
[I-D.bosh-core-new-block]
Boucadair, M. and J. Shallow, "New Constrained Application
Protocol (CoAP) Block-Wise Transfer Options", draft-bosh-
core-new-block-00 (work in progress), April 2020.
[I-D.ietf-dots-multihoming] [I-D.ietf-dots-multihoming]
Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing
Deployment Considerations for Distributed-Denial-of- Deployment Considerations for Distributed-Denial-of-
Service Open Threat Signaling (DOTS)", draft-ietf-dots- Service Open Threat Signaling (DOTS)", draft-ietf-dots-
multihoming-03 (work in progress), January 2020. multihoming-03 (work in progress), January 2020.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
L., and K. Nishizuka, "Use cases for DDoS Open Threat L., and K. Nishizuka, "Use cases for DDoS Open Threat
Signaling", draft-ietf-dots-use-cases-20 (work in Signaling", draft-ietf-dots-use-cases-20 (work in
 End of changes. 80 change blocks. 
354 lines changed or deleted 387 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/