Distributed-Denial-of-Service Open
Threat Signaling (DOTS) Server DiscoveryOrangeRennes35000Francemohamed.boucadair@orange.comMcAfee, Inc.Embassy Golf Link Business ParkBangaloreKarnataka560071IndiaTirumaleswarReddy_Konda@McAfee.comDOTSAutomationProvisioningConfigurationLocationDeploymentMultihomingDDoSSecurityIt may not be possible for a network to determine the cause for an
attack, but instead just realize that some resources seem to be under
attack. To fill that gap, Distributed-Denial-of-Service Open Threat
Signaling (DOTS) allows a network to inform a DOTS server that it is
under a potential attack so that appropriate mitigation actions are
undertaken.This document specifies mechanisms to configure DOTS clients with
DOTS servers. The discovery procedure also covers the DOTS Signal
Channel Call Home. DDoS Open Threat Signaling (DOTS) specifies an architecture,
in which a DOTS client can inform a DOTS server that the network is
under a potential attack and that appropriate mitigation actions are
required. Indeed, because the lack of a common method to coordinate a
real-time response among involved actors and network domains inhibits
the effectiveness of DDoS attack mitigation, DOTS signal channel
protocol is meant to
carry requests for DDoS attack mitigation, thereby reducing the impact
of an attack and leading to more efficient defensive actions in various
deployment scenarios such as those discussed in . Moreover, DOTS clients can
instruct a DOTS server to install filtering rules by means of DOTS data
channel .The basic high-level DOTS architecture is illustrated in (): specifies that the
DOTS client may be provided with a list of DOTS servers; each associated
with one or more IP addresses. These addresses may or may not be of the
same address family. The DOTS client establishes one or more DOTS
sessions by connecting to the provided DOTS server addresses.This document specifies methods for DOTS clients to discover their
DOTS server(s). The rationale for specifying multiple discovery
mechanisms is discussed in .The discovery methods can also used by a DOTS server to locate a DOTS
client in the context of DOTS Signal Channel Call Home .Considerations for the selection of DOTS server(s) by multi-homed
DOTS clients is out of scope; the reader should refer to for more details.Likewise, happy eyeballs considerations for DOTS signal channel
protocol are out of scope. The reader should refer to Section 4 of .This document assumes that security credentials to authenticate DOTS
server(s) are provisioned to a DOTS client using a variety of means such
as (but not limited to) those discussed in or . DOTS clients use
those credentials for authentication purposes following the rules
documented in .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 and .DHCP refers to both DHCPv4 and DHCPv6
."Peer DOTS agent" refers to the peer DOTS server (normal DOTS
operation) or to a peer DOTS client (for DOTS Signal Channel Call
Home).It is tempting to specify one single discovery mechanism for DOTS.
Nevertheless, the analysis of the various use cases sketched in reveals that it is unlikely
that one single discovery method can be suitable for all the sample
deployments. Concretely:Many use cases discussed in do involve a CPE device.
Multiple CPEs, connected to distinct network providers may even be
considered. It is intuitive to leverage on existing mechanisms such
as discovery using service resolution or DHCP to provision the CPE
acting as a DOTS client with the DOTS server(s).Resolving a DOTS server domain name offered by an upstream
transit provider provisioned to a DOTS client into IP address(es)
require the use of the appropriate DNS resolvers; otherwise,
resolving those names will fail. The use of protocols such as DHCP
does allow to associate provisioned DOTS server domain names with a
list of DNS servers to be used for name resolution. Furthermore,
DHCP allows to directly provision IP addresses avoiding therefore
the need for extra lookup delays.Some of the use cases may allow DOTS clients to have direct
communications with upstream DOTS servers; that is no DOTS gateway
is involved. Leveraging on existing features that do not require
specific feature on the node embedding the DOTS client may ease DOTS
deployment. Typically, the use of Straightforward-Naming Authority
Pointer (S-NAPTR) lookups allows the
DOTS server administrators to provision the preferred DOTS transport
protocol between the DOTS client and the DOTS server and allows the
DOTS client to discover this preference.The upstream network provider is not the DDoS mitigation provider
for some of these use cases. It is safe to assume that for such
deployments, the DOTS server(s) domain name is provided during the
service subscription (i.e., manual/local configuration).Multiple DOTS clients may be enabled within a network (e.g.,
enterprise network). Dynamic means to discover DOTS servers in a
deterministic manner are interesting from an operational
standpoint.Some of the use cases may involve a DOTS gateway that is
responsible for selecting the appropriate DOTS server(s) to relay
requests received from DOTS clients.Consequently, this document describes a unified discovery logic
() which involves the following
mechanisms:Dynamic discovery using DHCP ().A resolution mechanism based on straightforward Naming Authority
Pointer (S-NAPTR) resource records in the Domain Name System (DNS)
().DNS Service Discovery ().A key point in the deployment of DOTS is the ability of network
operators to be able to configure DOTS clients with the correct DOTS
server(s) information consistently. To accomplish this, operators will
need a consistent set of ways in which DOTS clients can discover this
information, and a consistent priority among these options. If some
devices prefer manual configuration over dynamic discovery, while others
prefer dynamic discovery over manual configuration, the result will be a
process of "whack-a-mole", where the operator must find devices that are
using the wrong DOTS server(s), determine how to ensure the devices are
configured properly, and then reconfigure the device through the
preferred method.All DOTS clients MUST support at least one of the three mechanisms
below to determine a DOTS server list. All DOTS clients SHOULD implement
all three, or as many as are practical for any specific device, of these
ways to discover DOTS servers, in order to facilitate the deployment of
DOTS in large scale environments:Explicit configuration:Local/Manual configuration: A DOTS client, will learn the
DOTS server(s) by means of local or manual DOTS configuration
(i.e., DOTS servers configured at the system level).
Configuration discovered from a DOTS client application is
considered as local configuration.An
implementation may give the user an opportunity (e.g., by means
of configuration file options or menu items) to specify DOTS
server(s) for each address family. These MAY be specified either
as IP addresses or the DNS name of a DOTS server. When only DOTS
server's IP addresses are configured, a reference identifier
must also be configured for authentication purposes.Automatic configuration (e.g., DHCP, an automation system):
The DOTS client attempts to discover DOTS server(s) names and/or
addresses from DHCP, as described in .Service Resolution : The DOTS client attempts to discover DOTS
server name(s) using service resolution, as specified in .DNS SD: DNS Service Discovery. The DOTS client attempts to
discover DOTS server name(s) using DNS service discovery, as
specified in .Some of these mechanisms imply the use of DNS to resolve the IP
address(es) of the DOTS server, while others imply an IP address of the
relevant DOTS server is obtained directly. Implementation options may
vary on a per device basis, as some devices may not have DNS
capabilities and/or proper configuration.DOTS clients will prefer information received from the discovery
methods in the order listed.On hosts with more than one interface or address family (IPv4/v6),
the DOTS server discovery procedure has to be performed for each
combination of interface and address family. A client MAY choose to
perform the discovery procedure only for a desired interface/address
combination if the client does not wish to discover a DOTS server for
all combinations of interface and address family.The above procedure MUST also be followed by a DOTS gateway.
Likewise, this procedure MUST be followed by a DOTS server in the
context of DOTS Signal Channel Call Home .The discovery method MUST be reiterated upon the following
events:Expiry of a lease associated with a discovered DOTS server.Expiry of a DOTS server's certificate currently in use.Attachment to a new network.As reported in Section 1.7.2 of :"few certification authorities issue server certificates based on
IP addresses, but preliminary evidence indicates that such
certificates are a very small percentage (less than 1%) of issued
certificates".In order to allow for PKIX-based authentication between a DOTS client
and server while accommodating for the current best practices for
issuing certificates, this document allows for configuring names to DOTS
clients. These names can be used for two purposes: to retrieve the list
of IP addresses of a DOTS server or to be presented as a reference
identifier for authentication purposes.Defining the option to include a list of IP addresses would avoid a
dependency on an underlying name resolution, but that design requires to
also supply a name for PKIX-based authentication purposes.The design assumes that the same peer DOTS agent is used for
establishing both signal and data channels. For more customized
configurations (e.g., transport-specific configuration, distinct DOTS
servers for the signal and the data channels), an operator can supply
only a DOTS reference identifier that will be then passed to the
procedure described in .The DHCPv6 DOTS option is used to configure a name of the DOTS
server (or the name of the DOTS client for DOTS Signal Channel Call
Home). The format of this option is shown in .The fields of the option shown in are as follows:Option-code: OPTION_V6_DOTS_RI (TBA1, see )Option-length: Length of the dots-server-name field in
octets.dots-agent-name: A fully qualified domain name of the peer
DOTS agent. This field is formatted as specified in Section 10
of .An example of the dots-agent-name
encoding is shown in . This example
conveys the FQDN "dots.example.com.".The DHCPv6 DOTS option can be used to configure a list of IPv6
addresses of a DOTS server (or a DOTS client for DOTS Signal Channel
Call Home). The format of this option is shown in . As a reminder, this format follows
the guidelines for creating new DHCPv6 options (Section 5.1 of ).The fields of the option shown in are as follows:Option-code: OPTION_V6_DOTS_ADDRESS (TBA2, see )Option-length: Length of the 'DOTS ipv6-address(es)' field in
octets. MUST be a multiple of 16.DOTS ipv6-address: Includes one or more IPv6 addresses of the peer DOTS agent to be used by a
DOTS agent for establishing a DOTS session. Note, IPv4-mapped IPv6 addresses (Section
2.5.5.2 of ) are allowed to be
included in this option.To return more than one DOTS agents to
the requesting DHCPv6 client, the DHCPv6 server returns multiple
instances of OPTION_V6_DOTS.DHCP clients MAY request options OPTION_V6_DOTS_RI and
OPTION_V6_DOTS_ADDRESS, as defined in , Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5,
18.2.6, and 21.7. As a convenience to the reader, it is mentioned
here that the DHCP client includes the requested option codes in the
Option Request Option.If the DHCP client receives more than one instance of
OPTION_V6_DOTS_RI (or OPTION_V6_DOTS_ADDRESS) option, it MUST use
only the first instance of that option.If the DHCP client receives both OPTION_V6_DOTS_RI and
OPTION_V6_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as
reference identifier for authentication purposes (e.g., PKIX ), while the addresses included in
OPTION_V6_DOTS_ADDRESS are used to reach the peer DOTS agent. In
other words, the name conveyed in OPTION_V6_DOTS_RI MUST NOT be
passed to underlying resolution library in the presence of
OPTION_V6_DOTS_ADDRESS in a response.If the DHCP client receives OPTION_V6_DOTS_RI only, but
OPTION_V6_DOTS_RI option contains more than one name, as
distinguished by the presence of multiple root labels, the DHCP
client MUST use only the first name. Once the name is validated
(Section 8 of ), the name is passed to
a name resolution library. Moreover, that name is also used as a
reference identifier for authentication purposes.If the DHCP client receives OPTION_V6_DOTS_ADDRESS only, the
address(es) included in OPTION_V6_DOTS_ADDRESS is used to reach the
peer DOTS agent. In addition, these addresses can be used as
identifiers for authentication.The DHCP client MUST silently discard multicast and host loopback
addresses conveyed in
OPTION_V6_DOTS_ADDRESS.The DHCPv4 DOTS option is used to configure a name of the peer
DOTS agent. The format of this option is illustrated in .The fields of the option shown in are as follows:Code: OPTION_V4_DOTS_RI (TBA3, see );Length: Includes the length of the "DOTS server name" field
in octets; the maximum length is 255 octets.Peer DOTS agent name: The domain name of the peer DOTS agent.
This field is formatted as specified in Section 10 of .The DHCPv4 DOTS option can be used to configure a list of IPv4
addresses of a peer DOTS agent. The format of this option is
illustrated in .The fields of the option shown in are as follows:Code: OPTION_V4_DOTS_ADDRESS (TBA4, see );Length: Length of all included data in octets. The minimum
length is 5.List-Length: Length of the "List of DOTS IPv4 Addresses"
field in octets; MUST be a multiple of 4.List of DOTS IPv4 Addresses: Contains one or more IPv4
addresses of the peer DOTS agent to be used by a DOTS agent. The
format of this field is shown in .OPTION_V4_DOTS_ADDRESS can include multiple lists of DOTS
IPv4 addresses; each list is treated separately as it
corresponds to a given peer DOTS agent. When several lists of DOTS IPv4 addresses are
to be included, "List-Length" and "DOTS IPv4 Addresses" fields
are repeated.OPTION_V4_DOTS_ADDRESS is a
concatenation-requiring option. As such, the mechanism specified in
MUST be used if
OPTION_V4_DOTS_ADDRESS exceeds the maximum DHCPv4 option size of 255
octets.To discover a peer DOTS agent, the DHCPv4 client MUST include
both OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter
Request List Option .If the DHCP client receives more than one instance of
OPTION_V4_DOTS_RI (or OPTION_V4_DOTS_ADDRESS) option, it MUST use
only the first instance of that option.If the DHCP client receives both OPTION_V4_DOTS_RI and
OPTION_V4_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as
reference identifier for authentication purposes, while the
addresses included in OPTION_V4_DOTS_ADDRESS are used to reach the
peer DOTS agent. In other words, the name conveyed in
OPTION_V4_DOTS_RI MUST NOT be passed to underlying resolution
library in the presence of OPTION_V4_DOTS_ADDRESS in a response.If the DHCP client receives OPTION_V4_DOTS_RI only, but
OPTION_V4_DOTS_RI option contains more than one name, as
distinguished by the presence of multiple root labels, the DHCP
client MUST use only the first name. Once the name is validated
(Section 10 of ), the name is passed
to a name resolution library. Moreover, that name is also used as a
reference identifier for authentication purposes.If the DHCP client receives OPTION_V4_DOTS_ADDRESS only, the
address(es) included in OPTION_V4_DOTS_ADDRESS is used to reach the
peer DOTS server. In addition, these addresses can be used as
identifiers for authentication.The DHCP client MUST silently discard multicast and host loopback
addresses conveyed in OPTION_V4_DOTS_ADDRESS.This mechanism is performed in two steps:A DNS domain name is retrieved for each combination of interface
and address family. A DOTS client has to determine the domain in
which it is located relying on dynamic means such as DHCP () . Implementations MAY allow the user to
specify a default name that is used, if no specific name has been
configured.Retrieved DNS domain names are then used for S-NAPTR lookups.
Further DNS lookups may be necessary to determine DOTS server IP
address(es).Once the DOTS client has retrieved client's DNS domain or discovered
the peer DOTS agent name that needs to be resolved (e.g., ), an S-NAPTR lookup with 'DOTS' application
service and the desired protocol tag is made to obtain information
necessary to connect to the authoritative DOTS server within the given
domain.This specification defines "DOTS" and "DOTS-CALL-HOME" as application
service tags (Sections
and ). It also defines
"signal.udp" (), "signal.tcp" (), and "data.tcp" ()
as application protocol tags. An example is provided in . An example is provided in for the
Call Home case.If no DOTS-specific S-NAPTR records can be retrieved, the discovery
procedure fails for this domain name (and the corresponding interface
and IP protocol version). If more domain names are known, the discovery
procedure MAY perform the corresponding S-NAPTR lookups immediately.
However, before retrying a lookup that has failed, a DOTS client MUST
wait a time period that is appropriate for the encountered error (e.g.,
NXDOMAIN, timeout, etc.).DNS-based Service Discovery (DNS-SD)
provides generic solutions for discovering services. DNS-SD defines a
set of naming rules for certain DNS record types that they use for
advertising and discovering services.Section 4.1 of specifies that a
service instance name in DNS-SD has the following structure:The <Domain> portion specifies the DNS sub-domain where the
service instance is registered. It may be "local.", indicating the mDNS
local domain, or it may be a conventional domain name such as
"example.com.".The <Service> portion of the DOTS service instance name MUST be
"_dots._signal._udp" or "_dots._signal._tcp" or "_dots._data._tcp" or
"_dots-call-home._signal._udp" or "_dots-call-home._signal._tcp".DOTS-related security considerations are discussed in Section 4 of
is to be considered.
DOTS agents must authenticate each other using (D)TLS before a DOTS
session is considered valid according to the .The security considerations in and
are to be considered.The primary attack against the methods described in is one that would lead to impersonation of a
DOTS server. An attacker could attempt to compromise the S-NAPTR
resolution. The use of mutual authentication makes it difficult to
redirect a DOTS client to an illegitimate DOTS server.Since DNS-SD is just a specification for how to name and use
records in the existing DNS system, it has no specific additional
security requirements over and above those that already apply to DNS
queries and DNS updates. For DNS queries, DNS Security Extensions
(DNSSEC) SHOULD be used where the
authenticity of information is important. For DNS updates, secure
updates
SHOULD generally be used to control which clients have permission to
update DNS records.IANA is requested to allocate the SRV service name of "_dots._signal"
for DOTS signal channel over UDP or TCP, and the service name of
"_dots._data" for DOTS data channel over TCP.IANA is requested to assign the following new DHCPv6 Option Code in
the registry maintained in:
http://www.iana.org/assignments/dhcpv6-parameters.IANA is requested to assign the following new DHCPv4 Option Code in
the registry maintained in:
http://www.iana.org/assignments/bootp-dhcp-parameters/.Option NameValueData lengthMeaningOPTION_V4_DOTS_RITBA3Variable; the maximum length is 255 octets.Includes the name of the DOTS server.OPTION_V4_DOTS_ADDRESSTBA4Variable; the minimum length is 5.Includes one or multiple lists of DOTS IP addresses; each list is
treated as a separate DOTS server.This document requests IANA to make the following allocations from
the registry available at:
https://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.xhtml.Application Protocol Tag: DOTSIntended Usage: See Security Considerations: See Contact Information: <one of the authors>Application Protocol Tag: DOTS-CALL-HOMEIntended Usage: See Security Considerations: See Contact Information: <one of the authors>Application Protocol Tag: signal.udpIntended Usage: See Security Considerations: See Contact Information: <one of the authors>Application Protocol Tag: signal.tcpIntended Usage: See Security Considerations: See Contact Information: <one of the authors>Application Protocol Tag: data.tcpIntended Usage: See Security Considerations: See Contact Information: <one of the authors>Thanks to Brian Carpenter for the review of the BRSKI text.Many thanks to Russ White for the review, comments, and text
contribution.Thanks for Dan Wing and Pei Wei for the review and comments.Thanks to Bernie Volz for the review of the DHCP section.