Re: [Ntp] Quick review of WGLC for status change for draft-ietf-ntp-update-registries

Heiko Gerstung <heiko.gerstung@meinberg.de> Tue, 16 August 2022 06:31 UTC

Return-Path: <heiko.gerstung@meinberg.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 1F19EC14CF0B for <ntp@ietfa.amsl.com>; Mon, 15 Aug 2022 23:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=meinberg.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 NKcFhQf9hjoM for <ntp@ietfa.amsl.com>; Mon, 15 Aug 2022 23:31:10 -0700 (PDT)
Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96AE3C14CE24 for <ntp@ietf.org>; Mon, 15 Aug 2022 23:31:04 -0700 (PDT)
Received: from seppmail.py.meinberg.de (unknown [193.158.22.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id D06C671C0349; Tue, 16 Aug 2022 08:31:00 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=d2021; t=1660631460; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HYIqdwnKPOWM5TW78VIH4CF6Jg2zjq6b4vbYJZTK7qM=; b=mINKfnPyeUehAbV9Qced5FT0EG1P5M6KVhhviA5jiHzeiAAO77C2y4jn2XcD1WlSh9gDV4 UiMfQ6SqZmTiz9VCBtK/DxMvlh8lxds3rb/i0sd21bMk9QZLWYtz4krATbKCyxvMkavU+e WGVgC2VvX6xeFmarx4WLSQHy8lbYDM8PbZ5x9guEp88kqpngTDIsV2Ojamaja/Hqr636ny lchKKMZj1byJq6BCYqPE6a07DMInSR/qEn9TdICG4zB0/cQPqoqfSwK16ZiVAH3CwNT5eK ZNCMJItCteJtpQuZKd026N000xZTCNLUPJ1KJ2pAwGFNgGxJ0AwDhWlkcMYHFQ==
Received: from srv-kerioconnect.py.meinberg.de (srv-kerioconnect.py.meinberg.de [172.16.3.65]) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by seppmail.py.meinberg.de (Postfix) with ESMTPS; Tue, 16 Aug 2022 08:31:00 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.63.22070801
Date: Tue, 16 Aug 2022 08:30:57 +0200
Message-ID: <83E424AA-F0B8-48C0-B05A-33296EA5A6D9@meinberg.de>
Thread-Topic: [Ntp] Quick review of WGLC for status change for draft-ietf-ntp-update-registries
References: <0b57b7db-772e-f5e6-e6a0-a433673f3d77@nwtime.org> <YvED7T5R0UsRWbv3@localhost> <b64c6a0a-ea2e-0a19-4bb9-38bfaa2e5032@nwtime.org> <656D355F-E06A-4005-B9D6-90885FA8509D@akamai.com> <1a4bae28-f0f3-e675-899a-bad597b4ee29@nwtime.org> <F74A7B5B-3D77-42AF-BD7E-1A874CCD2D66@akamai.com> <67545c9a-3291-bbe6-c876-4c762c80c710@nwtime.org> <FF22AEFE-ED61-405E-AB40-B7901D0CD588@meinberg.de> <f79cecd6-92b0-595b-e449-6b6f8944ae66@nwtime.org> <133C5633-E4D5-42AF-8215-E3FDE28C5BF9@meinberg.de> <Yvon8eNc4hlI4LbG@localhost>
In-Reply-To: <Yvon8eNc4hlI4LbG@localhost>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+MGYyODEyMGVhZmM2ZTY1NQ==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: Miroslav Lichvar <mlichvar@redhat.com>, Heiko Gerstung <heiko.gerstung=40meinberg.de@dmarc.ietf.org>
Cc: Harlan Stenn <stenn@nwtime.org>, "ntp@ietf.org" <ntp@ietf.org>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----31D89F6F00849E59C8380ADAD15E49AA"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/pB0fOVIbcJbgrPMC2en4VRZVMa4>
Subject: Re: [Ntp] Quick review of WGLC for status change for draft-ietf-ntp-update-registries
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: Tue, 16 Aug 2022 06:31:15 -0000

Hi Miroslav,

OK, maybe we should not redefine this for V5 then - although I would expect that not too many implementations are using mode 7 packets anyway.

One situation we have to take care of IMHO is an NTPv2/v3/v4 client trying to use a V5 server. Maybe it would be better to just state that a V5 only implementation must not respond to V2,V3,V4 requests. If it chooses to support those older protocol versions, it has to respond with the correct (requested) packet format. 

The second problem is an NTP V5 client sending a request to a V2/V3/V4 server. It would be possible to send a V5 NTP request in a V4 compatible format here (as a probe) and if we receive a response indicating that V5 is not supported (as far as I understood, ntpd would for example send a V4 response, others might choose not to respond at all), we can go away and look for a V5 supporting server. 

I would not have too many concerns regarding the firewalls, as a lot of them are not using this kind of deep packet inspection approach to blocking NTP traffic (and those who do would probably be the better maintained ones where there is at least reason for hope that the configuration will be adjusted to look at both NTP VN and Mode). Firewalls might be a problem anyway, as they tend to look at NTP packet lengths and therefore might end up blocking V5 traffic if we manage to increase the packet size to exceed the firewall's limit for an NTP packet). 

Regards,
  Heiko



--
Heiko Gerstung | Managing Director
T: +49 (0)5281 9309-404 | LinkedIn Profile <https://www.linkedin.com/in/heikogerstung/> | Twitter <https://twitter.com/hgerstung>
heiko.gerstung@meinberg.de

MEINBERG® The Synchronization Experts
 
Meinberg Funkuhren GmbH & Co. KG
Lange Wand 9 | 31812 Bad Pyrmont | Germany
Web: http://www.meinberg.de | http://www.meinbergglobal.com | LinkedIn  <https://www.linkedin.com/company/meinberg-funkuhren-gmbh-&-co--kg>

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung

Do not miss our Time Synchronization Blog:
http://blog.meinbergglobal.com
 
 

Am 15.08.22, 13:03 schrieb "ntp im Auftrag von Miroslav Lichvar" <ntp-bounces@ietf.org im Auftrag von mlichvar@redhat.com>:

    On Mon, Aug 15, 2022 at 12:58:17PM +0200, Heiko Gerstung wrote:
    > thanks for the quick response. As far as I can see, mode 7 is "reserved" in the current version of the RFC for NTP, or did I miss an errata?

    The RFC says "reserved for private use".

    Another thing to consider is that mode 7 might be blocked in firewalls
    for all NTP versions to prevent amplification attacks exploiting the
    ntpd private protocol (aka ntpdc).

    -- 
    Miroslav Lichvar

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