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

[Heiko Gerstung <[e-mail]>]

Apologies for the more or less broken quoting style. Outlook is crap in this regard ..

On 28.08.19, 14:27 "ntp im Auftrag von Ulrich Windl" <[e-mail] im Auftrag von [e-mail]> wrote:

    >>> Heiko Gerstung <[e-mail]> schrieb am 28.08.2019 um 13:59
    in
    Nachricht <[e-mail]>:
    > Harlan,
    > 
    > I asked why we would not want to improve the loop prevention mechanism, I do
    
    > not have a solution at hand which I sketched out in full detail already. But
    
    > here is a possibility that came to my mind just now, it certainly needs to
    be 
    > refined and checked and modified:
    > 
    > - create a random ID on each server at startup
    
    I'd add a "double-may" there: The ID MAY be random, and it MAY be re-created
    on each server startup.
    Maybe think of it like the driftfile that preserves some value across
    restarts.

OK, fine with me. 

    
    > - communicate that ID to each client which indicates (e.g. by an EF) that it
    
    > is interested in this information, for example if it wants to be a server 
    > itself (stratum 2+)
    
    Why not always add it?
    
Because as Miroslav already pointed out, most client-only implementations do not need it. 
    
    > - a tier-2 server uses that ID from its upstream server as its refID
    > - any server that is interested in degree n - loop detection will indicate 
    > this (using an EF, maybe something like the I-DO EF) to its upstream 
    > server(s)
    > - those servers respond with an EF containing a list of IDs representing the
    
    > sync chain, maybe limited to n entries (if the requesting client asks for 
    > only n entries)
    > - now, if this server which received the chain of IDs from its upstream 
    > server(s) now is questioned by one of its downstream clients about the chain
    
    > of sync, it will add the RefID of its upstream servers to the sync chain 
    > received by that upstream server and push this down to the client
    > 
    > This way, those clients interested in only degree 1 loop protection just use
    
    > the RefID field. And those who are interested in degree n loop protection
    can 
    > request the chain of IDs from their upstream servers. 
    > 
    > The freedom to change the packet header format would allow us to increase 
    > the number of bytes for the RefID to improve security (more bytes, harder to
    
    > guess). 
    > 
    > We have had cases where a server A was synchronized by server B which was 
    > synchronized by server C. Server C also used Server D which was synchronized
    
    > by Server A, i.e. whenever your client believes it has more than one source
    
    > of time and it turns out that all of them go back to one single source. 
    > Adding non-randomized IDs like "GPS" to the sync chain (by the stratum 1 
    > server) would also allow the clients to identify if they are relying on one
    
    > single source of time, which in turn would make it possible to choose
    another 
    > server with a different source (like Galileo) instead.
    
    So this applies only to stratum-1 servers (which had spacial refIDs anyway).

No, the whole sync chain thing would be applicable to all servers, not only stratum 1's. I just wanted to point out that you can avoid using the same root source of time with the stratum 1 servers creating the sync chain by just initializing it with a standardized RefID (like "GPS") referring to their non-NTP source. That way, a client could avoid using three servers all taking their time from GPS and then get hit by the same spoofing attack. 

    What about having a "normal" REFID for stratum 1 servers, and adding a
    mandatory "reference source class" (like "GPS", "Gallileo" (note the extra
    length!), "NTP" (for stratum > 1), "DCF-77", etc? (Or even do it the GPT-way:
    Allocate UUIDs (well, GUIDs will do as well) for all known reference clock
    sources?)

Yes, why not. And yes, I took notice of the longer RefID value ;-) ...

    And if you like splitting hairs, you could have different IDs for the "time
    source" (like TAI), the "time carrier" (like GPS) and the "time access point"
    (effectively the interface providing GPS time) like "Product X from Vendor Y
    with further details Z"...
    So if a specific product has a bug, you could filter it; if a specific carrier
    has a problem, you could filter it, and if you distrust some source, you could
    filter it... ;-)

Yep!

Regards,
    Heiko



    
    Regards,
    Ulrich
    
    > 
    > 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 
    >  
    >  
    > 
    > On 28.08.19, 13:38 "ntp im Auftrag von Harlan Stenn" <[e-mail]
    
    > im Auftrag von [e-mail]> wrote:
    > 
    >     
    >     
    >     On 8/28/2019 4:23 AM, 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.
    >     
    >     Exactly how would this work?
    >     
    >     Has there been any reported instances of this being useful or needed
    for
    >     NTP?
    >     
    >     What abuse vectors would this create?
    >     
    >     > Regards,
    >     >    Heiko
    >     > 
    >     
    >     -- 
    >     Harlan Stenn, Network Time Foundation
    >     http://nwtime.org - be a Member!
    >     
    >     _______________________________________________
    >     ntp mailing list
    >     [e-mail] 
    >     https://www.ietf.org/mailman/listinfo/ntp 
    >     
    > 
    > 
    > _______________________________________________
    > ntp mailing list
    > [e-mail] 
    > https://www.ietf.org/mailman/listinfo/ntp 
    
    
    
    _______________________________________________
    ntp mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/ntp
    



-- 
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