Re: [Ntp] Robert Wilton's Discuss on draft-ietf-ntp-interleaved-modes-05: (with DISCUSS and COMMENT)

Miroslav Lichvar <mlichvar@redhat.com> Tue, 29 June 2021 10:17 UTC

Return-Path: <mlichvar@redhat.com>
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 EC8823A2D51 for <ntp@ietfa.amsl.com>; Tue, 29 Jun 2021 03:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.996
X-Spam-Level:
X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
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 XeqPHETuQKb6 for <ntp@ietfa.amsl.com>; Tue, 29 Jun 2021 03:17:54 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (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 0F8D53A2E6F for <ntp@ietf.org>; Tue, 29 Jun 2021 03:17:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1624961873; 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=vi2k3NSy99iFQP1yOJQk6PhZvAQhKs1rnYuAjz90Q6I=; b=IrvgePjq5cMOkaXHu7VRlXA1m7JAUYA0nkLUgf9WnwEMRJo753d2x5GQwxGi6mLtbSsZyR 8ICShl29xN8D1ypo1pDfNxJDtmgb3ctHt1aVn9/nDTPHTwxwfznna1UYyS3H1u4RZdhDoW VICMARym35E5DDdgt763YtPq9qlEmuc=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-229-fwTQet68M7GuWVpVFKn5Vw-1; Tue, 29 Jun 2021 06:17:51 -0400
X-MC-Unique: fwTQet68M7GuWVpVFKn5Vw-1
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1D2D319057A8; Tue, 29 Jun 2021 10:17:50 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BA3715D6AD; Tue, 29 Jun 2021 10:17:48 +0000 (UTC)
Date: Tue, 29 Jun 2021 12:17:47 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-ntp-interleaved-modes@ietf.org" <draft-ietf-ntp-interleaved-modes@ietf.org>, "ntp-chairs@ietf.org" <ntp-chairs@ietf.org>, "ntp@ietf.org" <ntp@ietf.org>, "odonoghue@isoc.org" <odonoghue@isoc.org>
Message-ID: <YNrzSy0jtuY65IPn@localhost>
References: <162489575248.15557.5659898954890340208@ietfa.amsl.com> <YNrfb6JIcfEa25pb@localhost> <DM4PR11MB5438A23994F586634481EF37B5029@DM4PR11MB5438.namprd11.prod.outlook.com>
MIME-Version: 1.0
In-Reply-To: <DM4PR11MB5438A23994F586634481EF37B5029@DM4PR11MB5438.namprd11.prod.outlook.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlichvar@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/lOFgq6imed7rnPgW5GcschgCr68>
Subject: Re: [Ntp] Robert Wilton's Discuss on draft-ietf-ntp-interleaved-modes-05: (with DISCUSS and COMMENT)
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: Tue, 29 Jun 2021 10:17:59 -0000

On Tue, Jun 29, 2021 at 09:44:35AM +0000, Rob Wilton (rwilton) wrote:
> > That's a good point. The problem is that there is no good way to
> > negotiate it. Some widely-used server implementations drop requests
> > with unknown extension fields. From a missing response the client
> > cannot tell if the server doesn't support it, or if it's under heavy
> > load or there is a packet loss in the network somewhere.
> 
> That makes it sound like the NTPv4 extension mechanism is just broken.  I.e., nobody can define new extensions in practice?

Yes, that's one of the problems we are trying to fix in NTPv5.

NTPv4 practically has only Autokey and NTS as extensions. They are
both authentication mechanisms, so there is no point in negotiating
the extension, e.g. to fall back to unauthenticated NTP. Also, NTS has
a separate protocol for key establishment (NTS-KE). If there is a
misconfigured client trying to use a server that does not support it,
at least there should be a "Could not connect" error message.

> But it isn't clear to me how processing this as a bogus packet helps (noting that I don't know NTP).

A client request is never bogus. Only server response can be bogus,
for a client that doesn't support the interleaved mode, if it somehow
managed to form a request that from the server's point of view looks
like interleaved. This doesn't happen in practice as far as I can
tell.

> E.g., looking at figure 1 in section 2, then what would the flow look like between a client that supports interleaved mode and a server that doesn't know this extension at all?
> 
> I presume that the first 2 packets (client (B) -> server, server(B) -> client) would just be regular basic NTP.
> At this stage, wouldn't the client now send an I mode packet to the server?  Wouldn't the server treat this as a bogus packet, drop it, and not reply?  Or does the server still reply regardless in this scenario? 

A server is always expected to respond (except rate limiting, etc). If
it doesn't support the interleaved mode, or has the support disabled,
it doesn't care in what mode the request it is and always responds in
the basic mode. Clients are required to accept it, even if they are
sending interleaved requests.

Thanks,

-- 
Miroslav Lichvar