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.
This document 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 vicious
and sophisticated in almost all aspects of their maneuvers and
malevolent intentions. IT organizations and service providers are facing
DDoS attacks that fall into two broad categories: Network/Transport
layer attacks and Application layer attacks: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 user traffic. The main method of such attacks is to send a large
volume or high PPS of traffic toward the victim's infrastructure.
Typically, attack volumes may vary from a few 100 Mbps/PPS 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
Protoco).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 valid 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/ 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 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.In some deployments, 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 the DOTS client can
convey to the DOTS server, 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 the DOTS client to signal to the DOTS server any knowledge regarding
ongoing attacks. This can happen in cases where DOTS clients are asking
the DOTS server 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 by the DOTS client
domain, the DOTS server, and its associated mitigation services, can
proactively benefit this information and optimize the overall service
delivered. It is important to note that DOTS client and server 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 from the client as hints and
cannot completely rely or trust the attack details conveyed by the DOTS
client.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 the
DOTS server to share DOTS telemetry with the DOTS client.Thus mutual sharing of information is crucial for "closing the
mitigation loop" between the DOTS client and server. 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 the 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 client and server can be
high-lighted, and maybe handled, using the DOTS telemetry
attributes.In addition, management and orchestration systems, at both DOTS
client and server sides, can potentially use DOTS telemetry as a
feedback to automate various control and management activities derived
from ongoing information signaled.If the DOTS server's mitigation resources have the capabilities to
facilitate the DOTS telemetry, the DOTS server adopts its protection
strategy and activates the required countermeasures immediately
(automation enabled). The overall results of this adoption are optimized
attack mitigation decisions and actions.The DOTS telemetry can also be used to tune the DDoS mitigators with
the correct state of the 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. In anomaly detection, the main idea is 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 peace 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. This complexity
originates from the fact that the packet itself 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 this attribute 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. Consequently, the overall mitigation performances obtained are
dramatically improved in terms of time to mitigate, accuracy,
false-negative, false-positive, and other measures.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 client behavior. Consequently,
common global thresholds for attack detection practically cannot be
realized. Each DOTS client 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 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. The DOTS client asks the DOTS server 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 client. In this case, it can be valuable to clients
to signal to server the "Total pipe capacity", which is the level of
traffic the DOTS client domain can absorb from the upstream network.
Dynamic updates of the condition of pipes between DOTS agents while they
are under a DDoS attack is essential. For example, 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 client's pipes to be
saturated unintentionally. The rate-limit action defined in is a reasonable candidate to
achieve this objective; the client can ask for the type 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 DOTS telemetry to
all elements involved in the mitigation process is essential and
absolutely improves the overall service effectiveness.
Bi-directional feedback between DOTS agents is required for the
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').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.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 .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 .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
pre-mitigation telemetry information to DOTS clients () 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'.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.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(s) to be used for
traffic-related telemetry data. Typically, the supported units are:
packets per second (PPS) or kilo packets per second (Kpps) and Bits
per Second (BPS), and kilobytes per second or megabytes per second
or gigabytes per second.DOTS clients that are interested to receive pre-mitigation
telemetry 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-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" .This limit can be expressed in packets per second (PPS) or kilo
packets per second (Kpps) and Bits per Second (BPS), and in kilobytes
per second or megabytes per second or gigabytes per second. 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 total connections capacity:The percentile values
representing the total traffic normal baseline. The traffic normal baseline is represented for a
target and is transport-protocol specific.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 and 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.The maximum number of partial requests allowed per second
to the target per client.The threshold is
transport-protocol.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 .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-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-mitigation telemetry attributes specified in can be signaled between DOTS agents.Pre-mitigation telemetry attributes may be sent by a DOTS client or a
DOTS server.DOTS agents MUST bind pre-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 .DOTS agents MUST NOT sent pre-mitigation telemetry messages to the
same peer more frequently than once every 'telemetry-notify-interval'
().DOTS pre-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-lis' MUST be present in the
attack details.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.This attribute () conveys the
percentile values of total traffic observed during a DDoS
attack.The total traffic is represented for a target and is
transport-protocol specific.This attribute () conveys the total
attack traffic identified by the DOTS client domain's DMS (or DDoS
Detector).The total attack traffic is represented for a target and is
transport-protocol specific.If the target is subjected to resource consuming DDoS attack,
this 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.This attribute () is used to signal a
set of details characterizing an attack. The following optional
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 by the
vendor 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' defined in .'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-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-mitigation telemetry 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 pre-mitigation telemetry). This is a mandatory attribute.At least 'target' attribute and another pre-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-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-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.The pre-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-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-mitigation requests per DOTS client
domain.DOTS clients of the same domain can request to receive
pre-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-mitigation
telemetry data from the DOTS server. The GET request specify a 'tmid'
() or not ().The DOTS server will send asynchronous notifications to the DOTS
client when an event if following similar considerations as in Section
4.4.2.1 of . An
example of a pre-mitugation telemetry notification is shown in .A DOTS server may aggregate pre-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-mitigation telemetry data with an alert
to an administrator or a network controller. The DOTS client may send
a mitigation request if the attack cannot be handled locally.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.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:Some of these attributes should be prepended with
"ietf-dots-telemetry:"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.Authors would like to thank Kaname Nishizuka, Jon Shallow, Wei Pan
and Yuuhei Hayashi for comments and review.Private Enterprise Numbers