IETF Logo Mail Archive

Re: [Ntp] Danny's Review (was Re: draft-ietf-ntp-roughtime-05: tag change makes implementation more complex)

Danny Mayer <mayer@pdmconsulting.net> Wed, 29 September 2021 15:12 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 B979D3A1AC2 for <ntp@ietfa.amsl.com>; Wed, 29 Sep 2021 08:12:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, T_SPF_TEMPERROR=0.01] 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 jV80or1i9U-b for <ntp@ietfa.amsl.com>; Wed, 29 Sep 2021 08:12:04 -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 2A9DB3A1AB5 for <ntp@ietf.org>; Wed, 29 Sep 2021 08:12:01 -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) server-digest SHA256) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4HKKbc6ZrWzMNDw; Wed, 29 Sep 2021 15:11:56 +0000 (UTC)
To: "Salz, Rich" <rsalz@akamai.com>, JP Sugarbroad <taralx@gmail.com>
Cc: Watson Ladd <watsonbladd@gmail.com>, NTP WG <ntp@ietf.org>, Marcus Dansarie <marcus@dansarie.se>
References: <CAGZkp1-ZCuSvMyQyWCnE511O8-WL=OXfsTdraKsByMmWC3spVA@mail.gmail.com> <CACsn0ckZmR=k2NAmdyhVOA=V_XQ18AnBUBSTOu+bDXS1YsPpUg@mail.gmail.com> <CAGZkp18eASaF7qvubYpDgzvg643ZXuPwDs9qsiC1P_AVLcywLA@mail.gmail.com> <CACsn0cnjHFwxHT13nMavRFzRteWJ=SORY8v4RCZjdjYP0H3oaw@mail.gmail.com> <7dde7eb3-4dc7-94d3-e63a-6d5d0736b1c2@pdmconsulting.net> <54baf1fa-b138-4eb8-6f4e-99168cf2db7b@dansarie.se> <0a95d35f-f708-4a3c-4ecf-77597c42a7a4@pdmconsulting.net> <CACsn0c=gdQWDumfzeHYYWzXPV4sz4J9mTUtYW+4=KueaHHbGdQ@mail.gmail.com> <79dfd56c-54e8-8b85-ed9d-da9fac71d1f1@pdmconsulting.net> <c95eaafb-f294-a54e-d495-0cf74e574686@pdmconsulting.net> <CACsn0cmks2fdwem1rS+QNzCL1WhNR4890Fi1zpjQrL=E3Y=3fQ@mail.gmail.com> <684af837-0713-9293-168b-8b140bf15d22@pdmconsulting.net> <CAGZkp183CgJJOd5O5dDdeKtAzgCobwBzpZe3ixBWJ-ZLQXB6bg@mail.gmail.com> <edee8b51-47b4-3a33-436e-b235fdcf6b99@pdmconsulting.net> <981D597A-2484-47C9-AA99-F95E6623F51D@akamai.com>
From: Danny Mayer <mayer@pdmconsulting.net>
Message-ID: <aba9eb26-31dd-2a6e-2146-9e271c90a9ab@pdmconsulting.net>
Date: Wed, 29 Sep 2021 11:11:56 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <981D597A-2484-47C9-AA99-F95E6623F51D@akamai.com>
Content-Type: multipart/alternative; boundary="------------B62E3D9B06E937AD910AF89C"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/8aacvghkKQODRbQ4DKPrhJOoM2A>
Subject: Re: [Ntp] Danny's Review (was Re: draft-ietf-ntp-roughtime-05: tag change makes implementation more complex)
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: Wed, 29 Sep 2021 15:12:16 -0000

On 9/28/21 7:13 PM, Salz, Rich wrote:
>
> > There is nothing to prevent me creating a protocol called SMOOTHTIME 
> and throwing the ROUGHTIM value in the header to fool you. How has 
> that made the protocol unambiguous?
>
> And what will happen?  Your protocol will be treated by conformant 
> applications as ROUGHTIM.  Is that what SMOOTHTIM is?
>
> The IETF tries not to have conflicting identifiers, and sometimes IANA 
> is involved.
>
> A protocol header might help here, and seems to cause no harm.
>
Can you point to an existing RFC where the protocol name is in the 
header? Is there something useful about it that the security folks think 
it would be a good addition? Any other references to make sense of this?

Danny

v2.23.0 | Report a Bug | By Email