[Dots] Review of draft-ietf-dots-multihoming

Jon Shallow <supjps-ietf@jpshallow.com> Fri, 02 July 2021 16:01 UTC

Return-Path: <supjps-ietf@jpshallow.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3734E3A2346 for <dots@ietfa.amsl.com>; Fri, 2 Jul 2021 09:01:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHYTghTP1GZR for <dots@ietfa.amsl.com>; Fri, 2 Jul 2021 09:01:53 -0700 (PDT)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693E53A2345 for <dots@ietf.org>; Fri, 2 Jul 2021 09:01:53 -0700 (PDT)
Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from <jon.shallow@jpshallow.com>) id 1lzLbx-0006RY-O6 for ietf-supjps-dots@ietf.org; Fri, 02 Jul 2021 17:01:49 +0100
From: Jon Shallow <supjps-ietf@jpshallow.com>
To: dots@ietf.org
Date: Fri, 02 Jul 2021 17:01:58 +0100
Message-ID: <047d01d76f5b$962ce270$c286a750$@jpshallow.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AddvWudDcUgmBKmzR+ShoFd1LWw6kw==
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/3K7yVN1XA2mUsM207RC10lBDgy0>
Subject: [Dots] Review of draft-ietf-dots-multihoming
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Jul 2021 16:01:55 -0000

Hi all,

I have done a review of draft-ietf-dots-multihoming and have come up with
some things that I think need to be corrected/updated.

s/I-D.ietf-dots-use-cases/RFC8903/g
s/RFC8782/I-D.ietf-dots-rfc8782-bis/g

1. Introduction

OLD - needs rewording

   In many deployments, it may not be possible for a network to
   determine the cause of a distributed Denial-of-Service (DoS) attack
   [RFC4732].  Rather, the network may just realize that some resources
   seem to be under attack.  To improve such situation, the IETF is
   specifying the DDoS Open Threat Signaling (DOTS) architecture
   [RFC8811], where 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 jeopardizes the efficiency of DDoS attack mitigation actions,
   the DOTS protocol is meant to carry requests for DDoS attack
   mitigation, thereby reducing the impact of an attack and leading to
   more efficient responsive actions.

NEW

   In many deployments, it may not be possible for a network to
   determine the root cause of a distributed Denial-of-Service (DoS) attack
   [RFC4732].  Rather, the network may just realize that some resources
   appear to be under attack.  To help with such situations, the IETF has
   specified the DDoS Open Threat Signaling (DOTS) architecture
   [RFC8811], where a DOTS client can inform an upstream DOTS server that
its
   network is under a potential attack and that appropriate mitigation
   actions are required.  The DOTS protocols can be used to coordinate
real-time mitigation efforts which can evolve at the attacks mutate,
  thereby reducing the impact of an attack and leading to
   more efficient responsive actions.

OLD

provided DOTS server(s) addresses (e.g.,
   [RFC8973]).

NEW

provided DOTS server(s) addresses (e.g., by using
   [RFC8973]).

OLD

          * Send a DOTS mitigation request to an arbitrary DOTS server
          won't help mitigating a DDoS attack.

NEW

          * Sending a DOTS mitigation request to an arbitrary DOTS server
          Will not necessarily help in  mitigating a DDoS attack.

s/Sketch guidelines and recommendations/Give guidelines and recommendations/

s/ Identify cases where anycast is not recommended./ Identify cases where
anycast is not recommended for DOTS./

3. Terminology

Define PA and PI addresses (I know we define them in Section 1, but this may
help  the reader).

4.2 Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs

s/is connected to the Internet using one single router is connected to the
Internet using a single router/

4.4 Multi-homed Enterprise with the Same ISP

Do we need to consider 4.1 in the same light - ISPs here in the UK are now
offering wired plus backup 4G options to the Residential user?  In other
words, I think we need to add in to the relevant places "Multi-Homed
Residential, Single provisioning domain".

5.1 Residential CPE

s/ be established and maintained with each of the DOTS servers because/ be
established and MUST be maintained with each of the DOTS servers because/

s/ the mitigation scope of these servers is restricted./ the mitigation
scope of each of these servers is restricted./

OLD

  the DOTS client among the DOTS servers available MUST select a DOTS
   server whose network has assigned the IP prefixes from which target

NEW

  the DOTS client MUST select an available DOTS
   server whose network has assigned the IP prefixes from which target

s/ domain another domain than the one that owns those addresses/ domain
other than the one that owns those addresses/

" Nevertheless, if the DDoS attack is
   received from one single network, then only the DOTS server of that
   network MUST be contacted."

Does not make sense to me and either needs to be re-written or removed.

5.2 Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs

s/ One of more DOTS clients/ One or more DOTS clients/

s/ some issues arise to steer traffic towards the appropriate DOTS server/
some issues may arise in how to steer traffic towards the appropriate DOTS
server

6. Security Considerations

OLD

   DOTS client should not leak information specific to a given link to
   DOTS servers not authorized to mitigate attacks received on that
   link.

NEW

   DOTS client SHOULD NOT leak information specific to a given link to
   DOTS servers on different interconnection links that are not authorized
to mitigate attacks for that given link.



Regards

Jon