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

[Harlan Stenn <[e-mail]>]

Heiko,

On 9/2/2019 4:49 AM, Heiko Gerstung wrote:
> On 02.09.19, 13:30 "ntp im Auftrag von Harlan Stenn" <[e-mail] im Auftrag von [e-mail]> 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!