Re: [Ntp] [tsvwg] [Tsv-art] Tsvart early review of draft-ietf-ntp-alternative-port-02

Hal Murray <halmurray@sonic.net> Thu, 09 December 2021 08:46 UTC

Return-Path: <halmurray@sonic.net>
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 A5E403A0766; Thu, 9 Dec 2021 00:46:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eAs0CZbH2pH; Thu, 9 Dec 2021 00:46:37 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8592E3A0112; Thu, 9 Dec 2021 00:46:37 -0800 (PST)
Received: from 107-137-68-211.lightspeed.sntcca.sbcglobal.net (107-137-68-211.lightspeed.sntcca.sbcglobal.net [107.137.68.211]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id 1B98kWP2009008 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 9 Dec 2021 00:46:35 -0800
Received: from hgm (localhost [IPv6:::1]) by 107-137-68-211.lightspeed.sntcca.sbcglobal.net (Postfix) with ESMTP id CCEF528C1BF; Thu, 9 Dec 2021 00:46:31 -0800 (PST)
To: Eliot Lear <lear@lear.ch>
cc: "touch@strayalpha.com" <touch@strayalpha.com>, Steven Sommars <stevesommarsntp@gmail.com>, NTP WG <ntp@ietf.org>, TSVWG <tsvwg@ietf.org>, Harlan Stenn <stenn@nwtime.org>, Danny Mayer <mayer@pdmconsulting.net>, Miroslav Lichvar <mlichvar@redhat.com>, tsv-art <tsv-art@ietf.org>, Hal Murray <halmurray@sonic.net>
From: Hal Murray <halmurray@sonic.net>
In-Reply-To: Message from Eliot Lear <lear@lear.ch> of "Thu, 09 Dec 2021 08:51:41 +0100." <159160c7-e595-349f-aff9-35cc60b02413@lear.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <135758.1639039591.1@hgm>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 09 Dec 2021 00:46:31 -0800
Message-Id: <20211209084631.CCEF528C1BF@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
X-Sonic-CAuth: UmFuZG9tSVbfVjoQgGuK0pwZ4iFFW4xBaIGdDnM/7AY6FxxUGEnJ5hSHxbjUnxL2/6WTayrK/lqCDD0ntLOmE/3aWyYhmCySm+KtblWQbRI=
X-Sonic-ID: C;QNGjgsxY7BG+muSrSr5vsA== M;ukP3g8xY7BG+muSrSr5vsA==
X-Sonic-Spam-Details: -1.5/5.0 by cerberusd
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/s37qMM5qjdtL5XbvCQS-Gb2V6OU>
Subject: Re: [Ntp] [tsvwg] [Tsv-art] Tsvart early review of draft-ietf-ntp-alternative-port-02
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 09 Dec 2021 08:46:39 -0000

> Miroslav, one question I would like to understand is whether those drops
> involve typical packets used to sync clocks or if those are control
> packets.  In other words, are clocks not syncing because of the drops?

It depends.  There is no standardization on the filters.

My initial description of a simple length check was overly simplified.

Sometimes, basic non-authenticated NTP requests or responses get dropped.
The NTP pool has a monitoring setup.  It polls each server to verify
that it is responding with reasonable values of time.  Sometimes healthy
servers get dropped because the monitoring packets don't get through.
This is not common, but also not rare.

Sometimes, the filters are dropping mode 6 and 7.  If that was the only
type of filter we wouldn't be having this discussion.

Sometimes, the dropping is length dependent in strange ways.  I had one case
where every 4th NTS packet would get through.  When an NTS exchange fails, the
next request is roughly 100 bytes longer.  That's asking for an extra cookie to
replace the one that would have been in the lost packet.  The request for an
extra cookie is the full length of a cookie to avoid amplification.  If 2
packets in a row are dropped, the 3rd request will have 2 extra cookie requests.
The 4th one will have 3.  That worked. :)  Then it started over again with
short packets which didn't work...