Re: [Ntp] WGLC on draft-ietf-alternative-port-01

Danny Mayer <mayer@pdmconsulting.net> Sun, 25 July 2021 23:46 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 57C273A0E9E for <ntp@ietfa.amsl.com>; Sun, 25 Jul 2021 16:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, 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 HY68tVMRrnYM for <ntp@ietfa.amsl.com>; Sun, 25 Jul 2021 16:46:35 -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 381F13A0E9B for <ntp@ietf.org>; Sun, 25 Jul 2021 16:46:33 -0700 (PDT)
Received: from newusers-MBP.fios-router.home (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 4GY07m6Gz6zMNCS; Sun, 25 Jul 2021 23:46:28 +0000 (UTC)
To: Dieter Sibold <dsibold.ietf@gmail.com>
Cc: Watson Ladd <watsonbladd@gmail.com>, Miroslav Lichvar <mlichvar@redhat.com>, NTP WG <ntp@ietf.org>
References: <PH0PR06MB7061EF8C35B67CDE520E60F2C2349@PH0PR06MB7061.namprd06.prod.outlook.com> <YNMbMd+3dDjAnIDP@localhost> <CACsn0cnMR=E13wd06+=Jdr++s5hqvSt7VitE8euUzc2dF_SjtQ@mail.gmail.com> <a39454b6-31b2-a8f5-1070-3d1b3c155297@pdmconsulting.net> <492BFE65-30FD-42AC-8891-B9A7D007BC03@gmail.com>
From: Danny Mayer <mayer@pdmconsulting.net>
Message-ID: <ac4aa859-7d26-17ba-a33b-dec781258b52@pdmconsulting.net>
Date: Sun, 25 Jul 2021 19:46:28 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <492BFE65-30FD-42AC-8891-B9A7D007BC03@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/ch0cS7hqcxyPnjKWBGNeq314uZg>
Subject: Re: [Ntp] WGLC on draft-ietf-alternative-port-01
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, 25 Jul 2021 23:46:40 -0000

I have now come to the conclusion that this should NOT be accepted. 
Based on a conversation I had recently something like 70% of all traffic 
is still NTP V3 so this would not have any effect on them. Millions of 
firewalls would need to be changed. While the idea is generally good, 
it's not practical.

An easier and more practical proposal would be to remove mode 6 and 7 
packets from the existing protocol and require that those types of 
packets and information be done on a separate port or even use TCP.

Danny

On 7/23/21 1:26 PM, Dieter Sibold wrote:
> I agree with Danny.
> - Dieter
>
> On 24 Jun 2021, at 15:52, Danny Mayer wrote:
>
>> On 6/24/21 1:08 AM, Watson Ladd wrote:
>>> On Wed, Jun 23, 2021 at 4:30 AM Miroslav Lichvar <mlichvar@redhat.com> wrote:
>>>> On Fri, Jun 11, 2021 at 01:36:03PM +0000, Karen O'Donoghue wrote:
>>>>> NTP Working Group,
>>>>>
>>>>> This email starts a two week working group last call (WGLC) on
>>>>> https://datatracker.ietf.org/doc/draft-ietf-ntp-alternative-port/
>>>> One thing that I'd like to specifically ask everyone to consider
>>>> is the intended future of the alternative port. Do we expect NTP to
>>>> fully move there at some point and keep the port 123 only for legacy
>>>> implementations? Or should it always be just an alternative in case
>>>> the port 123 is not working?
>>> I do not think the situation with port 123 is salvageable. There is
>>> too much blocking and other manipulation. I think this doc as is is
>>> the only way forward.
>> Using an alternative port will not fly. You need to remember that there are millions upon millions of devices out there that use port 123 for NTP. Don't expect them to change just because you wrote a document to say to use a different port. If you want to use a different port you may as well design a different protocol. The port number is baked in and all firewalls would need to be changed to accommodate this.
>>
>> I will need to read the document again and decide on my vote. I don't think that the consequences have been thought through.
>>
>> Danny
>>
>>
>> _______________________________________________
>> ntp mailing list
>> ntp@ietf.org
>> https://www.ietf.org/mailman/listinfo/ntp