Re: [Ntp] [tsvwg] Antw: [EXT] Re: [Tsv‑art] Tsvart early review of draft‑ietf‑ntp‑alternative‑port‑02

Eliot Lear <lear@lear.ch> Mon, 06 December 2021 10:16 UTC

Return-Path: <lear@lear.ch>
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 C1E893A09D1; Mon, 6 Dec 2021 02:16:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.742
X-Spam-Level:
X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
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 t4Iq79oBWfEO; Mon, 6 Dec 2021 02:16:30 -0800 (PST)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 D1E333A09C1; Mon, 6 Dec 2021 02:16:28 -0800 (PST)
Received: from [IPV6:2001:420:c0c0:1011::4] ([IPv6:2001:420:c0c0:1011:0:0:0:4]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1B6AFvkD2139193 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 6 Dec 2021 11:15:58 +0100
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1638785759; bh=9F72CrvVLD6Pe8rU6muVjwpQh8YxwelpKqPIczRkyes=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=LI7uO9nuzexWcCTonIsgqeVLZfeVKu1tP6/vyd1Hvg+3VJ7gZOEg6CCcq9C0azIMm j/4+hiK384MoNCNjT0xcQuDFG0uvbndsgAv/JcWCGTrHodN9or1Mr7hHgNZZ2n8oSN lm3eIZCB8oYGUbvBz9uL6jREMRQYm6UWJwXGaF/0=
Message-ID: <b694a433-8555-0eed-e38f-c15c0e2a6e98@lear.ch>
Date: Mon, 06 Dec 2021 11:15:55 +0100
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: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, halmurray@sonic.net, touch@strayalpha.com
Cc: magnus.westerlund@ericsson.com, "ntp@ietf.org" <ntp@ietf.org>, tsvwg@ietf.org, iana-port-experts@icann.org, draft-ietf-ntp-alternative-port.all@ietf.org, tsv-art@ietf.org
References: <20211204231206.A534228C17A@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <61ADC2E6020000A100046157@gwsmtp.uni-regensburg.de>
From: Eliot Lear <lear@lear.ch>
In-Reply-To: <61ADC2E6020000A100046157@gwsmtp.uni-regensburg.de>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------iJuyirjyNWPlnbuUM1Sk4Pcl"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/mNVOlIM3aXThRvLAhp7guVzwLY0>
Subject: Re: [Ntp] [tsvwg] Antw: [EXT] Re: [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: Mon, 06 Dec 2021 10:16:35 -0000

I have a question:

Had neither NTP nor NTS existed, and you were requesting a new port for 
a secure time protocol, would you have designed it identically?

Eliot

On 06.12.21 08:59, Ulrich Windl wrote:
>>>> Hal Murray <halmurray@sonic.net> schrieb am 05.12.2021 um 00:12 in Nachricht
> <20211204231206.A534228C17A@107-137-68-211.lightspeed.sntcca.sbcglobal.net>:
>
> ...
>> Many many many sites have quietly installed filters in their routers.  Set
>> and
>> forget.
> ...
>
> Can any RFC do something against that "set and forget" mentality? I guess not.
>
>
>> 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.
> Still no RFC can fix this. Anybody having read the NTPv3/NTPv4 RFCs should know better.
>
> ...
>
> Regards,
> Ulrich
>
>   
>
>
>