IETF Logo Mail Archive

Re: [Ntp] [EXT] Re: I-D Action: draft-ietf-ntp-update-registries-09.txt

"Windl, Ulrich" <u.windl@ukr.de> Mon, 27 November 2023 14:58 UTC

Return-Path: <u.windl@ukr.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 BC1C7C14EB17 for <ntp@ietfa.amsl.com>; Mon, 27 Nov 2023 06:58:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=unavailable autolearn_force=no
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 K-kwMgPCAvli for <ntp@ietfa.amsl.com>; Mon, 27 Nov 2023 06:58:39 -0800 (PST)
Received: from mail01.ukr.de (mail01.ukr.de [193.175.194.181]) (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 72019C151081 for <ntp@ietf.org>; Mon, 27 Nov 2023 06:58:37 -0800 (PST)
X-CSE-ConnectionGUID: W/gms/KzSdiO71sdtzKkOg==
X-CSE-MsgGUID: eOIrmf0ST9OK67fQJKiQaQ==
X-ThreatScanner-Verdict: Negative
X-IronPort-AV: E=McAfee;i="6600,9927,10907"; a="503205"
X-IronPort-AV: E=Sophos;i="6.04,231,1695679200"; d="scan'208";a="503205"
Received: from unknown (HELO ukr-excmb02.ukr.local) ([172.24.6.62]) by dmz-infcsg01.ukr.dmz with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Nov 2023 15:58:34 +0100
Received: from ukr-excmb03.ukr.local (172.24.6.63) by ukr-excmb02.ukr.local (172.24.6.62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.34; Mon, 27 Nov 2023 15:58:33 +0100
Received: from ukr-excmb03.ukr.local ([fe80::1cb4:6e0c:6da4:a8a0]) by ukr-excmb03.ukr.local ([fe80::1cb4:6e0c:6da4:a8a0%4]) with mapi id 15.01.2507.034; Mon, 27 Nov 2023 15:58:33 +0100
From: "Windl, Ulrich" <u.windl@ukr.de>
To: Miroslav Lichvar <mlichvar@redhat.com>, Hal Murray <halmurray@sonic.net>
CC: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, "ntp@ietf.org" <ntp@ietf.org>
Thread-Topic: [EXT] Re: [Ntp] I-D Action: draft-ietf-ntp-update-registries-09.txt
Thread-Index: AQHaINzOp/6LqpoGDkKRcheD+LrvIbCOJIUAgAAc/XA=
Date: Mon, 27 Nov 2023 14:58:33 +0000
Message-ID: <1feb65a66afa45ddab110ad26e2e7b70@ukr.de>
References: <rsalz=40akamai.com@dmarc.ietf.org> <ED05CB35-6EEC-4BE3-9A13-9B8978AA8587@akamai.com> <20231127025215.B19BF28C1C3@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <ZWSjYi2It4s3d2Rm@localhost>
In-Reply-To: <ZWSjYi2It4s3d2Rm@localhost>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.24.3.1]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/YF0UIwGq4EVPYf609eMuF4b5Yes>
Subject: Re: [Ntp] [EXT] Re: I-D Action: draft-ietf-ntp-update-registries-09.txt
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: Mon, 27 Nov 2023 14:58:43 -0000

Hi!

That one implementation is NTPv3? šŸ˜‰
Browsing the text version of RFC 1305 I realized that there are many <$E "escapes" from Ventura Publisher unsubstituted, making it somewhat hard to read:
<$Eroman peer.hostkeyid~<<-~as~required>;

Kind regards,
Ulrich

-----Original Message-----
From: ntp <ntp-bounces@ietf.org> On Behalf Of Miroslav Lichvar
Sent: Monday, November 27, 2023 3:11 PM
To: Hal Murray <halmurray@sonic.net>
Cc: Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org>; ntp@ietf.org
Subject: [EXT] Re: [Ntp] I-D Action: draft-ietf-ntp-update-registries-09.txt

On Sun, Nov 26, 2023 at 06:52:15PM -0800, Hal Murray wrote:
> Shared key MACs have a 4 byte key number and 16 or 20 bytes of MAC.  The key 
> number space was shared by autokey and manual assignments.  The manual mode 
> was restricted to the lower 65K.

There is at least one implementation that doesn't support autokey and
can assign symmetric keys in the full 32-bit range following RFC 5905.

> So sites that are not using autokey don't 
> need the at least 28 byte length restriction from RFC 7822 for the last 
> extension.

What extension fields would they use? IIRC everything specified for
NTPv4 has last extension at least 28 octets. I don't like the idea of
site-specific parsing of NTP packets. Think of tcpdump/wireshark.

-- 
Miroslav Lichvar

_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp

v2.23.0 | Report a Bug | By Email