IETF Logo Mail Archive

Re: [Ntp] [EXT] Re: NTPv5 KISS code support

"Windl, Ulrich" <u.windl@ukr.de> Fri, 03 November 2023 06:47 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 21BB5C16F3FC for <ntp@ietfa.amsl.com>; Thu, 2 Nov 2023 23:47:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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
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 m_53XAQ1el7i for <ntp@ietfa.amsl.com>; Thu, 2 Nov 2023 23:47:22 -0700 (PDT)
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 C0E3BC15C2A5 for <ntp@ietf.org>; Thu, 2 Nov 2023 23:47:21 -0700 (PDT)
X-CSE-ConnectionGUID: A1RVPga3TPGZ7vpEWNWlLQ==
X-CSE-MsgGUID: X6tv3Qy/SqeBvs3RQS7mWg==
X-ThreatScanner-Verdict: Negative
X-IronPort-AV: E=McAfee;i="6600,9927,10882"; a="438935"
X-IronPort-AV: E=Sophos;i="6.03,273,1694728800"; d="scan'208";a="438935"
Received: from unknown (HELO ukr-excmb01.ukr.local) ([172.24.6.61]) by dmz-infcsg01.ukr.dmz with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Nov 2023 07:47:18 +0100
Received: from ukr-excmb03.ukr.local (172.24.6.63) by ukr-excmb01.ukr.local (172.24.6.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.34; Fri, 3 Nov 2023 07:47:18 +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; Fri, 3 Nov 2023 07:47:18 +0100
From: "Windl, Ulrich" <u.windl@ukr.de>
To: Miroslav Lichvar <mlichvar@redhat.com>, David Venhoek <david@venhoek.nl>
CC: NTP WG <ntp@ietf.org>
Thread-Topic: [EXT] Re: [Ntp] NTPv5 KISS code support
Thread-Index: AQHaDWyNsw8tqUih0kePjwpr0l4st7BoJ2xA
Date: Fri, 03 Nov 2023 06:47:18 +0000
Message-ID: <960aba9f833b4461863ea165df632ea5@ukr.de>
References: <CAPz_-SWRUTB2wQeLg5wS_c34D-7R-Ngcek13rzknyiGf9iG-tA@mail.gmail.com> <ZUNnqmnEVDx1538O@localhost>
In-Reply-To: <ZUNnqmnEVDx1538O@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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/btr17oDq6uWWOfNItbggMufDYXc>
Subject: Re: [Ntp] [EXT] Re: NTPv5 KISS code support
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: Fri, 03 Nov 2023 06:47:26 -0000

Hi!

So you are saying the KoD (Kiss of Death) as it is specified now is broken by design?
I see two possibilities:
1) Drop the concept for NTPv5
2) Improve the concept for NTPv5
Basically I think KoD is a good idea to inform the client about an issue the server sees, be it technical or political (policy).

Kind Regards,
Ulrich Windl

-----Original Message-----
From: ntp <ntp-bounces@ietf.org> On Behalf Of Miroslav Lichvar
Sent: Thursday, November 2, 2023 10:11 AM
To: David Venhoek <david@venhoek.nl>
Cc: NTP WG <ntp@ietf.org>
Subject: [EXT] Re: [Ntp] NTPv5 KISS code support

On Wed, Nov 01, 2023 at 03:37:44PM +0100, David Venhoek wrote:
> Hi All,
> 
> I have made a pull request with suggested wording for including kiss
> code support in ntpv5. The PR can be found
> athttps://github.com/mlichvar/draft-ntp-ntpv5/pull/9, the suggested
> patch is also included below for completeness. Please do share any
> feedback regarding the chosen design, this looked good to me but there
> may be better approaches.

This looks similar to the description of DENY, RSTR, RATE codes in RFC
5905.

One problem is that it's a security issue, a denial of service for the
client. A single spoofed response shouldn't be able to completely break
synchronization with a server. There needs to be some maximum poll
value specificied for RATE and some interval specified for RSTR and
DENY. With that, I would ask how is it better than what we already
have with the suggested poll interval returned in a normal server
response.

The other issue is the most buggy clients that would need this
handling are least likely to implement it, at least that's what
we have seen with (S)NTPv4 implementations. With the most severe bugs
that lead to flooding of servers (e.g. in systemd-timesyncd and
Fortigate firewalls for example), handling of these codes wouldn't
make a difference anyway. By the time the client receives a response
from the server, it has already sent another request, so it couldn't
accept it as valid even if it had this functionality implemented.

-- 
Miroslav Lichvar

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

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