Re: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts

Miroslav Lichvar <mlichvar@redhat.com> Tue, 10 September 2019 07:47 UTC

Return-Path: <mlichvar@redhat.com>
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 AE0A112006A for <ntp@ietfa.amsl.com>; Tue, 10 Sep 2019 00:47:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 RgNRuSAYA6_w for <ntp@ietfa.amsl.com>; Tue, 10 Sep 2019 00:47:11 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF6012004F for <ntp@ietf.org>; Tue, 10 Sep 2019 00:47:11 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 34EFB10F23EE for <ntp@ietf.org>; Tue, 10 Sep 2019 07:47:10 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AEEBD1001944 for <ntp@ietf.org>; Tue, 10 Sep 2019 07:47:09 +0000 (UTC)
Date: Tue, 10 Sep 2019 09:47:04 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: ntp@ietf.org
Message-ID: <20190910074704.GB21704@localhost>
References: <heiko.gerstung@meinberg.de> <F9ECE897-2A6D-4336-86B6-88F87FC4BA89@meinberg.de> <20190903081335.15AB8406062@ip-64-139-1-69.sjc.megapath.net> <AF23AEA1-E2A4-4F4B-9649-21BCF3BFBD8B@akamai.com> <CAJm83bC81BWxGPmGbaTgxU6vmKtWF_-j5oMohyU9M5YX9HqbYQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJm83bC81BWxGPmGbaTgxU6vmKtWF_-j5oMohyU9M5YX9HqbYQ@mail.gmail.com>
User-Agent: Mutt/1.12.0 (2019-05-25)
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.66]); Tue, 10 Sep 2019 07:47:10 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/8QSiSyazST94nTN9yN5k07SUeUI>
Subject: Re: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
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: Tue, 10 Sep 2019 07:47:13 -0000

On Mon, Sep 09, 2019 at 12:18:01PM -0400, Daniel Franke wrote:
> On Mon, Sep 9, 2019 at 12:08 PM Salz, Rich <rsalz@akamai.com> wrote:
> >
> > >    It can't.  There are fields in a NTP v3 reply that are copied from the request
> >     packet.  The v3 only system doesn't know how to find them in a v4 packet.
> >
> > So that could be a signal to the sender that the receiver does not know the version, right?
> 
> The only thing that would really paint us into a corner would be if
> there were a lot of v4 servers out there that reply to v5 packets with
> something structured like a v4 packet but with a 5 in the version
> field.

IIRC, there are few implementations that do that. openntpd is probably
the most widely used one. As a server, it just checks if the packet is
48 or 64 octets long and that the mode is 1 or 3. It doesn't support
extension fields. Sending requests with length != 48 would be a simple
way to prevent it from responding (correctly).

> I propose we just avoid this situation entirely by making NTS a
> mandatory part of v5.

I don't think that is a good idea. I'm sure we can figure out
something simple that doesn't require TCP or TLS. For instance, moving
the origin field in the header would prevent such broken servers from
sending a valid response.

-- 
Miroslav Lichvar