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

Harlan Stenn <stenn@nwtime.org> Mon, 02 September 2019 12:08 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 AE67A120089 for <ntp@ietfa.amsl.com>; Mon, 2 Sep 2019 05:08:08 -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 1UjXicBNRJ1I for <ntp@ietfa.amsl.com>; Mon, 2 Sep 2019 05:08:06 -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 02D3E120110 for <ntp@ietf.org>; Mon, 2 Sep 2019 05:08:06 -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 46MTQ308ChzL7Y; Mon, 2 Sep 2019 12:08:42 +0000 (UTC)
To: 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> <e5b16adb-eddb-fadd-4940-9d97685a36e4@rubidium.se>
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: <6ccb0e56-8bf7-8625-4ee3-2cde6df11681@nwtime.org>
Date: Mon, 2 Sep 2019 05:08:03 -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: <e5b16adb-eddb-fadd-4940-9d97685a36e4@rubidium.se>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/owlnIAs9Dc55PL_X45znkwB282I>
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:08:09 -0000

On 9/2/2019 4:32 AM, Magnus Danielson wrote:
> Dear Harlan,
> 
> On 2019-09-02 12:47, Harlan Stenn wrote:
>> On 8/28/2019 4:30 AM, Magnus Danielson wrote:
>>> I agree. If someone knocks on the door with v5 packets, reply in v5
>>> form, if someone knocks on the door with v4 packets, reply in v4 form.
>>> As people migrate to v5, they can start using all the benefits from it.
>> So what's the value and purpose of the version field in the packet if we
>> decide it no longer identifies the structure/content of the fields in
>> the packet?
>
> I have never said that. Rather the opposite.
What did I miss?  "If someone knocks on the door with v5 packtes, reply
in v5 form, ..."

How would a v4 implementation do this *properly*?  How would a v3
implementation do this?  There are still MILLIONS of v3 implementations
out there, and a noticeable number of "cheap" implementations, mostly in
embedded devices.

I continue to maintain that a response should be with a packet at the
highest version level we speak that does not exceed the version of the
incoming packet.

>> An implementation that speaks "version N" MUST understand version N
>> packet formats, and SHOULD understand versions <N.
>>
>> If there is a blanket requirement that if we understand version N and we
>> get a packet that is version >N, then if we respond with that same
>> version instead of responding with a version N packet, then we are
>> effectively saying we MUST NOT ever change the layout and meaning of the
>> content of the base packet.
>>
>> What I'm seeing in this thread is that folks disagree with the above,
>> and in that case I'm wondering if folks understand what they think
>> they're advocating for.
>>
>> Please see Heiko's last comment below, and understand it in this context.
> 
> Your comments are void since you misunderstood me, you should know
> better. Re-read and I think again and you will realize what I was trying
> to say is already in line with what you said. I do not feel motivated to
> contributing further if you keep this up.

Please tell me how I misunderstood you.

Perhaps you misunderstood me?

Either way, I'd prefer we both understood each other, and hopefully came
to an agreement.

>>> For loop-protection, keeping a list of nodes from the source is a very
>>> easy base condition to avoid routing loops, since as an announcement
>>> comes in, if none of the nodes in the list is oneself, you may use it,
>>> where as if any of the nodes is oneself, a loop is for sure detected.
>> The recipient has NO KNOWLEDGE of what the incoming refid means.
>>
>> It's SOLE PURPOSE in this is degree-one loop detection, and that happens
>> at the "top" of the local tree.
>
> Which indicates it's not a good method. You refer to another technical
> context than I was referring to.

It's not a good method *for what*?  It's demonstrably a good method for
detecting and avoiding degree-one loops.

>>> While the trace loop detection mechanism is sufficient in theory, it
>>> does not completely solve all loop problems, as transient loops may
>>> occur, but it at least avoids problems in the long term.
>>
>> I don't believe there is any current way to communicate this knowledge,
>> so larger trace loop detection seems impossible without a way to
>> communicate this information.  It also begs the question of *where* this
>> detection should happen.
> 
> I've designed these things before. I know what works.
> 
> You need to communicate a trace list, which requires dataformat to
> support it.
> 
> There is other methods, too.

Please offer at least a draft proposal.  I look forward to the security
analysis.

>> I think Heiko mentioned a loop they saw and I would be very interested
>> in seeing the details there, as such a loop should break as soon as any of:
>>
>> - the stratum in the loop devolves to 16
>> - the root distance grows
>> - possibly something else
>
> These are too slow. You shoot the phase of the systems too far. It's a
> weak method. It will break a loop, but way too late and the collateral
> damage is too great.

Then perhaps effort is better spent in detecting this case, as it would
*seem* to be an issue of an insufficient number of time sources.

If one has insufficient time sources,  exactly what are the alternatives
to providing time sync amongst the members of the "time island" and what
are the costs/ and benefits of each alternative?

With insufficient connectivity to what extent does it matter which weeds
one sails off into?

With insufficient connectivity (ie, knowledge of accurate time) how can
any demonstrably better choice be made?  This is precisely why we
shifted from local refclocks to orphan mode.  And the bottom line is one
must still make decisions based on the best available information.

>> The point being that the important thing is that if a loop happens there
>> is an automatic recovery path.  If we never get a loop that's better,
>> but it won't be fatal to a properly configured setup if a loop happens
>> and the loop is then broken.
> 
> The trouble with the loop is that the system is tricked to belief this
> IS the better path. You need to kill old topology information or have a
> full trace to break any risk of loop, and to very quickly kill the loop
> and allow for other paths to be discovered.

I'm not certain this is the only viable approach, especially in today's
security environment.

We might be able to avoid this based on additional weighting and
analysis of stratum and root distance, or perhaps some new meterics.

>>> If I only had time to describe all the things I would do to enhance NTP,
>>> it has a number of built-in assumptions which is not useful or correct.
>> How about a list of at least some of the built-in assumptions that you
>> think are not useful or correct?
> 
> From the top of my head a few:
> 
> The Allan interception point is based on incorrect theory of the noise.

I honestly don't know if this is true or not.  I don't disbelieve you.

I do wonder if perhaps the elements that make up the noise now have
changed from what they used to be.

Is that what you are saying?

> Rather than drive things to highest stratum, going to closes
> intermediate node and then let that do aggregated questioning to
> increase the width of single stream rather than separate allows better
> noise suppression of asymmetric delays.

I'd have to re-check, and I thought we stopped following the best
stratum and focused on the best "numbers".

As for increasing the width, how is that different from making sure one
has enough sources of time?

At what level of the tree does this matter?

There is mechanism and policy here.

One can have leaf nodes that listen to a lot of different upstreams.

One can have leaf nodes that listen to one or more different upstreams,
where each upstream listens to a "wide" number of sources.

How is this different from the age-old discussion of "have enough
sources of time"?  And folks who pick one, which is great until it dies,
so they pick 2, until that fails because of lack of a majority, then 3
which fails when one dies and it devolves into 2, or 4 which works until
2 follow correct time and 2 follow leap-smeared time, or ...

I submit we have all the mechanism we likely need, and the problem is
with the implemented policy choices.

> The frequency/phase lock-in methods is dated and has failures in
> error-handling, especially with how calibration works and can become
> incorrect. There is simpler methods with much better error-handling.

I'd like to discuss this with you privately, if you're interested.

H
--
> Cheers,
> Magnus
> 
>>
>> H
>> --
>>> Cheers,
>>> Magnus
>>>
>>> On 2019-08-28 13:23, Heiko Gerstung wrote:
>>>> Why not define a method in v5 that not only protects against degree 1 loops but maybe also against degree 2,3 or n? 
>>>>
>>>> This is what I meant when trying to explain that we should not stick to the existing packet format with its shortcomings.
>>>>
>>>> Regards,
>>>>    Heiko
>>>>
>>> _______________________________________________
>>> ntp mailing list
>>> ntp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ntp
>>>
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
> 

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