Re: [Ntp] Publication has been requested for draft-ietf-ntp-using-nts-for-ntp-20

Miroslav Lichvar <mlichvar@redhat.com> Thu, 14 November 2019 10:39 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 C45C51207FE for <ntp@ietfa.amsl.com>; Thu, 14 Nov 2019 02:39:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 2MD3Dtr3k47G for <ntp@ietfa.amsl.com>; Thu, 14 Nov 2019 02:39:23 -0800 (PST)
Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B083120857 for <ntp@ietf.org>; Thu, 14 Nov 2019 02:39:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573727962; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=INzRZgt31hoiX6rWR6xVvA7vpv/U5rb4oNBREddgwME=; b=IRlzGDasbjHPy5y3Sc+RrKkzgxCY0EU0V1KWUlhSD/UuMUttyXvCcv3R0XslNCmqg+bq62 m/8DLITQtlavrB1XIm5q3MBfpO3uGpw+oUJwGeGN6BBa6b+2QPXe5KS/Bb5HNjk6IhOTJH s7/+d/URboUQR3wX1kq1QioRWTe/WOc=
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-326-eJ0d_WinO6etiTowkM91VA-1; Thu, 14 Nov 2019 05:39:19 -0500
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C096D8C5EE8 for <ntp@ietf.org>; Thu, 14 Nov 2019 10:39:18 +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 48AA660303 for <ntp@ietf.org>; Thu, 14 Nov 2019 10:39:17 +0000 (UTC)
Date: Thu, 14 Nov 2019 11:39:15 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: ntp@ietf.org
Message-ID: <20191114103915.GG2634@localhost>
References: <mlichvar@redhat.com> <20191113160710.GD2634@localhost> <20191114093853.2DF2D406063@ip-64-139-1-69.sjc.megapath.net>
MIME-Version: 1.0
In-Reply-To: <20191114093853.2DF2D406063@ip-64-139-1-69.sjc.megapath.net>
User-Agent: Mutt/1.12.1 (2019-06-15)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-MC-Unique: eJ0d_WinO6etiTowkM91VA-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/5J-zlGmCmK6fWZkuJdRZ7XwpoCk>
Subject: Re: [Ntp] Publication has been requested for draft-ietf-ntp-using-nts-for-ntp-20
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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, 14 Nov 2019 10:39:27 -0000

On Thu, Nov 14, 2019 at 01:38:53AM -0800, Hal Murray wrote:
> 
> mlichvar@redhat.com said:
> >    with a list of one or more IP addresses to NTP servers for which the
> > cookies
> 
> > Is it wrong to interpret a FQDN as a list of addresses? 
> 
> Good question.
> 
> I vote we add something like "use only one address, but the client gets to 
> pick which one".

I think it should prefer the address family (IPv4/IPv6) it used to
connect NTS-KE. Wasn't that the original reason for allowing hostnames
in the NTS-KE record, that some servers behind NAT may not know the
address of the client and cannot respond with the corresponding
address?

Should multiple addresses per IPv4/IPv6 be expected and what does that
mean? Are they different addresses of the same server, or different
servers? There is only one "Server Negotiation" record allowed in the
NTS-KE response, so I think that suggests it's supposed to be only one
server.

Another question is what should happen when a client runs out of
cookies, starts a new NTS-KE exchange, and gets a different address or
hostname than before. Is it ok to continue using the old address for
as long as it responds?

> Our code processes the list in order, using the first one that isn't already 
> in use.  Thus
>   server foo.example.com nts
>   server foo.example.com nts
> Will get 2 connnections to the same server in the typical case where the 
> server has both an IPv4 address and a IPv6 address.

I guess if you specified the same server twice, you would expect to
have two associations with that server.

What about "pool"? Does it create multiple associations if the
negotiated "hostname" resolved to multiple addresses?

In my implementation I'm currently going with the "single server"
interpretation and won't be using multiple addresses.

-- 
Miroslav Lichvar