IETF Logo Mail Archive

[Ntp] Re: [EXT] Re: Alternate mechanism for kiss of death messages.

"Windl, Ulrich" <u.windl@ukr.de> Wed, 19 June 2024 08:00 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 13384C151076 for <ntp@ietfa.amsl.com>; Wed, 19 Jun 2024 01:00:05 -0700 (PDT)
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=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 Uv1ESgyY7AgA for <ntp@ietfa.amsl.com>; Wed, 19 Jun 2024 01:00:01 -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 B11BAC15108B for <ntp@ietf.org>; Wed, 19 Jun 2024 00:59:58 -0700 (PDT)
X-CSE-ConnectionGUID: IOS/lDdRRi2a12njcoA9LQ==
X-CSE-MsgGUID: UFpQ9kNZQFSg+iB8+ZZWzA==
X-ThreatScanner-Verdict: Negative
X-IronPort-AV: E=McAfee;i="6700,10204,11107"; a="857268"
X-IronPort-AV: E=Sophos;i="6.08,249,1712613600"; d="scan'208";a="857268"
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; 19 Jun 2024 09:59:56 +0200
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.39; Wed, 19 Jun 2024 09:59:55 +0200
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.039; Wed, 19 Jun 2024 09:59:55 +0200
From: "Windl, Ulrich" <u.windl@ukr.de>
To: Miroslav Lichvar <mlichvar@redhat.com>, Paul Gear <ntp=40libertysys.com.au@dmarc.ietf.org>
Thread-Topic: [EXT] [Ntp] Re: Alternate mechanism for kiss of death messages.
Thread-Index: AQHauzqqWb5lJBlRr0aZ3uCj0bjByLHFH+uAgALDnQCAA6drAIADO0zQ
Date: Wed, 19 Jun 2024 07:59:55 +0000
Message-ID: <ab53a0ee2bca41e3b710876533ed739a@ukr.de>
References: <CAPz_-SWrOJbyw-wQeLsTcfjVJWT3iEHubcVjW9__Yz9RPMAPpQ@mail.gmail.com> <ZmcAIJSBdTw3mjMC@localhost> <CAPz_-SX5y6vTEJM5f9hj1GcTk3sZFWpCPt0VScYqw1C4ndLoKA@mail.gmail.com> <c0b6e511-9b61-40b1-916d-e58abe8e908e@libertysys.com.au> <Zm_1lgO038Vtyswn@localhost>
In-Reply-To: <Zm_1lgO038Vtyswn@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.2]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Message-ID-Hash: ZVTR47DE5CHSIKRLTWBOD6LK652IAORC
X-Message-ID-Hash: ZVTR47DE5CHSIKRLTWBOD6LK652IAORC
X-MailFrom: u.windl@ukr.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" <ntp@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Ntp] Re: [EXT] Re: Alternate mechanism for kiss of death messages.
List-Id: Network Time Protocol <ntp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/7CDrpdWpoA1Cvy15t4RM6OP0Jzk>
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>

In the reference implementation you could disable KoDs; maybe some paranoid operators thought KoDs are dangerous.
Also many installations do not use authentication, and non-authentic KoDs could be dangerous, actually.

-----Original Message-----
From: Miroslav Lichvar <mlichvar@redhat.com> 
Sent: Monday, June 17, 2024 10:37 AM
To: Paul Gear <ntp=40libertysys.com.au@dmarc.ietf.org>
Cc: ntp@ietf.org
Subject: [EXT] [Ntp] Re: Alternate mechanism for kiss of death messages.

On Sat, Jun 15, 2024 at 10:48:38AM +1000, Paul Gear wrote:
> I have a question, though: Where is the value in specifying an alternate
> mechanism?  The method currently described in
> https://datatracker.ietf.org/doc/html/rfc5905#section-7.4 is very
> straightforward and has been in place for a long time.  Adding an alternate
> mechanism would require compliant implementations to perform two checks
> instead of one.  Admittedly this is not a high bar, but it provides
> opportunity for variance in behaviour that suggests against its inclusion in
> NTPv5.  I think we should be aiming to reduce the number of alternate
> mechanisms rather than increase them.

The trouble with the NTPv4 KoD mechanism is that almost nothing
implemented it. The reference ID, where the KoD code was stored, is
now replaced in NTPv5 with a set of reference IDs using the bloom
filter. If the KoD values were included in the bloom filter, I think
even fewer implementations would bother to check them.

The poll value was already used for negotiating polling interval
in NTPv4. It was required for symmetric mode. NTPv5 just clarifies and
extends on that.

An advantage is that a response having a large poll value, indicating
to client to reduce its polling rate, can be still used for
synchronization. Some clients don't like a KoD RATE response and
immediately send another request, an exact opposite of the expected
behavior.

-- 
Miroslav Lichvar

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

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