IETF Logo Mail Archive

Re: [Ntp] The NTP WG has placed draft-roughtime-aanchal in state "Call For Adoption By WG Issued"

Miroslav Lichvar <mlichvar@redhat.com> Wed, 11 September 2019 15:01 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 0D312120969 for <ntp@ietfa.amsl.com>; Wed, 11 Sep 2019 08:01:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 nFQlRTuJ6tFd for <ntp@ietfa.amsl.com>; Wed, 11 Sep 2019 08:01:21 -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 CBC5D12094F for <ntp@ietf.org>; Wed, 11 Sep 2019 08:01:21 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 68E90C05686D for <ntp@ietf.org>; Wed, 11 Sep 2019 15:01:21 +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 D91A25FCA6 for <ntp@ietf.org>; Wed, 11 Sep 2019 15:01:20 +0000 (UTC)
Date: Wed, 11 Sep 2019 17:01:15 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: ntp@ietf.org
Message-ID: <20190911150115.GK21704@localhost>
References: <watsonbladd@gmail.com> <CACsn0cktCkUjS-gUSWPhVoo+LWJD_MVeSaX2WqdcH0WNPyo2Tg@mail.gmail.com> <20190910063355.7082A40605C@ip-64-139-1-69.sjc.megapath.net> <OFA013F915.2AEF3333-ONC1258471.00380E6E-C1258471.003BA9C3@ptb.de> <dbf6adae-dd5a-2c86-7bc2-2829db0cbb83@dansarie.se> <20190911070549.GF21704@localhost> <CACsn0ckvfJKL6dfwo1W6Kh2DKrxcb_LwPLFN=wBQcM4L4DBdCw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CACsn0ckvfJKL6dfwo1W6Kh2DKrxcb_LwPLFN=wBQcM4L4DBdCw@mail.gmail.com>
User-Agent: Mutt/1.12.0 (2019-05-25)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 11 Sep 2019 15:01:21 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/v8JJJr3-MeQMd6dyXmrOqiM3rmw>
Subject: Re: [Ntp] The NTP WG has placed draft-roughtime-aanchal in state "Call For Adoption By WG Issued"
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: Wed, 11 Sep 2019 15:01:23 -0000

On Wed, Sep 11, 2019 at 07:42:38AM -0700, Watson Ladd wrote:
> On Wed, Sep 11, 2019 at 12:06 AM Miroslav Lichvar <mlichvar@redhat.com> wrote:
> > If I understand it correctly, Roughtime could be specified as an NTP
> > extension field, possibly as an extension to NTS. So, I think the
> > document should explain why a new protocol using a different transport
> > was needed. I guess one reason could be that Roughtime is easier to
> > implement than NTP, especially in some specific frameworks.
> 
> The signing negatively affects the possible timing accuracy

I think with the interleaved mode that wouldn't have to be the case,
but even if it was, why would it matter? It wouldn't be worse than
what is currently specified, right?

> and you
> need to track things differently on the server.

Meaning it would be more difficult to add the support to an NTP server
than implement it as a separate service?

> What are the benefits from adding it as an extension?

The "proof of malfeasance" could cover the timestamps that the client
is using to synchronize the clock. I'm not sure if there is any value
in that.

-- 
Miroslav Lichvar

v2.23.0 | Report a Bug | By Email