[Ntp] NTPv5 extension field format
David Venhoek <david@venhoek.nl> Wed, 01 November 2023 13:23 UTC
Return-Path: <david@venhoek.nl>
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 E4DCBC1519BE for <ntp@ietfa.amsl.com>; Wed, 1 Nov 2023 06:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venhoek-nl.20230601.gappssmtp.com
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 7GSUWdwo1w_l for <ntp@ietfa.amsl.com>; Wed, 1 Nov 2023 06:23:57 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E66C1519B1 for <ntp@ietf.org>; Wed, 1 Nov 2023 06:23:55 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-53e70b0a218so10995245a12.2 for <ntp@ietf.org>; Wed, 01 Nov 2023 06:23:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venhoek-nl.20230601.gappssmtp.com; s=20230601; t=1698845034; x=1699449834; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=teWyNOTVnE+S/z6XaEfaWOIo91tWD+UkWDXh6pU3JIE=; b=LcuUcSDyIFaggbI6mBvGGFT3Yi3fz36seoG03dJ+PGWRB3lxeQAFRdJpG+ApWcILrE DOqpCglGWMtrcbezxVB8c6c5r/sXNMUiwDdraEUE6PFK/tDglLBgLHfW7OTXbG2NVeEB VCjK4z9hgT+8U0LsByrdqMHvlsusS83R7oBIKj7KoO+lK4LFwdnfKYJBqlMiwxKVgHM7 qpzpY/K10mdFwd7wBC3JJ3i/z1mSLy9JTOHGz5P/pqN/m1jUe9SQ5oehX5iG82DLL3Qe TECUCUVy12ly/m6igQZogTdm/FrOls5uvGtrDuSea421k91HP7YRt2SXlOJYhYuW/dh/ 9GxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698845034; x=1699449834; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=teWyNOTVnE+S/z6XaEfaWOIo91tWD+UkWDXh6pU3JIE=; b=TW7HcFWztazOYjwSnrK/VAchacTRQytRKyJg4wV7QJzMgIXF7+kpMOjugghV4ZSUKc clsXbUbwCrz90g681AgI9VQ7eOCDUsjjL3q32K7Mn+h/wNFf44NgFr22hIdSN/o/Mxka kOfc9Yfb05i+Nd0cSKdF1yjRz3OcHAmxI/tUOPp+jJmjQA2eaOWiF880CqdDdhW1qIw0 uTXVMid2hLWEUx0rsQdVrmZ4N3TqIvCeuZEUgiuNicX3rV4Q6986NBwBgfYQ1hVjBzpX mz7HZph5d2q6bQFR/uj7VogmMOCbjpQYXZoOkN0Q9nNkIpPy0DeobytDhHtAnw+q9l13 iNSA==
X-Gm-Message-State: AOJu0YyxLzVmKabfN7Lymhs0ft2hzlmgrzApt0t0J5ACYPAbBVjkzT1L u1zkrGSQ+AvsyBLd69zv+CYZrFrzASkBG7IQABTl8hqceXPjLZPrJWY=
X-Google-Smtp-Source: AGHT+IHNSCv3LpcJBK9BswcaVI1xBknjktB7IBKncGYqMC2DKEFLSFjxo+p+AQyxtW2aVbJcaYR+5LkyfzUJTcfI7GU=
X-Received: by 2002:a17:906:eec3:b0:9b2:b153:925 with SMTP id wu3-20020a170906eec300b009b2b1530925mr1712134ejb.21.1698845033986; Wed, 01 Nov 2023 06:23:53 -0700 (PDT)
MIME-Version: 1.0
From: David Venhoek <david@venhoek.nl>
Date: Wed, 01 Nov 2023 14:23:43 +0100
Message-ID: <CAPz_-SWnYFCnuj3MNnWFGRrFp-03Cm_d195Qm8pLJST2ku-Jkg@mail.gmail.com>
To: NTP WG <ntp@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/2tGdUu7743TWEE7WpQTYTMQ0gyE>
Subject: [Ntp] NTPv5 extension field format
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
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, 01 Nov 2023 13:23:58 -0000
Dear All, After having implemented NTPv5 in ntpd-rs, I want to again bring for consideration whether we should not just simply keep the NTPv4 extension field format rather than changing it for NTPv5. The reason is that it turns out to be rather annoying to support both the NTPv4 and v5 extension field formats at the same time, and I rather have just a single variant of that code to reduce the chance of bugs in it. I know I have suggested this before, and that it looked not possible without additional length fields at least on some of the extension fields. However, I think we can do it without needing any more bytes on the line more than in the current situation. Looking at all the extension fields in the current spec I find that there are only 4 extension fields where the size is even variable in a way that is not a-priori known to the receiver: - The draft ID, which can be solved by simply requireing the padding be 0 and instructing receivers to ignore any trailing 0 bytes. - The MAC extension field, but here the receiver knows the length it should have once it has determined the key (which it can do based on the first 4 data bytes). - The Reference ID Response: Here we could just pad with further bytes from the bloom filter, and only switch to 0's once those run out. Knowing the offset, the client then always knows which section is valid (since the total bloom filter size is fixed). - Finally, for reference ID requests we can simply just assume that no padding was done on receive and return sufficient bytes for a larger request. (Note that this interpretation actually makes the padding of ref ID response moot, we will always get a request with length a multiple of 4). If there is at least some interest in this I can make a suggestion for how to change the text of the current draft for this. Kind regards, David Venhoek
- [Ntp] NTPv5 extension field format David Venhoek
- Re: [Ntp] NTPv5 extension field format Salz, Rich
- Re: [Ntp] NTPv5 extension field format Miroslav Lichvar