Distributed Denial-of-Service Open Threat
Signaling (DOTS) TelemetryOrangeRennes35000Francemohamed.boucadair@orange.comMcAfee, Inc.Embassy Golf Link Business ParkBangaloreKarnataka560071Indiakondtir@gmail.comRadware Ltd.Raoul Wallenberg StreetTel-Aviv69710Israelehudd@radware.comCMCC32, Xuanwumen WestBeiJingBeiJing100053Chinachenmeiling@chinamobile.comDOTSThis document aims to enrich DOTS signal channel protocol with
various telemetry attributes allowing optimal DDoS attack mitigation. It
specifies the normal traffic baseline and attack traffic telemetry
attributes a DOTS client can convey to its DOTS server in the mitigation
request, the mitigation status telemetry attributes a DOTS server can
communicate to a DOTS client, and the mitigation efficacy telemetry
attributes a DOTS client can communicate to a DOTS server. The telemetry
attributes can assist the mitigator to choose the DDoS mitigation
techniques and perform optimal DDoS attack mitigation.Distributed Denial of Service (DDoS) attacks have become more
sophisticated. IT organizations and service providers are facing DDoS
attacks that fall into two broad categories:Network/Transport layer attacks target the victim's
infrastructure. These attacks are not necessarily aimed at taking
down the actual delivered services, but rather to eliminate various
network elements (routers, switches, firewalls, transit links, and
so on) from serving legitimate users traffic. The main method of such attacks is to send a large
volume or high packet per second (pps) of traffic toward the
victim's infrastructure. Typically, attack volumes may vary from a
few 100 Mbps to 100s of Gbps or even Tbps. Attacks are commonly
carried out leveraging botnets and attack reflectors for
amplification attacks such as NTP (Network Time Protocol), DNS
(Domain Name System), SNMP (Simple Network Management Protocol), or
SSDP (Simple Service Discovery Protocol).Application layer attacks target various applications. Typical
examples include attacks against HTTP/HTTPS, DNS, SIP (Session
Initiation Protocol), or SMTP (Simple Mail Transfer Protocol).
However, all applications with their port numbers open at network
edges can be attractive attack targets. Application layer attacks are considered more
complex and hard to categorize, therefore harder to detect and
mitigate efficiently.To compound the problem, attackers also leverage multi-vectored
attacks. These attacks are assembled from dynamic attack vectors
(Network/Application) and tactics. As such, multiple attack vectors
formed by multiple attack types and volumes are launched simultaneously
towards a victim. Multi-vector attacks are harder to detect and defend.
Multiple and simultaneous mitigation techniques are needed to defeat
such attack campaigns. It is also common for attackers to change attack
vectors right after a successful mitigation, burdening their opponents
with changing their defense methods.The ultimate conclusion derived from these real scenarios is that
modern attacks detection and mitigation are most certainly complicated
and highly convoluted tasks. They demand a comprehensive knowledge of
the attack attributes, the targeted normal behavior (including, normal
traffic patterns), as well as the attacker's on-going and past actions.
Even more challenging, retrieving all the analytics needed for detecting
these attacks is not simple to obtain with the industry's current
capabilities.The DOTS signal channel protocol is used to carry
information about a network resource or a network (or a part thereof)
that is under a DDoS attack. Such information is sent by a DOTS client
to one or multiple DOTS servers so that appropriate mitigation actions
are undertaken on traffic deemed suspicious. Various use cases are
discussed in .Typically, DOTS clients can be integrated within a DDoS attack
detector, or network and security elements that have been actively
engaged with ongoing attacks. The DOTS client mitigation environment
determines that it is no longer possible or practical for it to handle
these attacks. This can be due to a lack of resources or security
capabilities, as derived from the complexities and the intensity of
these attacks. In this circumstance, the DOTS client has invaluable
knowledge about the actual attacks that need to be handled by its DOTS
server(s). By enabling the DOTS client to share this comprehensive
knowledge of an ongoing attack under specific circumstances, the DOTS
server can drastically increase its ability to accomplish successful
mitigation. While the attack is being handled by the DOTS server
associated mitigation resources, the DOTS server has the knowledge about
the ongoing attack mitigation. The DOTS server can share this
information with the DOTS client so that the client can better assess
and evaluate the actual mitigation realized.DOTS clients can send mitigation hints derived from attack details to
DOTS servers, with the full understanding that the DOTS server may
ignore mitigation hints, as described in
(Gen-004). Mitigation hints will be transmitted across the DOTS signal
channel, as the data channel may not be functional during an attack. How
a DOTS server is handling normal and attack traffic attributes, and
mitigation hints is implementation-specific.Both DOTS client and server can benefit this information by
presenting various information in relevant management, reporting, and
portal systems.This document defines DOTS telemetry attributes that can be conveyed
by DOTS clients to DOTS servers, and vice versa. The DOTS telemetry
attributes are not mandatory fields. Nevertheless, when DOTS telemetry
attributes are available to a DOTS agent, and absent any policy, it can
signal the attributes in order to optimize the overall mitigation
service provisioned using DOTS. Some of the DOTS telemetry data is not
shared during an attack time.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
when, and
only when, they appear in all capitals, as shown here.The reader should be familiar with the terms defined in ."DOTS Telemetry" is defined as the collection of attributes that are
used to characterize normal traffic baseline, attacks and their
mitigation measures, and any related information that may help in
enforcing countermeasures. The DOTS Telemetry is an optional set of
attributes that can be signaled in the DOTS signal channel protocol.The meaning of the symbols in YANG tree diagrams is defined in .When signaling a mitigation request, it is most certainly beneficial
for DOTS clients to signal to DOTS servers any knowledge regarding
ongoing attacks. This can happen in cases where DOTS clients are asking
DOTS servers for support in defending against attacks that they have
already detected and/or mitigated. These actions taken by DOTS clients
are referred to as "signaling the DOTS Telemetry".If attacks are already detected and categorized within a DOTS client
domain, the DOTS server, and its associated mitigation services, can
proactively benefit this information and optimize the overall service
delivery. It is important to note that DOTS clients and servers
detection and mitigation approaches can be different, and can
potentially outcome different results and attack classifications. The
DDoS mitigation service treats the ongoing attack details received from
DOTS clients as hints and cannot completely rely or trust the attack
details conveyed by DOTS clients.A basic requirement of security operation teams is to be aware and
get visibility into the attacks they need to handle. The DOTS server
security operation teams benefit from the DOTS telemetry, especially
from the reports of ongoing attacks. Even if some mitigation can be
automated, operational teams can use the DOTS telemetry to be prepared
for attack mitigation and to assign the correct resources (operation
staff, networking and mitigation) for the specific service. Similarly,
security operation personnel at the DOTS client side ask for feedback
about their requests for protection. Therefore, it is valuable for DOTS
servers to share DOTS telemetry with DOTS clients.Mutual sharing of information is thus crucial for "closing the
mitigation loop" between DOTS clients and servers. For the server side
team, it is important to realize that the same attacks that the DOTS
server's mitigation resources are seeing are those that a DOTS client is
asking to mitigate. For the DOTS client side team, it is important to
realize that the DOTS clients receive the required service. For example,
understanding that "I asked for mitigation of two attacks and my DOTS
server detects and mitigates only one...". Cases of inconsistency in
attack classification between DOTS clients and servers can be
highlighted, and maybe handled, using the DOTS telemetry attributes.In addition, management and orchestration systems, at both DOTS
client and server sides, can use DOTS telemetry as a feedback to
automate various control and management activities derived from signaled
telemetry information .If the DOTS server's mitigation resources have the capabilities to
facilitate the DOTS telemetry, the DOTS server adapts its protection
strategy and activates the required countermeasures immediately
(automation enabled) for the sake of optimized attack mitigation
decisions and actions.DOTS telemetry can also be used to tune the DDoS mitigators with the
correct state of an attack. During the last few years, DDoS attack
detection technologies have evolved from threshold-based detection (that
is, cases when all or specific parts of traffic cross a pre-defined
threshold for a certain period of time is considered as an attack) to an
"anomaly detection" approach. For the latter, it is required to maintain
rigorous learning of "normal" behavior and where an "anomaly" (or an
attack) is identified and categorized based on the knowledge about the
normal behavior and a deviation from this normal behavior. Machine
learning approaches are used such that the actual traffic thresholds are
automatically calculated by learning the protected entity normal traffic
behavior during idle time. The normal traffic characterization learned
is referred to as the "normal traffic baseline". An attack is detected
when the victim's actual traffic is deviating from this normal
baseline.In addition, subsequent activities toward mitigating an attack are
much more challenging. The ability to distinguish legitimate traffic
from attacker traffic on a per packet basis is complex. For example, a
packet may look "legitimate" and no attack signature can be identified.
The anomaly can be identified only after detailed statistical analysis.
DDoS attack mitigators use the normal baseline during the mitigation of
an attack to identify and categorize the expected appearance of a
specific traffic pattern. Particularly, the mitigators use the normal
baseline to recognize the "level of normality" needs to be achieved
during the various mitigation process.Normal baseline calculation is performed based on continuous learning
of the normal behavior of the protected entities. The minimum learning
period varies from hours to days and even weeks, depending on the
protected application behavior. The baseline cannot be learned during
active attacks because attack conditions do not characterize the
protected entities' normal behavior.If the DOTS client has calculated the normal baseline of its
protected entities, signaling such information to the DOTS server along
with the attack traffic levels is significantly valuable. The DOTS
server benefits from this telemetry by tuning its mitigation resources
with the DOTS client's normal baseline. The DOTS server mitigators use
the baseline to familiarize themselves with the attack victim's normal
behavior and target the baseline as the level of normality they need to
achieve. Fed with this inforamtion, the overall mitigation performances
is expected to be improved in terms of time to mitigate, accuracy,
false-negative, and false-positive. Mitigation of attacks without having certain knowledge of normal
traffic can be inaccurate at best. This is especially true for recursive
signaling (see Section 3.2.3 in ). In addition, the highly
diverse types of use-cases where DOTS clients are integrated also
emphasize the need for knowledge of each DOTS client domain behavior.
Consequently, common global thresholds for attack detection practically
cannot be realized. Each DOTS client domain can have its own levels of
traffic and normal behavior. Without facilitating normal baseline
signaling, it may be very difficult for DOTS servers in some cases to
detect and mitigate the attacks accurately: It is important to emphasize that it is practically impossible
for the DOTS server's mitigators to calculate the normal baseline in
cases where they do not have any knowledge of the traffic
beforehand.In addition, baseline learning requires a period of time that
cannot be afforded during active attack.Of course, this information can provided using out-of-band
mechanisms or manual configuration at the risk to maintain
inaccurate information as the network evolves and "normal" patterns
change. The use of a dynamic and collaborative means between the
DOTS client and server to identify and share key parameters for the
sake of efficient DDoS protection is valuable.During a high volume attack, DOTS client pipes can be totally
saturated. DOTS clients ask their DOTS servers to handle the attack
upstream so that DOTS client pipes return to a reasonable load level
(normal pattern, ideally). At this point, it is essential to ensure that
the mitigator does not overwhelm the DOTS client pipes by sending back
"clean traffic", or what it believes is "clean". This can happen when
the mitigator has not managed to detect and mitigate all the attacks
launched towards the DOTS client domain. In this case, it can be
valuable to DOTS clients to signal to DOTS servers the "total pipe
capacity", which is the level of traffic the DOTS client domain can
absorb from its upstream network. Dynamic updates of the condition of
pipes between DOTS agents while they are under a DDoS attack is
essential (e.g., where multiple DOTS clients share the same physical
connectivity pipes). It is important to note that the term "pipe" noted
here does not necessary represent physical pipe, but rather represents
the maximum level of traffic that the DOTS client domain can receive.
The DOTS server should activate other mechanisms to ensure it does not
allow the DOTS client domain's pipes to be saturated unintentionally.
The rate-limit action defined in is a reasonable candidate to
achieve this objective; the DOTS client can ask for the type(s) of
traffic (such as ICMP, UDP, TCP port number 80) it prefers to limit. The
rate-limit action can be controlled via the signal-channel even when the pipe
is overwhelmed.To summarize: Timely and effective signaling of up-to-date DDoS telemetry to
all elements involved in the mitigation process is essential and
absolutely improves the overall DDoS mitigation service
effectiveness. Bi-directional feedback between DOTS agents is
required for an increased awareness of each party, supporting
superior and highly efficient attack mitigation service.Following the rules in , a unique identifier is
generated by a DOTS client to prevent request collisions ('cuid').As a reminder,
forbids 'cuid' to be returned in a response message body.DOTS gateways may be located between DOTS clients and servers. The
considerations elaborated in must be followed. In
particular, 'cdid' attribute is used to unambiguously identify a DOTS
client domain.As a reminder,
forbids 'cdid' (if present) to be returned in a response message
body.Uri-Path parameters and attributes with empty values MUST NOT be
present in a request and render an entire message invalid.The DOTS server follows the same considerations discussed in
Section of 4.5.3 of for managing DOTS
telemetry configuration freshness and notification. Likewise, a DOTS
client may control the selection of configuration and
non-configuration data nodes when sending a GET request by means of
the 'c' Uri-Query option and following the procedure specified in
Section of 4.4.2 of . These considerations
are not re-iterated in the following sections.DOTS clients can use Block-wise transfer with the recommendation detailed in Section
4.4.2 of to
control the size of a response when the data to be returned does not
fit within a single datagram.DOTS clients can also use Block1 Option in a PUT request (see
Section 2.5 of ) to initiate large
transfers, but these 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 transfer, or to separate out the PUT into several
discrete PUTs where each of them fits into a single packet.Multi-homed DOTS clients are assumed to follow the recommendations
in to select which
DOTS server to contact and which IP prefixes to include in a telemetry
message to a given peer DOTS server. For example, if each upstream
network exposes a DOTS server and the DOTS client maintains DOTS
channels with all of them, only the information related to prefixes
assigned by an upstream network to the DOTS client domain will be
signaled via the DOTS channel established with the DOTS server of that
upstream network. Considerations related to whether (and how) a DOTS
client gleans some telemetry information (e.g., attack details) it
receives from a first DOTS server and share it with a second DOTS
server are implementation- and deployment-specific.Messages exchanged between DOTS agents are serialized using Concise
Binary Object Representation (CBOR). CBOR-encoded payloads are used to
carry signal channel-specific payload messages which convey request
parameters and response information such as errors .This document specifies a YANG module for representing DOTS
telemetry message types (). All
parameters in the payload of the DOTS signal channel are mapped to
CBOR types as specified in .This YANG module is not intended to be used via NETCONF/ RESTCONF
for DOTS server management purposes; such module is out of the scope
of this document. It serves only to provide a data model and encoding,
but not a management data model.DOTS servers are allowed to update the non-configurable 'ro'
entities in the responses.The DOTS telemetry module () uses
"enumerations" rather than "identities" to define units, samples, and
intervals because otherwise the namespace identifier
"ietf-dots-telemetry" must be included when a telemetry attribute is
included (e.g., in a mitigation efficacy update). The use of
"identities" is thus suboptimal from a message compactness
standpoint.Examples are provided for illustration purposes. The document does
not aim to provide a comprehensive list of message examples.The authoritative reference for validating telemetry messages is
the YANG module () and the mapping table
established in .As discussed in ,
each DOTS operation is indicated by a path-suffix that indicates the
intended operation. The operation path is appended to the path-prefix to
form the URI used with a CoAP request to perform the desired DOTS
operation. The following telemetry path-suffixes are defined ():OperationOperation PathDetailsTelemetry Setup/tm-setupTelemetry/tmConsequently, the "ietf-dots-telemetry" YANG module defined in this
document () augments the "ietf-dots-signal"
with two new message types called "telemetry-setup" and "telemetry". The
tree structure is shown in (more details
are provided in the following sections about the exact structure of
"telemetry-setup" and "telemetry" message types).In reference to , a DOTS telemetry
setup message MUST include only telemetry-related configuration
parameters () or information about DOTS
client domain pipe capacity () or telemetry
traffic baseline (). As such, requests that
include a mix of telemetry configuration, pipe capacity, or traffic
baseline MUST be rejected by DOTS servers with a 4.00 (Bad Request).A DOTS client can reset all installed DOTS telemetry setup
configuration data following the considerations detailed in .A DOTS server may detect conflicts when processing requests related
to DOTS client domain pipe capacity or telemetry traffic baseline with
requests from other DOTS clients of the same DOTS client domain. More
details are included in .Telemetry setup configuration is bound to a DOTS client domain. DOTS
serves MUST NOT expect DOTS clients to send regular requests to refresh
the telemetry setup configuration. Any available telemetry setup
configuration has a validity timeout of the DOTS session with a DOTS
client domain. DOTS clients update their telemetry setup configuration
upon change of a parameter that may impact attack mitigation. DOTS telemetry setup configuration request and response messages are
marked as Confirmable messages.A DOTS client can negotiate with its server(s) a set of telemetry
configuration parameters to be used for telemetry. Such parameters
include:Percentile-related measurement parametersMeasurement unitsAcceptable percentile valuesTelemetry notification intervalAcceptable Server-originated telemetrySection 11.3 of includes more
details about computing percentiles.A GET request is used to obtain acceptable and current telemetry
configuration parameters on the DOTS server. This request may
include a 'cdid' Path-URI when the request is relayed by a DOTS
gateway. An example of such request is depicted in .Upon receipt of such request, the DOTS server replies with a 2.05
(Content) response that conveys the current and telemetry parameters
acceptable by the DOTS server. The tree structure of the response
message body is provided in .
Note that the response also includes any pipe () and baseline information () maintained by the DOTS server for this DOTS
client.DOTS servers that support the capability of sending telemetry
information to DOTS clients prior or during a mitigation () sets 'server-originated-telemetry' under
'max-config-values' to 'true' ('false' is used otherwise). If
'server-originated-telemetry' is not present in a response, this is
equivalent to receiving a request with
'server-originated-telemetry'' set to 'false'.When both 'min-config-values' and 'max-config-values' attributes
are present, the values carried in 'max-config-values' attributes
MUST be greater or equal to their counterpart in 'min-config-values'
attributes.PUT request is used to convey the configuration parameters for
the telemetry data (e.g., low, mid, or high percentile values). For
example, a DOTS client may contact its DOTS server to change the
default percentile values used as baseline for telemetry data. lists the attributes that can be
set by a DOTS client in such PUT request. An example of a DOTS
client that modifies all percentile reference values is shown in
.'cuid' is a mandatory Uri-Path parameter for PUT requests.The following additional Uri-Path parameter is defined: Telemetry Setup Identifier is an identifier
for the DOTS telemetry setup configuration data represented as
an integer. This identifier MUST be generated by DOTS clients.
'tsid' values MUST increase monotonically (when a new PUT is
generated by a DOTS client to convey new configuration
parameters for the telemetry). This is
a mandatory attribute.'cuid' and 'tsid' MUST NOT appear in the PUT request message
body.At least one configurable attribute MUST be present in the PUT
request.The PUT request with a higher numeric 'tsid' value overrides the
DOTS telemetry configuration data installed by a PUT request with a
lower numeric 'tsid' value. To avoid maintaining a long list of
'tsid' requests for requests carrying telemetry configuration data
from a DOTS client, the lower numeric 'tsid' MUST be automatically
deleted and no longer be available at the DOTS server.The DOTS server indicates the result of processing the PUT
request using the following response codes:If the request is missing a mandatory attribute, does not
include 'cuid' or 'tsid' Uri-Path parameters, or contains one or
more invalid or unknown parameters, 4.00 (Bad Request) MUST be
returned in the response.If the DOTS server does not find the 'tsid' parameter value
conveyed in the PUT request in its configuration data and if the
DOTS server has accepted the configuration parameters, then a
response code 2.01 (Created) MUST be returned in the
response.If the DOTS server finds the 'tsid' parameter value conveyed
in the PUT request in its configuration data and if the DOTS
server has accepted the updated configuration parameters, 2.04
(Changed) MUST be returned in the response.If any of the enclosed configurable attribute values are not
acceptable to the DOTS server (), 4.22
(Unprocessable Entity) MUST be returned in the response. The DOTS client may re-try and send the PUT
request with updated attribute values acceptable to the DOTS
server.By default, low percentile (10th percentile), mid percentile
(50th percentile), high percentile (90th percentile), and peak
(100th percentile) values are used to represent telemetry data.
Nevertheless, a DOTS client can disable some percentile types (low,
mid, high). In particular, setting 'low-percentile' to '0.00'
indicates that the DOTS client is not interested in receiving
low-percentiles. Likewise, setting 'mid-percentile' (or
'high-percentile') to the same value as 'low-percentile' (or
'mid-percentile') indicates that the DOTS client is not interested
in receiving mid-percentiles (or high-percentiles). For example, a
DOTS client can send the request depicted in to inform the server that it is interested in
receiving only high-percentiles. This assumes that the client will
only use that percentile type when sharing telemetry data with the
server.DOTS clients can also configure the unit type(s) to be used for
traffic-related telemetry data. Typically, the supported unit types
are: packets per second, bits per second, and bytes per second.DOTS clients that are interested to receive pre- or onoing
mitigation telemetry (pre-or-ongoing-mitigation) information from a
DOTS server () MUST set
'server-originated-telemetry' to 'true'. If
'server-originated-telemetry' is not present in a PUT request, this
is equivalent to receiving a request with
'server-originated-telemetry'' set to 'false'. An example of a
request to enable pre-or-ongoing-mitigation telemetry from DOTS
servers is shown in .A DOTS client may issue a GET message with 'tsid' Uri-Path
parameter to retrieve the current DOTS telemetry configuration. An
example of such request is depicted in .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 client, it MUST respond with a 4.04 (Not Found)
error response code.A DELETE request is used to delete the installed DOTS telemetry
configuration data (). 'cuid' and
'tsid' are mandatory Uri-Path parameters for such DELETE
requests.The DOTS server resets the DOTS telemetry configuration back to
the default values and acknowledges a DOTS client's request to
remove the DOTS telemetry configuration using 2.02 (Deleted)
response code. A 2.02 (Deleted) Response Code is returned even if
the 'tsid' parameter value conveyed in the DELETE request does not
exist in its configuration data before the request. discusses the procedure to reset
all DOTS telemetry setup configuration.A DOTS client can communicate to its server(s) its DOTS client
domain pipe information. The tree structure of the pipe information is
shown in .A DOTS client domain pipe is defined as a list of limits of
(incoming) traffic volume (total-pipe-capacity") that can be forwarded
over ingress interconnection links of a DOTS client domain. Each of
these links is identified with a "link-id" .The unit used by a DOTS client when conveying pipe information is
captured in 'unit' attribute.Similar considerations to those specified in are followed with one exception:The relative order of two PUT requests carrying DOTS client
domain pipe attributes from a DOTS client is determined by
comparing their respective 'tsid' values. If such two requests
have overlapping "link-id" and "unit", the PUT request with
higher numeric 'tsid' value will override the request with a
lower numeric 'tsid' value. The overlapped lower numeric 'tsid'
MUST be automatically deleted and no longer be available.DOTS clients SHOULD minimize the number of active 'tsids' used
for pipe information. Typically, in order to avoid maintaining a
long list of 'tsids' for pipe information, it is RECOMMENDED that
DOTS clients include in any request to update information related to
a given link the information of other links (already communicated
using a lower 'tsid' value). Doing so, this update request will
override these existing requests and hence optimize the number of
'tsid' request per DOTS client. Note: This assumes that all link information can fit in one
single message.For example, a DOTS client managing a single homed domain () can send a PUT request (shown in ) to communicate the capacity of "link1" used
to connect to its ISP.DOTS clients may be instructed to signal a link aggregate instead
of individual links. For example, a DOTS client managing a DOTS
client domain having two interconnection links with an upstream ISP
() can send a PUT request (shown in
) to communicate the aggregate link
capacity with its ISP. Signalling individual or aggregate link
capacity is deployment-specific.Now consider that the DOTS client domain was upgraded to connect
to an additional ISP (ISP#B of ), the
DOTS client can inform a 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 . This
request also includes information related to "link1" even if that
link is not upgraded. Upon receipt of this request, the DOTS server
removes the request with 'tsid=457' and updates its configuration
base to maintain two links (link#1 and link#2).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
the same DOTS client domain (see for
other delete 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 this update (e.g., from the network configuration in
to the one shown in ) by sending the PUT request depicted in
. Upon receipt of this request, the DOTS
server removes "link1" from its configuration bases for this DOTS
client domain.A GET request with 'tsid' Uri-Path parameter is used to retrieve
a specific installed DOTS client domain pipe related information.
The same procedure as defined in () is
followed.To retrieve all pipe information bound to a DOTS client, the DOTS
client proceeds as specified in .A DELETE request is used to delete the installed DOTS client
domain pipe related information. The same procedure as defined in
() is followed.A DOTS client can communicate to its server(s) its normal traffic
baseline and connections capacity:The percentile values
representing the total traffic normal baseline. It can be
represented for a target using 'total-traffic-normal'.The traffic normal per protocol
('total-traffic-normal-per-protocol') baseline is represented for
a target and is transport-protocol specific.The traffic normal per port number
('total-traffic-normal-per-port') baseline is represented for each
port number bound to a target.If the DOTS
client negotiated percentile values and units (), these negotiated values will be used
instead of the default ones.If the target is
subjected to resource consuming DDoS attacks, the following
optional attributes for the target per transport-protocol are
useful to detect resource consuming DDoS attacks:The maximum number of simultaneous connections that are
allowed to the target.The maximum number of simultaneous connections that are
allowed to the target per client.The maximum number of simultaneous embryonic connections
that are allowed to the target. The term "embryonic
connection" refers to a connection whose connection handshake
is not finished. Embryonic connection is only possible in
connection-oriented transport protocols like TCP or SCTP.The maximum number of simultaneous embryonic connections
that are allowed to the target per client.The maximum number of connections allowed per second to the
target.The maximum number of connections allowed per second to the
target per client.The maximum number of requests allowed per second to the
target.The maximum number of requests allowed per second to the
target per client.The maximum number of partial requests allowed per second
to the target. Attacks relying upon partial requests create a
connection with a target but do not send a complete request
(e.g., HTTP request). The maximum number of partial requests allowed per second
to the target per client.The aggregate per transport
protocol is captured in 'total-connection-capacity', while
port-specific capabilities are represented using
'total-connection-capacity-per-port'.The tree structure of the baseline is shown in .Similar considerations to those specified in are followed with one exception:The relative order of two PUT requests carrying DOTS client
domain baseline attributes from a DOTS client is determined by
comparing their respective 'tsid' values. If such two requests
have overlapping targets, the PUT request with higher numeric
'tsid' value will override the request with a lower numeric
'tsid' value. The overlapped lower numeric 'tsid' MUST be
automatically deleted and no longer be available.Two PUT requests from a DOTS client have overlapping targets if
there is a common IP address, IP prefix, FQDN, or URI.DOTS clients SHOULD minimize the number of active 'tsids' used
for baseline information. Typically, in order to avoid maintaining a
long list of 'tsids' for baseline information, it is RECOMMENDED
that DOTS clients include in a request to update information related
to a given target, the information of other targets (already
communicated using a lower 'tsid' value) (assuming this fits within
one single datagram). This update request will override these
existing requests and hence optimize the number of 'tsid' request
per DOTS client.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 whole.An example of a PUT request to convey the baseline information is
shown in .The DOTS client may share protocol-specific baseline information
(e.g., TCP and UDP) as shown in .The traffic baseline information should be updated to reflect
legitimate overloads (e.g., flash crowds) to prevent unnecessary
mitigation.A GET request with 'tsid' Uri-Path parameter is used to retrieve
a specific installed DOTS client domain baseline traffic
information. The same procedure as defined in () is followed.To retrieve all baseline information bound to a DOTS client, the
DOTS client proceeds as specified in .A DELETE request is used to delete the installed DOTS client
domain normal traffic baseline. The same procedure as defined in
() is followed.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 the
telemetry parameters to default values. Such a request does not
include any 'tsid'. An example of such request is depicted in .A DOTS server may detect conflicts between requests to convey pipe
and baseline information received from DOTS clients of the same DOTS
client domain. 'conflict-information' is used to report the conflict
to the DOTS client following similar conflict handling discussed in
Section 4.4.1 of .
The conflict cause can be set to one of these values:1: Overlapping targets (already defined in ).TBA: Overlapping pipe scope (see ).There are two broad types of DDoS attacks, one is bandwidth consuming
attack, the other is target resource consuming attack. This section
outlines the set of DOTS telemetry attributes () that covers both the types of attacks. The
ultimate objective of these attributes is to allow for the complete
knowledge of attacks and the various particulars that can best
characterize attacks.The "ietf-dots-telemetry" YANG module ()
augments the "ietf-dots-signal" with a new message type called
"telemetry". The tree structure of the "telemetry" message type is shown
.The pre-or-ongoing-mitigation telemetry attributes are indicated by
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.
Pre-or-ongoing-mitigation telemetry attributes specified in can be signaled between DOTS agents.Pre-or-ongoing-mitigation telemetry attributes may be sent by a DOTS
client or a DOTS server.DOTS agents SHOULD bind pre-or-ongoing-mitigation telemetry data with
mitigation requests relying upon the target clause. In particular, a
telemetry PUT request sent after a mitigation request may include a
reference to that mitigation request ('mid-list') as shown in . An example illustrating requests correlation by
means of 'target-prefix' is shown in .When generating telemetry data to send to a peer, the DOTS agent must
auto-scale so that appropriate unit(s) are used.DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry
messages to the same peer more frequently than once every
'telemetry-notify-interval' ().DOTS pre-or-ongoing-mitigation telemetry request and response
messages MUST be marked as Non-Confirmable messages.The description and motivation behind each attribute are presented
in . DOTS telemetry attributes are
optionally signaled and therefore MUST NOT be treated as mandatory
fields in the DOTS signal channel protocol.A target resource () is identified
using the attributes 'target-prefix', 'target-port-range',
'target-protocol', 'target-fqdn', 'target-uri', or 'alias-name'
defined in the base DOTS signal channel protocol.At least one of the attributes 'target-prefix', 'target-fqdn',
'target-uri', 'alias-name', or 'mid-list' MUST be present in the
target definition.If the target is subjected to bandwidth consuming attack, the
attributes representing the percentile values of the 'attack-id'
attack traffic are included.If the target is subjected to resource consuming DDoS attacks,
the same attributes defined for
are applicable for representing the attack.This is an optional sub-attribute.The 'total-traffic' attribute ()
conveys the percentile values of total traffic observed during a
DDoS attack. More granular total traffic can be conveyed in
'total-traffic-protocol' and 'total-traffic-port'.The 'total-traffic-protocol' represents the total traffic for a
target and is transport-protocol specific.The 'total-traffic-port' represents the total traffic for a
target per port number.The 'total-attack-traffic' attribute () conveys the total attack traffic identified
by the DOTS client domain's DMS (or DDoS Detector). More granular
total traffic can be conveyed in 'total-attack-traffic-protocol' and
'total-attack-traffic-port'.The 'total-attack-traffic-protocol' represents the total attack
traffic for a target and is transport-protocol specific.The 'total-attack-traffic-port' represents the total attack
traffic for a target per port number.If the target is subjected to resource consuming DDoS attack, the
'total-attack-connection' attribute is used to convey the percentile
values of total attack connections. The following optional
sub-attributes for the target per transport-protocol are included to
represent the attack characteristics:The number of simultaneous attack connections to the
target.The number of simultaneous embryonic connections to the
target.The number of attack connections per second to the
target.The number of attack requests to the target.The total attack connections per port number is represented
using 'total-attack-connection-port' attribute.This attribute () is used to signal a
set of details characterizing an attack. The following
sub-attributes describing the on-going attack can be signal as
attack details.Vendor ID is a security vendor's Enterprise
Number as registered with IANA . It is a four-byte integer
value.Unique identifier assigned for the
attack.Textual representation of attack
description. Natural Language Processing techniques (e.g., word
embedding) can possibly be used to map the attack description to
an attack type. Textual representation of attack solves two
problems: (a) avoids the need to create mapping tables manually
between vendors and (2) avoids the need to standardize attack
types which keep evolving.Attack severity. These values are
supported: emergency (1), critical (2), and alert (3).The time the attack started. The
attack's start time is expressed in seconds relative to
1970-01-01T00:00Z in UTC time (Section 2.4.1 of ). The CBOR encoding is modified so that
the leading tag 1 (epoch-based date/time) MUST be omitted.The time the attack-id attack ended. The
attack end time is expressed in seconds relative to
1970-01-01T00:00Z in UTC time (Section 2.4.1 of ). The CBOR encoding is modified so that
the leading tag 1 (epoch-based date/time) MUST be omitted.A count of sources involved in the
attack targeting the victim.A list of top talkers among attack
sources. The top talkers are represented using the
'source-prefix'.'spoofed-status' is
used whether a top talker is a spoofed IP address (e.g.,
reflection attacks) or not. If the
target is subjected to bandwidth consuming attack, the attack
traffic from each of the top talkers is included
('total-attack-traffic', ). If the target is subjected to resource
consuming DDoS attacks, the same attributes defined for are applicable for representing the
attack per talker.DOTS clients uses PUT request to signal pre-or-ongoing-mitigation
telemetry to DOTS servers. An example of such request is shown in
.'cuid' is a mandatory Uri-Path parameter for PUT requests.The following additional Uri-Path parameter is defined: Telemetry Identifier is an identifier for the
DOTS pre-or-ongoing-mitigation telemetry data represented as an
integer. This identifier MUST be generated by DOTS clients. 'tmid'
values MUST increase monotonically (when a new PUT is generated by
a DOTS client to convey pre-or-ongoing-mitigation telemetry).
This is a mandatory attribute.'cuid' and 'tmid' MUST NOT appear in the PUT request message
body.At least 'target' attribute and another pre-or-ongoing-mitigation
attributes () MUST be present in the PUT
request. If only the 'target' attribute is present, this request is
handled as per .The relative order of two PUT requests carrying DOTS
pre-or-ongoing-mitigation telemetry from a DOTS client is determined
by comparing their respective 'tmid' values. If such two requests have
overlapping 'target', the PUT request with higher numeric 'tmid' value
will override the request with a lower numeric 'tmid' value. The
overlapped lower numeric 'tmid' MUST be automatically deleted and no
longer be available.The DOTS server indicates the result of processing a PUT request
using CoAP response codes. The response code 2.04 (Changed) is
returned if the DOTS server has accepted the pre-or-ongoing-mitigation
telemetry. The error response code 5.03 (Service Unavailable) is
returned if the DOTS server has erred. 5.03 uses Max-Age option to
indicate the number of seconds after which to retry.How long a DOTS server maintains a 'tmid' as active or logs the
enclosed telemetry information is implementation-specific. Note that
if a 'tmid’ is still active, then logging details are updated by
the DOTS server as a function of the updates received from the peer
DOTS client.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 to the DOTS server to retrieve the list of active 'tmid'. The
DOTS client may then delete 'tmids' that should not be active anymore
(). Sending a DELETE with no 'tmid'
indicates that all 'tmids' must be deactivated ().The pre-or-ongoing-mitigation (attack details, in particular) can
also be signaled from DOTS servers to DOTS clients. For example, the
DOTS server co-located with a DDoS detector collects monitoring
information from the target network, identifies DDoS attack using
statistical analysis or deep learning techniques, and signals the
attack details to the DOTS client.The DOTS client can use the attack details to decide whether to
trigger a DOTS mitigation request or not. Furthermore, the security
operation personnel at the DOTS client domain can use the attack
details to determine the protection strategy and select the
appropriate DOTS server for mitigating the attack.In order to receive pre-or-ongoing-mitigation telemetry
notifications from a DOTS server, a DOTS client MUST send a PUT
(followed by a GET) with the target filter. An example of such PUT
request is shown in . In order to avoid
maintaining a long list of such requests, it is RECOMMENDED that DOTS
clients include all targets in the same request. DOTS servers may be
instructed to restrict the number of pre-or-ongoing-mitigation
requests per DOTS client domain. This request MUST be maintained
active by the DOTS server until a delete request is received from the
same DOTS client to clear this pre-or-ongoing-mitigation
telemetry.The relative order of two PUT requests carrying DOTS
pre-or-ongoing-mitigation telemetry from a DOTS client is determined
by comparing their respective 'tmid' values. If such two requests have
overlapping 'target', the PUT request with higher numeric 'tmid' value
will override the request with a lower numeric 'tmid' value. The
overlapped lower numeric 'tmid' MUST be automatically deleted and no
longer be available.DOTS clients of the same domain can request to receive
pre-or-ongoing-mitigation telemetry bound to the same target.The DOTS client conveys the Observe Option set to '0' in the GET
request to receive asynchronous notifications carrying
pre-or-ongoing-mitigation telemetry data from the DOTS server. The GET
request specifies a 'tmid' () or not
().The DOTS client can filter out the asynchronous notifications from
the DOTS server by indicating one or more Uri-Query options in its GET
request. A Uri-Query option can include the following parameters:
target-prefix, lower-port, upper-port, target-protocol, target-fqdn,
target-uri, alias-name. An example of request to subscribe to
asynchronous UDP telemetry notifications is shown in . This filter will be applied for all
'tmids'.The DOTS server will send asynchronous notifications to the DOTS
client when an attack event is detected following similar
considerations as in Section 4.4.2.1 of . An example of a
pre-or-ongoing-mitigation telemetry notification is shown in . A DOTS server sends the aggregate data for a target using
'total-attack-traffic' attribute. It may includes more granular data
when needed (that is, 'total-attack-traffic-protocol' and
'total-attack-traffic-port').A DOTS server may aggregate pre-or-ongoing-mitigation data (e.g.,
'top-talkers') for all targets of a domain, or when justified, send
specific information (e.g., 'top-talkers') per individual targets.The DOTS client may log pre-or-ongoing-mitigation telemetry data
with an alert sent to an administrator or a network controller. The
DOTS client may send a mitigation request if the attack cannot be
handled locally.A DOTS client that is not interested to receive
pre-or-ongoing-mitigation telemetry data for a target MUST send a
delete request similar to the one depicted in .The mitigation efficacy telemetry attributes can be signaled from
DOTS clients to DOTS servers as part of the periodic mitigation
efficacy updates to the server (Section 5.3.4 of ).The overall attack traffic as
observed from the DOTS client perspective during an active
mitigation. See .The overall attack details as
observed from the DOTS client perspective during an active
mitigation. See .The "ietf-dots-telemetry" YANG module augments the
"mitigation-scope" type message defined in "ietf-dots-signal" so that
these attributes can be signalled by a DOTS client in a mitigation
efficacy update ().In order to signal telemetry data in a mitigation efficacy update,
it is RECOMMENDED that the DOTS client has already established a DOTS
telemetry setup session with the server in 'idle' time.The mitigation status telemetry attributes can be signaled from the
DOTS server to the DOTS client as part of the periodic mitigation
status update (Section 5.3.3 of ). In particular, DOTS
clients can receive asynchronous notifications of the attack details
from DOTS servers using the Observe option defined in .In order to make use of this feature, DOTS clients MUST establish a
telemetry setup session with the DOTS server in 'idle' time and MUST
set the 'server-originated-telemetry' attribute to 'true'.DOTS servers MUST NOT include telemetry attributes in mitigation
status updates sent to DOTS clients for which
'server-originated-telemetry' attribute is set to 'false'.As defined in , the actual mitigation
activities can include several countermeasure mechanisms. The DOTS
server signals the current operational status to each relevant
countermeasure. A list of attacks detected by each countermeasure MAY
also be included. The same attributes defined for are applicable for describing the
attacks detected and mitigated.The "ietf-dots-telemetry" YANG module () augments the "mitigation-scope" type message
defined in "ietf-dots-signal" with telemetry data as depicted in
following tree structure: shows an example of an asynchronous
notification of attack mitigation status from the DOTS server. This
notification signals both the mid-percentile value of processed attack
traffic and the peak percentile value of unique sources involved in
the attack.DOTS clients can filter out the asynchronous notifications from the
DOTS server by indicating one or more Uri-Query options in its GET
request. A Uri-Query option can include the following parameters:
target-prefix, lower-port, upper-port, target-protocol, target-fqdn,
target-uri, alias-name. An example of request to subscribe to
asynchronous notifications bound to the "http1" alias is shown in
.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
(Not Found) error response code. The DOTS server MUST NOT add a new
observe entry if this query overlaps with an existing one. This module uses types defined in and
.All DOTS telemetry parameters in the payload of the DOTS signal
channel MUST be mapped to CBOR types as shown in the following
table:Implementers may use the values in:
https://github.com/boucadair/draft-dots-telemetry/blob/master/mapping-table.txtThis specification registers the DOTS telemetry attributes in the
IANA "DOTS Signal Channel CBOR Key Values" registry available at
https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel-cbor-key-values.The DOTS telemetry attributes defined in this specification are
comprehension-optional parameters.Note to the RFC Editor: (1) CBOR keys are assigned from the
32768-49151 range. (2) Please assign the following suggested
values.This specification requests IANA to assign a new code from the
"DOTS Signal Channel Conflict Cause Codes" registry available at
https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel-conflict-cause-codes.This document requests IANA to register the following URI in the
"ns" subregistry within the "IETF XML Registry" : This document requests IANA to register the following YANG
module in the "YANG Module Names" subregistry within the "YANG Parameters" registry.Security considerations in need to be taken into
consideration.The following individuals have contributed to this document:Li Su, CMCC, Email: suli@chinamobile.comJin Peng, CMCC, Email: pengjin@chinamobile.comPan Wei, Huawei, Email: william.panwei@huawei.comThe authors would like to thank Flemming Andreasen, Liang Xia, and
Kaname Nishizuka co-authors of
https://tools.ietf.org/html/draft-doron-dots-telemetry-00 draft and
everyone who had contributed to that document.The authors would like to thank Kaname Nishizuka, Jon Shallow, Wei
Pan and Yuuhei Hayashi for comments and review.Private Enterprise Numbers