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.comUnited Kingdomsupjps-ietf@jpshallow.comDOTSautomationcybersecurityDDoSResilienceIntelligenceService deliveryRobsutnessCollaborativeThis document aims to enrich DOTS signal channel protocol with
various telemetry attributes allowing optimal Distributed
Denial-of-Service 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 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 ongoing 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 .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 clients and servers 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 attributes of the DOTS signal channel
protocol . 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.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.Telemetry Setup Identifier (tsid) is an identifier that is generated
by DOTS clients to uniquely identify DOTS telemetry setup configuration
data.Telemetry Identifier (tmid) is an identifier that is generated by
DOTS clients to uniquely identify DOTS telemetry data that is
communicated prior or during a mitigation.When two telemetry requests overlap, "overlapped" lower numeric
'tsid' (or 'tmid')" refers to the lower 'tsid' (or 'tmid') value of
these overlapping requests.The meaning of the symbols in YANG tree diagrams are defined in and .Timely and effective signaling of up-to-date DDoS telemetry to all
elements involved in the mitigation process is essential and 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.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.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 client
domains and DOTS server domains 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 of them". 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
predefined 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 information, 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.This document specifies an extension to the DOTS signal channel
protocol. Considerations about how to establish, maintain, and make
use of the DOTS signal channel are specified in .Once the DOTS signal channel is established, DOTS clients that
support the DOTS telemetry extension proceed with the telemetry setup
configuration (e.g., measurement interval, telemetry notification
interface, pipe capacity, normal traffic baseline) as detailed in
. DOTS agents can then include DOTS
telemetry attributes using the DOTS signal channel (). A DOTS client can use separate messages to
share with its DOTS server(s) a set of telemetry data bound to an
ongoing mitigation (). Also, a DOTS
client that is interested to receive telemetry notifications related
to some of its resources follows the procedure defined in . The DOTS client can then decide to send a
mitigation request if the notified attack cannot be mitigated locally
within the DOTS client domain.Aggregate DOTS telemetry data can also be included in efficacy
update () or mitigation update () messages.Following the rules in Section 4.4.1 of , 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 Section 4.4.1 of 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 reiterated 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 CoAP 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.Q-Block1 and Q-Block2 Options that are similar to the CoAP Block1
and Block2 Options, but enable faster transmissions of big blocks of
data with less packet interchanges, are defined in . DOTS implementations can
consider the use of Q-Block1 and Q-Block2 Options.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.Telemetry 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 . As a reminder, Section 3 of defines the rules for
mapping YANG-modeled data to CBOR. The DOTS telemetry module () is not
intended to be used via NETCONF/RESTCONF for DOTS server management
purposes. It serves only to provide a data model and encoding
following . Server deviations are
strongly discouraged as the peer DOTS agent does not have means to
retrieve the list of deviations and that interoperability issues are
likely to be encountered. 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;
one of the key requirements for DOTS messages.The DOTS telemetry module () includes
some lists for which no key statement is included. This behavior is
compliant with . The reason for not
including these keys is because they are not included in the request
message body but as mandatory Uri-Paths in requests (Sections and ). Otherwise, whenever a key statement is used
in the module, the same definition as in Section 7.8.2 of is assumed. In order to optimize the data exchanged over the DOTS signal
channel, the document specifies a second YANG module
("ietf-dots-mapping", ) that augments the
DOTS data channel . This augmentation
can be used during idle time to share the attack mapping details
(). DOTS clients can use tools,
e.g., YANG Library , to retrieve the
list of features and deviations supported by the DOTS server. 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
exchanged over the DOTS signal channel are sections , , and together with the mapping table established in
. The structure of telemetry message bodies
is represented as a YANG data structure ().As discussed in Section 4.2 of , 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 (Table 1):Consequently, the "ietf-dots-telemetry" YANG module defined in defines data structure to represent new DOTS
message types called 'telemetry-setup' and 'telemetry'. The tree
structure is shown in . More details are
provided in Sections and
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
servers 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 association with a DOTS
client domain. DOTS servers MUST NOT reset 'tsid' because a session
failed with a DOTS client. 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 (Section 2.1 of ).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' Uri-Path when the request is relayed by a DOTS
gateway. An example of such request is depicted in .Upon receipt of such request, and assuming no error is
encountered by processing the 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). The
procedure specified in Section 4.4.1 of MUST be followed for
'tsid' rollover.This is a mandatory
attribute. 'tsid' MUST follow 'cuid'.'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
2.01 (Created) Response Code 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 retry 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 class(es) to be used for
traffic-related telemetry data among the following supported unit
classes: packets per second, bits per second, and bytes per
second.DOTS clients that are interested to receive pre or ongoing
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 the DOTS 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. The DOTS client MUST auto-scale so that
the appropriate unit is used.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. 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 that manages 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 (e.g., 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, and
assuming no error is encountered when processing the request, the
DOTS server removes "link1" from its configuration bases for this
DOTS client domain. Note that if the DOTS server receives a PUT
request with a 'capacity' attribute set to "0" for all included
links, it MUST reject the request with a 4.00 (Bad Request).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 DOTS 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 parameters will be
used instead of the default ones. For each used unit class, the
DOTS client MUST auto-scale so that the appropriate unit is
used.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 normal traffic 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, URI, or alias-name.
Also, two PUT requests from a DOTS client have overlapping targets
if the addresses associated with the FQDN, URI, or alias are
overlapping with each other or with 'target-prefix'.DOTS clients SHOULD minimize the number of active 'tsids' used
for baseline information. 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 attribute is 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 normal 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 (Section 4.4.1 of ).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
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 ()
defines the data structure of a new message type called 'telemetry'. The
tree structure of the 'telemetry' message type is shown in .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 attribute. 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
notifications to the same peer more frequently than once every
'telemetry-notify-interval' (). If a
telemetry notification is sent using a block-like transfer mechanism
(e.g., ), this rate limit
policy MUST NOT consider these individual blocks as separate
notifications, but as a single notification.DOTS pre-or-ongoing-mitigation telemetry request and response
messages MUST be marked as Non-Confirmable messages (Section 2.1 of
).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', 'alias-name', or a
pointer to a mitigation request ('mid-list').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 attribute.The 'total-traffic' attribute ()
conveys the percentile values (including peak and current observed
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 DDoS Mitigation System (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 (including peak and current observed values) of total attack
connections. The following optional subattributes 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 subattributes
describing the ongoing 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 the
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 (b) avoids the need to
standardize attack types which keep evolving.Attack severity level. This
attribute takes one of the values defined in Section 3.12.2 of
.The time the attack started. The
attack's start time is expressed in seconds relative to
1970-01-01T00:00Z in UTC time (Section 3.4.2 of ). The CBOR encoding is modified so that
the leading tag 1 (epoch-based date/time) MUST be omitted.The time the attack ended. The attack
end time is expressed in seconds relative to 1970-01-01T00:00Z
in UTC time (Section 3.4.2 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'
indicates whether a top talker is a spoofed IP address (e.g.,
reflection attacks) or not. If the
target is subjected to a bandwidth consuming attack, the attack
traffic from each of the top talkers is included
('total-attack-traffic', ). If the target is subjected to a resource
consuming DDoS attack, the same attributes defined in are applicable for representing the
attack per talker.In order to optimize the size of telemetry data conveyed over the
DOTS signal channel, DOTS agents MAY use the DOTS data channel to exchange vendor specific attack mapping
details (that is, {vendor identifier, attack identifier} ==>
attack description). As such, DOTS agents do not have to convey
systematically an attack description in their telemetry messages
over the DOTS signal channel.Multiple mappings for different vendor identifiers may be used;
the DOTS agent transmitting telemetry information can elect to use
one or more vendor mappings even in the same telemetry message.Note: It is possible that a DOTS server is making use of
multiple DOTS mitigators; each from a different vendor. How
telemetry information and vendor mappings are exchanged between
DOTS servers and DOTS mitigators is outside the scope of this
document.DOTS clients and servers may be provided with mappings from
different vendors and so have their own different sets of vendor
attack mappings. A DOTS agent MUST accept receipt of telemetry data
with a vendor identifier that is different to the one it uses to
transmit telemetry data. Furthermore, it is possible that the DOTS
client and DOTS server are provided by the same vendor, but the
vendor mapping tables are at different revisions. The DOTS client
SHOULD transmit telemetry information using the vendor mapping(s)
that it provided to the DOTS server and the DOTS server SHOULD use
the vendor mappings(s) provided to the DOTS client when transmitting
telemetry data to peer DOTS agent.The "ietf-dots-mapping" YANG module defined in augments the "ietf-dots-data-channel" . The tree structure of the
"ietf-dots-mapping" module is shown in . A DOTS client sends a GET request to retrieve the capabilities
supported by a DOTS server as per Section 7.1 of . This request is meant to assess whether
the capability of sharing vendor attack mapping details is supported
by the server (i.e., check the value of 'vendor-mapping-enabled').
If 'vendor-mapping-enabled' is set to 'true', A DOTS client MAY
send a GET request to retrieve the DOTS server's vendor attack
mapping details. An example of such GET request is shown in .A DOTS client MAY retrieve only the list of vendors supported by
the DOTS server. It does so by setting the "depth" parameter
(Section 4.8.2 of ) to "3" in the GET
request as shown in . An example of a
response body received from the DOTS server as a response to such
request is illustrated in .The DOTS client reiterates the above procedure regularly (e.g.,
once a week) to update the DOTS server's vendor attack mapping
details.If the DOTS client concludes that the DOTS server does not have
any reference to the specific vendor attack mapping details, the
DOTS client uses a POST request to install its vendor attack mapping
details. An example of such POST request is depicted in .The DOTS server indicates the result of processing the POST
request using the status-line. Concretely, "201 Created" status-line
MUST be returned in the response if the DOTS server has accepted the
vendor attack mapping details. If the request is missing a mandatory
attribute or contains an invalid or unknown parameter, "400 Bad
Request" status-line MUST be returned by the DOTS server in the
response. The error-tag is set to "missing-attribute",
"invalid-value", or "unknown-element" as a function of the
encountered error.If the request is received via a server-domain DOTS gateway, but
the DOTS server does not maintain a 'cdid' for this 'cuid' while a
'cdid' is expected to be supplied, the DOTS server MUST reply with
"403 Forbidden" status-line and the error-tag "access-denied". Upon
receipt of this message, the DOTS client MUST register (Section 5.1
of ).The DOTS client uses the PUT request to modify its vendor attack
mapping details maintained by the DOTS server (e.g., add a new
mapping).A DOTS client uses a GET request to retrieve its vendor attack
mapping details as maintained by the DOTS server ().When conveying attack details in DOTS telemetry messages
(Sections , , and ), DOTS agents MUST NOT
include 'attack-description' attribute except if the corresponding
attack mapping details were not shared with the peer DOTS agent.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).
The procedure specified in Section 4.4.1
of MUST be
followed for 'tmid' rollover.This is a
mandatory attribute. 'tmid' MUST follow 'cuid'.'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. In particular, the 2.04 (Changed) Response
Code is returned if the DOTS server has accepted the
pre-or-ongoing-mitigation telemetry. The 5.03 (Service Unavailable)
Response Code 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', 'target-port', 'target-protocol', 'target-fqdn',
'target-uri', 'alias-name', 'mid', and 'c' (content) (). Furthermore:If more than one Uri-Query option is included in a request,
these options are interpreted in the same way as when multiple
target attributes are included in a message body.If multiple values of a query parameter are to be included in a
request, these values MUST be included in the same Uri-Query
option and separated by a "," character without any spaces.Range values (i.e., contiguous inclusive block) can be included
for 'target-port', 'target-protocol', and 'mid' parameters by
indicating two bound values separated by a "-" character.Wildcard names (i.e., a name with the leftmost label is the "*"
character) can be included in 'target-fqdn' or 'target-uri'
parameters. DOTS clients MUST NOT include a name in which the "*"
character is included in a label other than the leftmost label.
"*.example.com" is an example of a valid wildcard name that can be
included as a value of the 'target-fqdn' parameter in an Uri-Query
option.DOTS clients may also filter out the asynchronous notifications
from the DOTS server by indicating a specific source information. To
that aim, a DOTS client may include 'source-prefix', 'source-port', or
'source-icmp-type' in a Uri-Query option. The same considerations
(ranges, multiple values) specified for target attributes apply for
source attributes. Special care SHOULD be taken when using these
filters as some attacks may be hidden to the requesting DOTS client
(e.g., the attack changes its source information).Requests with invalid query types (e.g., not supported, malformed)
by the DOTS server MUST be rejected by DOTS servers with a 4.00 (Bad
Request).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. The aggregate assumes that Uri-Query
filters are applied on the target. The DOTS server MAY include more
granular data when needed (that is, 'total-attack-traffic-protocol'
and 'total-attack-traffic-port'). If a port filter (or protocol
filter) is included in a request, 'total-attack-traffic-protocol' (or
'total-attack-traffic-port') conveys the data with the port (or
protocol) filter applied.A DOTS server may aggregate pre-or-ongoing-mitigation data (e.g.,
'top-talker') for all targets of a domain, or when justified, send
specific information (e.g., 'top-talker') 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 4.4.3 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' message type
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.An example of an efficacy update with telemetry attributes is
depicted in .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 4.4.2.2 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 of relevant
countermeasures. A list of attacks detected by each countermeasure MAY
also be included. The same attributes defined in are applicable for describing the
attacks detected and mitigated at the DOTS server domain.The "ietf-dots-telemetry" YANG module () augments the 'mitigation-scope' message type
defined in "ietf-dots-signal" with telemetry data as
depicted in the 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', 'target-port', 'target-protocol', 'target-fqdn',
'target-uri', 'alias-name', and 'c' (content) (). The considerations discussed in MUST be followed to include multiple query
values, ranges ('target-port', 'target-protocol'), and wildcard name
('target-fqdn', 'target-uri').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.A list of common CoAP errors that are implemented by DOTS servers are
provided in Section 9 of . The following additional
error cases apply for the telemetry extension:4.00 (Bad Request) is returned by the DOTS server when the DOTS
client has sent a request that violates the DOTS telemetry
extension.4.04 (Not Found) is returned by the DOTS server when the DOTS
client is requesting a ‘tsid’ or ‘tmid’ that
is not valid.4.00 (Bad Request) is returned by the DOTS server when the DOTS
client has sent a request with invalid query types (e.g., not
supported, malformed).4.04 (Not Found) is returned by the DOTS server when the DOTS
client has sent a request with a target query that does not match
the target of the enclosed 'mid' as maintained by the DOTS
server.This module uses types defined in
and .Note to the RFC Editor: Please replace "RFC UUUU" with the RFC
number to be assigned to .All DOTS telemetry parameters in the payload of the DOTS signal
channel MUST be mapped to CBOR types as shown in Table 2:Note: Implementers must check that the mapping output provided by
their YANG-to-CBOR encoding schemes is aligned with the content of
Table 2.This specification registers the DOTS telemetry attributes in the
IANA "DOTS Signal Channel CBOR Key Values" registry .The DOTS telemetry attributes defined in this specification are
comprehension-optional parameters.Note to the RFC Editor: CBOR keys are assigned from the 128-255
range.This specification requests IANA to assign a new code from the
"DOTS Signal Channel Conflict Cause Codes" registry .This document requests IANA to register the following URIs in the
"ns" subregistry within the "IETF XML Registry" : This document requests IANA to register the following YANG
modules in the "YANG Module Names" subregistry within the "YANG Parameters" registry.The security considerations for the DOTS signal channel protocol
are discussed in Section 11 of . The following discusses
the security considerations that are specific to the DOTS signal
channel extension defined in this document.The DOTS telemetry information includes DOTS client network
topology, DOTS client domain pipe capacity, normal traffic baseline
and connections capacity, and threat and mitigation information. Such
information is sensitive; it MUST be protected at rest by the DOTS
server domain to prevent data leakage.DOTS clients are typically trusted devices by the DOTS client
domain. DOTS clients may be co-located on network security services
(e.g., firewall) and a compromised security service potentially can do
a lot more damage to the network. This assumption differs from the
often held view that devices are untrusted, often referred to as the
"zero-trust model". A compromised DOTS client can send fake DOTS
telemetry data to a DOTS server to mislead the DOTS server. This
attack can be prevented by monitoring and auditing DOTS clients to
detect misbehavior and to deter misuse, and by only authorizing the
DOTS client to convey the DOTS telemetry for specific target resources
(e.g., an application server is authorized to exchange DOTS telemetry
for its IP addresses but a DDoS mitigator can exchange DOTS telemetry
for any target resource in the network). As a reminder, this is
variation of dealing with compromised DOTS clients as discussed in
Section 11 of .DOTS servers must be capable of defending themselves against DoS
attacks from compromised DOTS clients. The following non-comprehensive
list of mitigation techniques can be used by a DOTS server to handle
misbehaving DOTS clients:The probing rate (defined in Section 4.5 of ) can be used to limit
the average data rate to the DOTS server.Rate-limiting DOTS telemetry, including those with new 'tmid'
values, from the same DOTS client defends against DoS attacks that
would result in varying the 'tmid' to exhaust DOTS server
resources. Likewise, the DOTS server can enforce a quota and
time-limit on the number of active pre-or-ongoing-mitigation
telemetry data (identified by 'tmid') from the DOTS client.Note also that telemetry notification interval may be used to
rate-limit the pre-or-ongoing-mitigation telemetry notifications
received by a DOTS client domain.The security considerations for the DOTS data channel protocol are
discussed in Section 10 of . The
following discusses the security considerations that are specific to
the DOTS data channel extension defined in this document.All data nodes defined in the YANG module specified in which can be created, modified, and deleted
(i.e., config true, which is the default) are considered sensitive.
Write operations to these data nodes without proper protection can
have a negative effect on network operations. Appropriate security
measures are recommended to prevent illegitimate users from invoking
DOTS data channel primitives as discussed in . Nevertheless, an attacker who can access a
DOTS client is technically capable of undertaking various attacks,
such as: Communicating invalid attack mapping details to the server
('/data-channel:dots-data/data-channel:dots-client/dots-telemetry:vendor-mapping'),
which will mislead the server when correlating attack details.Some of the readable data nodes in the YANG module specified in
may be considered sensitive. It is thus
important to control read access to these data nodes. These are the
data nodes and their sensitivity:'/data-channel:dots-data/data-channel:dots-client/dots-telemetry:vendor-mapping'
can be misused to infer the DDoS protection technology deployed in
a DOTS client domain.'/data-channel:dots-data/dots-telemetry:vendor-mapping' can be
used by a compromised DOTS client to leak the attack detection
capabilities of the DOTS server. This is a variation of the
compromised DOTS client attacks discussed in .The following individuals have contributed to this document:Li Su, CMCC, Email: suli@chinamobile.comPan Wei, Huawei, Email: william.panwei@huawei.comThe authors would like to thank Flemming Andreasen, Liang Xia, and
Kaname Nishizuka co-authors of and everyone who had
contributed to that document.The authors would like to thank Kaname Nishizuka, Wei Pan, and Yuuhei
Hayashi for comments and review.Special thanks to Jon Shallow and Kaname Nishizuka for their
implementation and interoperability work.Many thanks to Jan Lindblad for the yangdoctors review and Nagendra
Nainar for the opsdir review.Private Enterprise NumbersDOTS Signal Channel CBOR Key ValuesDOTS Signal Channel Conflict Cause Codes