IETF Logo Mail Archive

[Ntp] Re: Grease in Roughtime

kristof.teichel@ptb.de Tue, 24 September 2024 07:46 UTC

Return-Path: <kristof.teichel@ptb.de>
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 B14BFC169421 for <ntp@ietfa.amsl.com>; Tue, 24 Sep 2024 00:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.405
X-Spam-Level:
X-Spam-Status: No, score=-4.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ptb.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2FQAQBWvZLy for <ntp@ietfa.amsl.com>; Tue, 24 Sep 2024 00:46:30 -0700 (PDT)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AA1DC151993 for <ntp@ietf.org>; Tue, 24 Sep 2024 00:46:28 -0700 (PDT)
Received: from s23397.bs.ptb.de ([172.21.101.132]) by mx1.bs.ptb.de with ESMTP id 48O7kO60022473-48O7kO62022473 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK); Tue, 24 Sep 2024 09:46:24 +0200
In-Reply-To: <55dedf3b-04f7-4efe-bb8a-6aee9554e011@dansarie.se>
References: <CAPz_-SUY9egByeG+cSHXFqbc6XzRmkpCF7Y4QS2ud0LmOjccAA@mail.gmail.com> <55dedf3b-04f7-4efe-bb8a-6aee9554e011@dansarie.se>
To: Marcus Dansarie <marcus@dansarie.se>
MIME-Version: 1.0
From: kristof.teichel@ptb.de
Message-ID: <OF4F731B07.08990379-ONC1258BA2.0029CC70-C1258BA2.002AB2EE@ptb.de>
Date: Tue, 24 Sep 2024 09:46:23 +0200
Content-Type: multipart/alternative; boundary="=_alternative 002AB2EEC1258BA2_="
X-FEAS-Client-IP: 172.21.101.132
X-FE-Policy-ID: 5:5:5:SYSTEM
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=ptb.de; s=s1-ptbde; c=relaxed/relaxed; h=references:to:cc:mime-version:subject:from:message-id:date:content-type; bh=llIsx1zEvouos9wWQclE5uzvGLkFvbTQpnOFgsPrHrE=; b=SvSvuWgfjfY0xz37Ct2RGscc2QaUodikUXUQtConATY8iYQO4cUJ0fAZUY24mbUPS6Kd8AHYpuo5 b6oG9bEko+TCSykFY8FwThPWc9J3JMYa5yOSiHKL4G8wK4EssFBBVNa2Nza9zGOWIGL4p86CoCOn lpN5Xy/NvlwKKluaCtrZ2HE+W4Yxkszrk+KwMdg2CxM0RXNn28SiCR7afeFn6UK2ikQWa4F0sOsk cXGdURFzdFAPLw/+mJbnavwUsZTymHpjP0DuV7puV0J7ToBT1objQkKVemKoZwUQOHtDtga2l1og WAwRf4UYQjw7uDkGxM6EsUppBMXx4IyNsJn06w==
Message-ID-Hash: 6JMH4GHDOZ5HSWVPHXR6ESHT4JKKJD4A
X-Message-ID-Hash: 6JMH4GHDOZ5HSWVPHXR6ESHT4JKKJD4A
X-MailFrom: kristof.teichel@ptb.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ntp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: ntp@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Ntp] Re: Grease in Roughtime
List-Id: Network Time Protocol <ntp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/PgyB8QlC_S9kjwNtO1JIqlW406w>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Owner: <mailto:ntp-owner@ietf.org>
List-Post: <mailto:ntp@ietf.org>
List-Subscribe: <mailto:ntp-join@ietf.org>
List-Unsubscribe: <mailto:ntp-leave@ietf.org>

Hi Marcus,

thanks for doing my pull request and integrating my changes. I should have 
done it earlier, but didn't.

About the GREASE section... can you explain the thinking behind randomly 
sending faulty packets?
a)      How would anyone (other than the client itself) even know whether 
or not the client reacted correctly (discarding a packet with inconsistent 
data or an invalid signature)? 
        I don't think I see who would even evaluate this as a test, much 
less how this could "ensure that clients validate signatures".
        What am I missing here?
b)      Wouldn't it make more sense to send packets with a valid timestamp 
but invalid signature - so that in the case of misbehaviour (accepting the 
time in spite of incorrect signature), nothing terrible would happen?


Besten Gruß / Kind regards,
Kristof Teichel

__________________________________________

Dr.-Ing. Kurt Kristof Teichel
Physikalisch-Technische Bundesanstalt (PTB) 
Arbeitsgruppe 4.42 "Zeitübertragung"
Bundesallee 100
38116 Braunschweig (Germany)
Tel.:        +49 (531) 592-4471
E-Mail:   kristof.teichel@ptb.de
__________________________________________



Von:    "Marcus Dansarie" <marcus@dansarie.se>
An:     ntp@ietf.org
Datum:  23.09.2024 22:49
Betreff:        [Ntp] Re: Grease in Roughtime



Thanks for the comments!

I just made a pull request on Github 
(https://github.com/ietf-wg-ntp/draft-roughtime/pull/4) that should 
clarify how grease is used in Roughtime. It also addresses most of 
Martin and Kristof's comments.

On 2024-09-17 13:52, David Venhoek wrote:
> First of all, regarding the ver tag, there is no requirement for
> servers to ignore unknown versions in that tag. this means that
> technically it is valid behavior right now for a server receiving
> unknown versions to reject that packet, even if there is version
> overlap. This seems highly undesirable

I don't think I fully understand the problem you are describing here 
however. Could you give an example?

Kind regards,
Marcus

_______________________________________________
ntp mailing list -- ntp@ietf.org
To unsubscribe send an email to ntp-leave@ietf.org

v2.29.0 | Report a Bug | By Email | System Status