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

Heiko Gerstung <heiko.gerstung@meinberg.de> Tue, 03 September 2019 07:59 UTC

Return-Path: <heiko.gerstung@meinberg.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 CD99612026E for <ntp@ietfa.amsl.com>; Tue, 3 Sep 2019 00:59:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.289
X-Spam-Level:
X-Spam-Status: No, score=-4.289 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, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=meinberg.de
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 Yw0j8dpP-sTg for <ntp@ietfa.amsl.com>; Tue, 3 Sep 2019 00:59:11 -0700 (PDT)
Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C0D12003F for <ntp@ietf.org>; Tue, 3 Sep 2019 00:59:11 -0700 (PDT)
Received: from srv-kerioconnect.py.meinberg.de (unknown [193.158.22.2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id 6566471C07BF; Tue, 3 Sep 2019 09:59:07 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.2 server1a.meinberg.de 6566471C07BF
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=meinberg.de; s=mail201101; t=1567497549; bh=iVOqGWx6Lj/EQjXEVpCCQT7gCXn9yT75joNysi/3kSQ=; h=Date:Subject:Message-ID:References:In-Reply-To:Mime-version:From: To:Content-Type:Content-Transfer-Encoding; b=F8mQ1jsYd8CL7dJfcjhk6AINN6MCp1+BzhqP53k8jSYU26g7ZQtoB9ckZYW4GaXhi kjrqMj6tBV2+vPHnes6fibFtK0/VcyjkQvN8tH15Qi5Zj8GbBz4JXJlwwD0EF0PiVV R4rzB9BcjdLT8jQdsDXRTzgmstKRVQ//mJUsZJh0=
X-Kerio-Anti-Spam: Build: [Engines: 2.15.9.1266, Stamp: 3], Multi: [Enabled, t: (0.000008,0.017643)], BW: [Enabled, t: (0.000007)], RTDA: [Enabled, t: (0.098786), Hit: No, Details: v2.7.53; Id: 15.1i65o8d.1djr24pcs.3f4ap], total: 0(700)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/10.1c.0.190812
Date: Tue, 3 Sep 2019 09:59:03 +0200
Message-ID: <F9ECE897-2A6D-4336-86B6-88F87FC4BA89@meinberg.de>
Thread-Topic: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
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> <d7d3e82d-2c9d-b360-9339-f3527973176d@nwtime.org>
In-Reply-To: <d7d3e82d-2c9d-b360-9339-f3527973176d@nwtime.org>
Mime-version: 1.0
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+MDNjYzVhNjFjMDY4OWQ0MA==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: Harlan Stenn <stenn@nwtime.org>, "ntp@ietf.org" <ntp@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.100.3 at server1a
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/JW84xoVtWGY2dPiq6OP4JKNzUPE>
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: Tue, 03 Sep 2019 07:59:15 -0000

Hi Harlan,

On 02.09.19, 14:31 "Harlan Stenn" <stenn@nwtime.org> wrote:

    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.

I am fine with that. No objections whatsoever. 
    
    >     > 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.

Harlan, you can at any time implement optional EFs in ntpd, they do not need to be standardized in an RFC. If they are picked up by the users, it might happen that they are ending up in a standalone RFC later (or in v5). 
    
    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.

I do not want to prevent this, I want to prevent that we end up adding this and that (optional) feature to v4 and see a ton of v4 implementations, each providing a different subset of all the features. I also do not want to wait another 10 years before we start working on v5, we should shorten the release cycle to a handful of years instead, making more incremental changes to the protocol instead of introducing a new version every 20 years and keep it alive by adding optional features to it during those two decades.
    
    >     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?

I think I explained it below.
    
    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?

If a bad actor can abuse an upstream system, all downstream systems are toast anyway, right? But again, the InstanceID is a way to avoid that mapping and at the same time provides a unique ID for each NTP instance. 
    
    >     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.

You have a great memory. I have no idea what I did 20 years ago to be honest. But just because it was shot down 20 years ago does not mean it is useless, unreasonable or not helpful today. And it definitely does not mean that we should leave it alone because something like this has been discussed in another time and people then decided it is not worth it. 
    
    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*.

This probably depends on the length of the InstanceID. If that ID is created in a randomized way and the random ID is long enough to make it very unlikely that two NTP instances talking to each other end up having the same ID, it can work just fine without any negotiations etc. What happens to IPv6 addresses that are hashed into 4 bytes to create a refid, what is the probability that two systems talking to each other come up with the same value? I know that a chain of 3-4 servers multiplies the chance that any two of them create the same random ID, but if we choose to have a 16byte InstanceID for example, this should be fine. 
    
    Please imagine this in the face of the NTP Pool.

The pool typically provides stratum 2 or 3 servers. I think that the pool especially would benefit from being able to identify that my stratum 3  pool servers A,B and C are in fact synchronized to the same stratum 1 server and therefore do not really represent a multi-source solution for my client. At the moment I do not really have a chance to find that out. If I would know, the client could re-resolve the pool dns entries until it finds 4 servers all with different stratum 1 sources.

The worst thing that can happen in the very unlikely event of two servers in a chain accidentally ending up with the same random InstanceID is that the downstream server wrongly detects a loop and rejects this reference. It would be possible to solve this by making it mandatory for an instance to recreate a new random InstanceID if all upstream servers are ruled out due to this loop detection. There are two possibilities here: if this is a false positive and there is no loop, changing my own instanceID will solve it because the upstream server will stick to its InstanceID and the resulting chain does not trigger the loop detection anymore. If it really is a loop, the chain will, after a few polling cycles, again trigger the loop detection because the new InstanceID shows up in the chain. If we add information in the chain about the polling intervals or the age of the InstanceID entries, the instance that recreated its random InstanceID could wait until it is clear that the IntanceID triggering the loop detection remains unchanged. 
    
    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.

I would not want something like a registry and I believe we do not need one. I am not sure about the dependency on an authoritative source. Can you explain why you believe that we do not need the loop detection as long as we have an authoritative source?
    
    >     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.
That's what I said. 
    
    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).

Well, we can only trust our direct upstream server. That server, in turn, can only trust its own upstream servers. This is a chain of trust and as I said, if I do not have any access, information or trust in any of the upstream servers of my own upstream server, I cannot assert anything. The intention of this approach/flag is to make sure that a client chooses a chain of NTS protected servers over an alternative that uses unauthenticated NTP. It would also allow the user to tell their clients to not accept any upstream source when its chain does not contain only NTS protected servers.
    
    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.

This is why I would like to see that a) the InstanceID is used as the RefID - but make it 16 bytes (or longer) and randomize it. This requires a change in the packet format (which was the start of this discussion). Using the InstanceID to create the chain, offering n-degree loop detection and an indication whether the upstream server relies on NTS/protected information, would be optional and can be implemented using EFs. 
    
    I see the same thing happening above, and with some proposals offered by
    others.

I do not see unintended consequences, but that is probably the nature of unintended consequences (if you would see them, they become intended consequences). The fact that this quickly sketched InstanceID thing can lead to unwanted side effects should not hold us back from investigating this and other possible enhancements. The chance of "unintended consequences" is *always* there. You can deal with that by discussions and research. My whole point here is that we should do this. I am not married to the idea of the InstanceID and the chain and n-degree loop detection etc.  - I just believe it would improve NTP and is worthwhile to be investigated further. 


    
    > 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!
    
Thank you for the discussion, Harlan. It helps to point out potential problems as this allows everyone to think about a solution for that problem. 

Best Regards,
    Heiko


-- 
Heiko Gerstung 
Managing Director

MEINBERG® Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone:    +49 (0)5281 9309-404
Fax:        +49 (0)5281 9309-9404

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung

Email:
 heiko.gerstung@meinberg.de 
Web:
 Deutsch   https://www.meinberg.de
 English    https://www.meinbergglobal.com

Do not miss our Time Synchronization Blog:
 https://blog.meinbergglobal.com 

Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung