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> Tue, 28 September 2021 20:01 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 CC88A3A0EDE for <ntp@ietfa.amsl.com>; Tue, 28 Sep 2021 13:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 9p_BTBYTtyyl for <ntp@ietfa.amsl.com>; Tue, 28 Sep 2021 13:01:41 -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 A5F5F3A0ED7 for <ntp@ietf.org>; Tue, 28 Sep 2021 13:01:37 -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 4HJr4F1jBLzMNXj; Tue, 28 Sep 2021 20:01:33 +0000 (UTC)
To: 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>
From: Danny Mayer <mayer@pdmconsulting.net>
Message-ID: <edee8b51-47b4-3a33-436e-b235fdcf6b99@pdmconsulting.net>
Date: Tue, 28 Sep 2021 16:01:32 -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: <CAGZkp183CgJJOd5O5dDdeKtAzgCobwBzpZe3ixBWJ-ZLQXB6bg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------B380814873F2D10E4637F2BE"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/n5Ho-wsubeoBE4TFigeByDSc9bs>
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: Tue, 28 Sep 2021 20:01:48 -0000

On 9/28/21 12:39 PM, JP Sugarbroad wrote:
> On Tue, Sep 28, 2021, 08:43 Danny Mayer <mayer@pdmconsulting.net 
> <mailto:mayer@pdmconsulting.net>> wrote:
>
>     Get rid of the useless "ROUGHTIM" string in the header and replace
>     it with something useful, including the version number.
>
> I don't think it's useless. We've seen a number of "tunneling" and 
> "punning" attacks where one protocol is mistaken for another. Having a 
> protocol unambiguously self-identify is useful.
>
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? That doesn't prevent tunneling, and yes I'm 
familiar with this idea and I've seen the implementations. The only 
proper way to handle this is deep packet inspection and fingerprinting. 
Nothing else really works.

Danny

v2.23.0 | Report a Bug | By Email