Re: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts

Harlan Stenn <stenn@nwtime.org> Mon, 02 September 2019 12:30 UTC

Return-Path: <stenn@nwtime.org>
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 B7A1C120119 for <ntp@ietfa.amsl.com>; Mon, 2 Sep 2019 05:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 BfBaq9H0j05x for <ntp@ietfa.amsl.com>; Mon, 2 Sep 2019 05:30:10 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (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 13C78120110 for <ntp@ietf.org>; Mon, 2 Sep 2019 05:30:10 -0700 (PDT)
Received: from [10.208.75.157] (75-139-194-196.dhcp.knwc.wa.charter.com [75.139.194.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 46MTvV5tl3zL7Y; Mon, 2 Sep 2019 12:30:46 +0000 (UTC)
To: Heiko Gerstung <heiko.gerstung@meinberg.de>, "ntp@ietf.org" <ntp@ietf.org>
References: <1B4A56E7-16A6-4767-9268-BCF4BEB9A247@isoc.org> <BCA949D7-7D92-43A9-9766-573559A9FC70@meinberg.de> <5D66392D020000A100033273@gwsmtp.uni-regensburg.de> <8F6BAF5F-CC7B-47B9-90FD-BD20D6ABE845@meinberg.de> <20190828103752.GI24761@localhost> <3f4b55ca-02d9-a470-229b-40860866efbf@nwtime.org> <20190828111458.GJ24761@localhost> <e50112dd-f918-1135-74c8-a738ecb70b70@nwtime.org> <55867E75-9813-466B-8E57-0E157DE5AEB9@meinberg.de> <d308b5d4-3d6e-981b-3dfc-9d5938bad78d@rubidium.se> <252618a3-d2fb-d5b1-baa4-72b16ef0f845@nwtime.org> <926287B2-62AD-4653-8726-A117EFC2A8B0@meinberg.de> <aca0fb0a-14b0-42a0-aa55-de5603e76b11@nwtime.org> <B5445640-4B7C-487C-9C16-5D6B8AEEC7D3@meinberg.de>
From: Harlan Stenn <stenn@nwtime.org>
Openpgp: preference=signencrypt
Autocrypt: addr=stenn@nwtime.org; prefer-encrypt=mutual; keydata= mQGNBFI2xmQBDACrPayw18eU4pIwCvKh7k0iMkAV9cvzs49kBppM+xoH+KKj4QWmkKELD39H ngQnT3RkKsTLlwxyLqPdUmeQNAY2M5fsOK+OF6EvwLPK9hbmE3Wx2moX+sbEUxJ2VzFhKSKb OPZALXwk1XxL0qBedz0xHYcDwaSAZZkEFXURv2pDIdrmnoUnq2gdC8GpoFJiXoUaCLSYzzaY ac4Njw7Mue8IqfzRQb70aMjXl/qmsmfmEVAyGXywDdc/ler4XSgiuYOV7Kf69bj9PFZZSMdJ MWgEyZH6lJ0TU5ccR2zp5ZRmWzQQkxJMyH2th7q0Nmz3aX4A0K4yE0Ba9/5Dr7ctpF15BrMF aEo4s5lwI6tUnkgMWo265mMzCz4mAPV/ac0w0OXQg7r9E2r0+dRapnzUlG43D0JLDqDr9uRR L6IrRQqoCWUC75lfmPYQYSlaTJaK68r3lXd0z1cXJUgVtEL5H3/Z71R2B20twcQVAnw2iIH6 L5vdrsIjHrMmkqRVbs9nNyEAEQEAAbQ5SGFybGFuIFN0ZW5uIChOZXR3b3JrIFRpbWUgRm91 bmRhdGlvbikgPHN0ZW5uQG53dGltZS5vcmc+iQG5BBMBAgAjBQJSNsblAhsvBwsJCAcDAgEG FQgCCQoLBBYCAwECHgECF4AACgkQyIwAt1pH+kBlzgv/QOg70vdj8wU/z97UPdlbxtN4THAB gfSX4N0VPKT5fjX1tFhuXZQAOv7wedR3Trh7TGteyg33TBAFf9A42mXZKi1IxAiQG118Hd8I 51rXwnugURIYQaIyQI+vbchRbwVyz+mVLTI/h6FdbsVzT4UFmir+ZMkb/XeZPu0HItk4OZHE 6hk+TuTiCnlqlCPLq371fXV54VOb91WZYD8EQFtK02QHGHsQqWvapdphiDVpYehmsPyiTESq NMKLVtjtyPkQ6S7QF3slSg+2q3j8lyxEA78Yl0MSFNU8B/BtKgzWP2itBOfi+rtUKg+jOY1V /s2uVk2kq2QmHJ/s5k5ldy3qVvoTpxvwBe0+EoBocTHYt+xxp0mTM6YY1xLiQpLznzluqg9z qtejX1gZOF4mgLiBIrhXzed3zsAazhTp5rNb1kn0brZFh6JC5Wk941eilnA4LqX8AWo0lmwo eb+mpwZK/5lNdage/anpVqft9wJ/8EcvST9TLUO4fPrmT3d/0LpWuQGNBFI2xmQBDADXLsBk I7CSa5UXlrNVFJQHER1VxRBKqjWWCh/8Qv9v3p3NrIc2UnhoZ1uWQ2voBGty5Xfy9k4afV5k WwDyRDUIb7PX+Tj4HjVVr7qvnOVe/0KzZpNq0Azd0ggFbsM+8mydktHIwJykW0NUsGwPRYuD OA0Lro0ohb5IiCt3sSQi1X1hYjo7O1Vmn8Gy/XYOnhnMux+5zDPO2yTkCNX5PocYi9IJJy6p Mq1yQV4Y2Dl8KtQzvtq55vCUxx6n0MMzFViGwNW6F4ge9ItO4tDScsgowDrHa208ehwOpv/i wjf93lCClQ6vaKmOBX872K/tdY/hwhxPPjgl1bcrOwMRYVemOPPehwnXH5bwclk1hvDQdkJQ 5pJOkE4VCryTF/iDAt4g2QnHocUwt3b6/ChUUWmj2GZ22OR12rbnCtLedwp0DpViKPUCQHBO vpgXdzE/L9zWar9fqM0EREMgfWbsJc9028qluCcFLIN1gYsq4cC+YGAcOu7HOI5orBBV4m9j XfsAEQEAAYkDPgQYAQIACQUCUjbGZAIbLgGpCRDIjAC3Wkf6QMDdIAQZAQIABgUCUjbGZAAK CRDfCQ/G52/8P/uWDACe7OEM+VETDRqjQgAwzX+RjCVPvtgrqc1SExS0fV7i1mUUxr/B8io3 Y1cRHFoFKmedxf8prHZq316Md5u4egjFdTT6ZqEqkK0hvv+i0pRpCa5EX9VIStcJStomZp8F cY34grA+EOWITaLQ4qNZUP7rf2e7gq1ubQTj7uLr6HZZvMZ5em+IvrOWEuWDI6yOiI6px04w RDfkoR2h6kgdw4V0PT4NjK9WYYKrVCf1bjLlVImNBEcXfvlUTrIYO8y6ptvoUsBQky5pQRvP 99Pn42WfyLy50aII6+vyudD4T0yLjXAz4KteUttxtIte64m/F9/7GEIZAxTUcLyOq/7bP4le h39jBckwc62iYzeK/VkU/bMMh2D68Z3QylMnhhcW27BcgQHPKsHhmFa2SNytYcuQiSdf9+pj 4i32ETz1nJAvYAAqgTF/0PL+8ZNQoEpe/n9woMKrlZrqD4EgFmhQ3bNVhlaXz1nuTZDrwPt1 yMxBuUNbCF4jFnaruwrSiGTRoIfUZQwAjQglahrV4/mcjfnvbNoseHX0PKd9q+wjg7MIjWqr f2CI8Fa6MdanqwYphz43I2yXANKFZuMWsWqyQYlvGuPUlUUcAL3stp24RkzDB1Q+JS0IZJST T2JSu0aTfUdWVNqr2UI19eX+zxbOTckSi3Ng14ezG8ZX194ZH10b8JzntQOwmA20pd5JDhug zQfASER+CZDiPPcQ4mvC4y7rMrfV6XGQbDynC3ekDxo8SC5SvjaczXMwXg6SZ8iFtEWmEwW9 r7zPjjIPDrX8w5LXBgxArM5o/HbERpc2EdAvMh1D7LC0SvmoE7fBKxsicVBe4h6vXjEZ+LLr /wuZiBld9OnxAUIpwptbBspO6WKTQYvgFH2OeDG27hiE5P4Xs4WSp5j9ez8OVB1iZnA2nCQ+ tNTjO8c+C/P92vPLx5+bpGRXTXMNaLh34PS3ZsYoUDkKZNhczRZUWJ7nynSbeeyF+QW7SLwA qY7O7dyk9LFTsfJqRQJ7tWnIAjJPCwmSgQ8Kl0UJ
Message-ID: <d7d3e82d-2c9d-b360-9339-f3527973176d@nwtime.org>
Date: Mon, 2 Sep 2019 05:30:07 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <B5445640-4B7C-487C-9C16-5D6B8AEEC7D3@meinberg.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/EgDfewnsVqyMcgFkxUwsjvIXmvc>
Subject: Re: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
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: Mon, 02 Sep 2019 12:30:13 -0000

Heiko,

On 9/2/2019 4:49 AM, Heiko Gerstung wrote:
> On 02.09.19, 13:30 "ntp im Auftrag von Harlan Stenn" <ntp-bounces@ietf.org im Auftrag von stenn@nwtime.org> wrote:
>         
>     On 9/2/2019 3:59 AM, Heiko Gerstung wrote:
>     > Harlan,
>     > 
>     > I am not sure I understand you correctly. My point was that we can change the base format of an NTP packet because we mark it as version=5. If someone sends a request with version=4, he should get a version=4 response with the v4 packet format. If someone sends a version=5 request, they will get a version=5 response with the new packet format, because the v5 request indicated that the client wants and understands a v5 response.
>     > 
>     > Maybe we both agree on this one here and just misunderstand each other? ;-)
>     
>     People are saying that regardless of the version number in the packet,
>     one should respond with the version the other side offers, with the data
>     that *we* understand.
>     
>     How can that possibly work if you want to make a v5 packet that changes
>     the format and/or content of the base packet?
>     
>     How can a v4 server that gets a v5 packet possibly respond with correct
>     v5 data?
> 
> I did not say that (or at least I did not mean it). I said that a server supporting both v4 and v5 should always respond with a v4 packet if the request is v4 and responds with a v5 packet it the request was v5. If a v4 only server receives a v5 request, it should not respond (or respond with a v4 packet instead). 

I'm saying that if a v3 system gets a v4 (or greater) packet, the v3
system should respond with a v3 packet.

Similary, a v4 system that gets a v5 (or greater) packet, the v4 system
should respond with a v4 packet.

>     > Again, the loop detection algorithm for degree-n-loops would be one benefit from a chain of refids that are passed on from top to down. It would also allow to identify if two or three of my stratum 3 sources get their time from the same stratum 1 source. If we add a flag to the chain that indicates that this InstanceID contributed to the chain using an NTS protected connection, a client could reject any source that is not providing a fully protected chain. Or it prefers a source that can come up with such a chain.
>     
>     How do you propose getting that refid chain "downstream"?
> 
> Using an EF. Adding an EF which says "send me the chain" to a request, triggering the upstream server to send its resonse with an EF attached to it that includes the chain.

In NTPv4?  I'm seeing incredible resistance to offering OPTIONAL EF
proposals (mechanisms) for v4.

I'm seeing people saying they don't see the need for that mechanism
because they want to prevent that as a policy choice for others.

>     We've just spent YEARS doing our best to remove meaning from the refid
>     field to prevent abuse vectors for a single upstream, and now you want a
>     method to clearly identify a chain of upstreams?
> 
> A unique chain of InstanceID's which does not include any IP addresses or host names is not a way of clearly identifying anyone in that chain. 

If you can't map an InstanceID to a system, then how do you detect a loop?

If you *can* map an InstanceID to a system, how do you prevent a bad
actor from abusing that "upstream" system to DoS "downstream" systems?

>     Indeed, for this chain to work one would need to know all the players in
>     the tree between the top of the heap and the "bottom", as  the loop
>     detection would need to know the various possible systems in the middle.
> 
> As far as I can see, you do not need to know anything about the players in the tree. You just get a list of instanceIDs and as long as your own is not included, and there is none appearing twice, you can assume that there is no loop.

I floated an idea for a proposal for this probably 20 years ago, and it
was shot down.

I think it requires negotiation between all connected parties out to
more than degree 2, as one must ensure that *none* of the current group
(which may have connections to members of outside groups) share a common
InstanceID (if I'm using that word correctly).

It means that changes in connectivity will cause ripples of
re-negotiations of the known participants *and likely the chains of
their neighbor groups*.

Please imagine this in the face of the NTP Pool.

This might be less horrible if we set up a registry of InstanceID
chains, but think hard about this - it's not a problem when we can get
time from an authoritative source.

The loop problem is only(?) a possibility if we *lose* access to an
authoritative source.

At least that's my current working premise.

>     When did NTS evolve to provide assertions about the intentions of the
>     "middle players"?
> 
> I did not say anything about intentions. I just stated that it could be useful to verify that the whole chain of clocks talked to each other using NTS. I know that any man-in-the-middle being able to trick its downstream NTS clients into trusting them will be able to fool a client. But that is true in general, i.e. any MITM attack that successfully gets into the chain will be able to spoil the time downstream. 

MITM is pretty much a "game over" scenario.

I'm very curious about the quality of assertions that we can actually
rely on because "the whole chain of clocks talked to each other using
NTS" (or any other authentication model).

The primary purpose of the REFID was degree-one loop detection.  Once it
was there, in an IPv4 world we noticed we could use it for more things.
 This eventually led to faulty assumptions and problematic behaviors.
Unintended consequences, if you will.

I see the same thing happening above, and with some proposals offered by
others.

> No need to freak out about this, just ideas for v5. Yes, I know that all this is not part of the protocol in its current state. But we are talking about the future version of the protocol and I see use cases for this. 
>     
> Best Regards,
>    Heiko
>     
> 

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!