Re: [Ntp] [Tsv-art] Tsvart early review of draft-ietf-ntp-alternative-port-02

Danny Mayer <mayer@pdmconsulting.net> Sun, 05 December 2021 17:11 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 A576F3A0126; Sun, 5 Dec 2021 09:11:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.752
X-Spam-Level:
X-Spam-Status: No, score=-3.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, URIBL_BLOCKED=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 00C2EFbtCOsy; Sun, 5 Dec 2021 09:11:35 -0800 (PST)
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 933CA3A00E9; Sun, 5 Dec 2021 09:11:26 -0800 (PST)
Received: from [192.168.0.101] (pool-108-26-179-179.bstnma.fios.verizon.net [108.26.179.179]) (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 4J6Y4W67CWzMNS4; Sun, 5 Dec 2021 17:11:23 +0000 (UTC)
Message-ID: <fbbe7c41-4b33-6c80-cb93-033c26f48548@pdmconsulting.net>
Date: Sun, 05 Dec 2021 12:11:22 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2
Content-Language: en-US
To: Hal Murray <halmurray@sonic.net>, touch@strayalpha.com
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, ntp@ietf.org, tsvwg@ietf.org, iana-port-experts@icann.org, draft-ietf-ntp-alternative-port.all@ietf.org, tsv-art <tsv-art@ietf.org>, Harlan Stenn <stenn@nwtime.org>
References: <20211204231206.A534228C17A@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
From: Danny Mayer <mayer@pdmconsulting.net>
In-Reply-To: <20211204231206.A534228C17A@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/_aFeTqe58e-GHD5hLVW8QwlGqgY>
Subject: Re: [Ntp] [Tsv-art] Tsvart early review of draft-ietf-ntp-alternative-port-02
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <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: Sun, 05 Dec 2021 17:11:42 -0000

On 12/4/21 6:12 PM, Hal Murray wrote:
> touch@strayalpha.com said:
>> FWIW, I don't see this assignment as appropriate.
> Without a new port, it will be close to impossible to widely deploy NTP
> security.
Why would that be? NTP has a port that is widely deployed.
>
> Years ago (2013), NTP was used in a giant DDoS attack.  That was due to a
> bug/oversight that had been around since the early NTP work.  (I've tracked it
> back to 1989.)
>    https://www.spamhaus.org/news/article/695/answers-about-recent-ddos
>    https://en.wikipedia.org/wiki/Denial-of-service_attack#Amplification
> The Wikipedia chart could use another column -- the number of sites available.
>   Almost all Linux or *BSD sites were running ntpd.
>
> The fix was trivial, but there are many essentially unattended sites running
> old versions of ntpd that will never get fixed.

Yes so how is the alternative port going to magically fix this?

> Many many many sites have quietly installed filters in their routers.  Set and
> forget.
>
> A typical filter drops UDP traffic to port 123 with a length other than 48.
> That lets old unauthenticated NTP through but authenticated packets are longer
> and get dropped.
The same happened with EDNS0. Firewall administrators had to go in and 
adjust their filtering. The same thing needs to  be done for NTP. It's 
EXACTLY what would be needed for an alternate port. You're just adding 
complexity for no real benefit.
> To use authentication on the existing port would require removing those
> filters.  Even if you could track down the right people, they would probably
> drag their feet until most of the sites running old unattended ntpd were fixed.

They don't need to remove filters as much they need to change them. Are 
you saying that the alternate port would not be filtered?

Dragging feet is the norm. The same happened with EDNS0. This is just 
moving the problem without solving it.

>
> An alternative would be to implement BCP 38.  How long has that been in
> progress?
>
We cannot help people who don't implement best practices. We can only 
point them to the documentation.

Danny