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

[Heiko Gerstung <[e-mail]>]

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). 
   
    > 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.
    
    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. 
    
    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 appeariong twice, you can assume that there is no loop.
    
    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. 

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
    

-- 
Heiko Gerstung 
Managing Director

MEINBERG® Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone:    [phone]
Fax:        [phone]

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

Email:
 [e-mail] 
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