[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
- [Dots] Review of draft-ietf-dots-multihoming Jon Shallow
- Re: [Dots] Review of draft-ietf-dots-multihoming mohamed.boucadair