DDoS Open Threat Signaling (DOTS) Agent Discovery
RFC 8973

Document Type RFC - Proposed Standard (January 2021; No errata)
Authors Mohamed Boucadair  , Tirumaleswar Reddy.K 
Last updated 2021-01-12
Replaces draft-boucadair-dots-server-discovery
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication (wg milestone: Nov 2019 - DOTS Server Discover... )
Document shepherd Valery Smyslov
Shepherd write-up Show (last changed 2020-02-07)
IESG IESG state RFC 8973 (Proposed Standard)
Consensus Boilerplate Yes
Telechat date
Responsible AD Benjamin Kaduk
Send notices to Valery Smyslov <valery@smyslov.net>
IANA IANA review state IANA OK - Actions Needed
IANA action state RFC-Ed-Ack
IANA expert review state Expert Reviews OK
IANA expert review comments All registrations approved.


Internet Engineering Task Force (IETF)                      M. Boucadair
Request for Comments: 8973                                        Orange
Category: Standards Track                                     T. Reddy.K
ISSN: 2070-1721                                                   McAfee
                                                            January 2021

           DDoS Open Threat Signaling (DOTS) Agent Discovery

Abstract

   This document specifies mechanisms to configure DDoS Open Threat
   Signaling (DOTS) clients with their DOTS servers.  The discovery
   procedure also covers the DOTS signal channel Call Home.  It can be
   useful to know the appropriate DOTS server for a given location in
   order to engage mitigation actions.  This is true even in cases where
   the DOTS client cannot localize the attack: cases where it only knows
   that some resources are under attack and that help is needed.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8973.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  Why Multiple Discovery Mechanisms?
   4.  DOTS Discovery Procedure
   5.  DHCP Options for DOTS Agent Discovery
     5.1.  DHCPv6 DOTS Options
       5.1.1.  Format of DOTS Reference Identifier Option
       5.1.2.  Format of DOTS Address Option
       5.1.3.  DHCPv6 Client Behavior
     5.2.  DHCPv4 DOTS Options
       5.2.1.  Format of DOTS Reference Identifier Option
       5.2.2.  Format of DOTS Address Option
       5.2.3.  DHCPv4 Client Behavior
   6.  Discovery Using Service Resolution
   7.  DNS Service Discovery
   8.  Security Considerations
     8.1.  DHCP
     8.2.  Service Resolution
     8.3.  DNS Service Discovery
   9.  IANA Considerations
     9.1.  Service Name and Transport Protocol Port Number Registry
     9.2.  DHCPv6 Options
     9.3.  DHCPv4 Options
     9.4.  Application Service & Application Protocol Tags
       9.4.1.  DOTS Application Service Tag Registration
       9.4.2.  DOTS Call Home Application Service Tag Registration
       9.4.3.  signal.udp Application Protocol Tag Registration
       9.4.4.  signal.tcp Application Protocol Tag Registration
       9.4.5.  data.tcp Application Protocol Tag Registration
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Acknowledgements
   Contributors
   Authors' Addresses

1.  Introduction

   DDoS Open Threat Signaling (DOTS) [RFC8811] 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, the DOTS signal
   channel protocol [RFC8782] is meant to carry requests for DDoS attack
   mitigation.  With this approach, DOTS can reduce the impact of an
   attack and lead to more efficient defensive actions in various
   deployment scenarios, such as those discussed in [DOTS-USE-CASES].
   Moreover, DOTS clients can instruct a DOTS server to install named
   filtering rules by means of the DOTS data channel protocol [RFC8783].

   The basic high-level DOTS architecture is illustrated in Figure 1.

                 +-----------+            +-------------+
                 | Mitigator | ~~~~~~~~~~ | DOTS Server |
                 +-----------+            +------+------+
                                                 |
                                                 |
                                                 |
                 +---------------+        +------+------+
                 | Attack Target | ~~~~~~ | DOTS Client |
                 +---------------+        +-------------+
Show full document text