Re: [Ntp] DDoS meets NTP

Danny Mayer <mayer@pdmconsulting.net> Mon, 19 April 2021 22:33 UTC

Return-Path: <mayer@pdmconsulting.net>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974213A4728 for <ntp@ietfa.amsl.com>; Mon, 19 Apr 2021 15:33:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-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 naofdCIgBylQ for <ntp@ietfa.amsl.com>; Mon, 19 Apr 2021 15:33:52 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (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 6D0A33A4726 for <ntp@ietf.org>; Mon, 19 Apr 2021 15:33:50 -0700 (PDT)
Received: from newusers-MBP.fios-router.home (pool-108-26-201-164.bstnma.fios.verizon.net [108.26.201.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4FPM6j4R8wzMNJk; Mon, 19 Apr 2021 22:33:49 +0000 (UTC)
To: Hal Murray <hmurray@megapathdsl.net>, NTP WG <ntp@ietf.org>
References: <20210419173823.CF68C40605C@ip-64-139-1-69.sjc.megapath.net>
From: Danny Mayer <mayer@pdmconsulting.net>
Message-ID: <6a2a9a69-c213-847c-ee2f-7a73ffddba65@pdmconsulting.net>
Date: Mon, 19 Apr 2021 18:33:48 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1
MIME-Version: 1.0
In-Reply-To: <20210419173823.CF68C40605C@ip-64-139-1-69.sjc.megapath.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/Y_C7aeNcGKSbxy8bQ5kAdpzsGrU>
Subject: Re: [Ntp] DDoS meets NTP
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Apr 2021 22:33:57 -0000

On 4/19/21 1:38 PM, Hal Murray wrote:
> One tool in this area is to have the NTS cookies tied to an IP Address.  We
> discussed this a long time ago.  Nobody was interested, but I've forgotten
> why.  Maybe it was more important to allow laptops to keep using their cookies
> across migrations that change IP Addresses.
>
> We could make it an option.  Then people with fixed addresses could turn it on
> and servers could have 2 modes of rate limiting.  That doesn't help if the bad
> guy can capture traffic from the client.  The server can't tell a replay from
> normal traffic.

This doesn't work at all. You should never be tying cookies to an IP 
address. Which address would that be? An IPv4 address, an IPV6 address, 
a VPN IP address, all of which can be active at the same time and being 
used at the same time. This is just as bad as the ReferenceID being used 
as the IP address from which it got it's preferred truechimer clock.

Danny