Subject: [Ntp] Antw: NTP WG Virtual Interim, Tuesday 12 February, 1630-1830 UTC

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 04 Feb 2019 08:23:18 +0100

Hi!

Recently I had this idea for REFID:
In the past one yould find out the time source where the currentl time came from.
With the new proposal, it's no longer possible. AFAIR the arguments were pro this (source not being trackable).
I have an argument against this: If you establish some time stamping service, you may be interested to document where the time came from. Just as one might document the certificate path back to the root CA...

Regards,
Ulrich Windl

---

From: Heiko Gerstung <[email-masked]>
Date: Mon, 4 Feb 2019 13:41:41 +0100

Hi Ulrich,

I believe that the RefID is not a good way of documenting where your time came from, it is easy to change and does not offer any legal or operational proof of anything, especially not when you need to fulfill some kind of traceability requirements. A certificate trail is completely different as it allows to make sure that the trail is what it says it is. 

I personally also like the possibility to easily spot what the time source of my time source is by looking at the RefID, but it is not capable of reliably fulfilling the traceability demands of users. 

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:
 [email-masked] 
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 04.02.19, 08:24 "ntp im Auftrag von Ulrich Windl" <[email-masked] im Auftrag von [email-masked]> wrote:

    Hi!

    Regards,
    Ulrich Windl

    
    _______________________________________________
    ntp mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/ntp

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 4 Feb 2019 11:03:21 -0800

Just to summarize:

- the refid is an "encoding" of the system peer.
- the refid is explicitly used as the way to prevent
  a degree-1 timing loop.
- there are cases where 3rd parties want to know "where
  do you get your time from?"  There are situations where
  that's OK for 3rd parties to know, and situations where
  that is "none of their business".

Before we start deciding where to draw these lines, especially for other
systems, we should have a clear understanding of what's going on, why,
and how to handle exceptions.

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

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 05 Feb 2019 08:37:54 +0100

>>> Heiko Gerstung <[email-masked]> schrieb am 04.02.2019 um 13:41
in
Nachricht <[email-masked]>:
> Hi Ulrich,
> 
> I believe that the RefID is not a good way of documenting where your time 
> came from, it is easy to change and does not offer any legal or operational

> proof of anything, especially not when you need to fulfill some kind of 
> traceability requirements. A certificate trail is completely different as it

> allows to make sure that the trail is what it says it is. 

Hi Heiko,

I agree in principle, but as it was for IPv4 in the past, REFID was the _only_
way to find the path to the refclock (assuming one could access all the servers
in the path). That's how ntptrace ("ntptrace is a perl script that uses the
ntpq utility program to follow the chain of NTP servers from a given host back
to the primary time source.") worked.

> 
> I personally also like the possibility to easily spot what the time source 
> of my time source is by looking at the RefID, but it is not capable of 
> reliably fulfilling the traceability demands of users. 

Yes, so obviously the proposal for a new REFID should include a repacement for
the functionality that got lost. In my view the best alternative would be an
extension field that tells what the REFID really is (IP adress(es), FQHN,
etc.). From such an extension field a program (not human) should be able to
contact (if possible and administratively allowed) contact the server to work
towards the ultimate time source recursively.

Regards,
Ulrich Windl

> On 04.02.19, 08:24 "ntp im Auftrag von Ulrich Windl" <[email-masked]

> im Auftrag von [email-masked]> wrote:
> 
>     Hi!
>     
>     With the new proposal, it's no longer possible. AFAIR the arguments were

> pro this (source not being trackable).
>     I have an argument against this: If you establish some time stamping 
> service, you may be interested to document where the time came from. Just as

> one might document the certificate path back to the root CA...
>     
>     Regards,
>     Ulrich Windl
>     
>     
>     
>

---

From: Heiko Gerstung <[email-masked]>
Date: Tue, 5 Feb 2019 08:51:50 +0100

Harlan,

isn't the stratum level the value that prevents timing loops? 

Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn: 

On 04.02.19, 20:04 "ntp im Auftrag von Harlan Stenn" <[email-masked] im Auftrag von [email-masked]> wrote:

    Just to summarize:

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 5 Feb 2019 09:18:10 +0100

> isn't the stratum level the value that prevents timing loops? 

That was in NTPv3.

In NTPv4 clients are allowed to synchronize to a higher stratum, so it
can only terminate the loop when the value reaches 16. It does not
prevent the loop from forming. The same applies to the root delay and
dispersion.

The refid field is useful at least to:
1) prevent A from synchronizing to B when:
  a) B is synchronized to A
  b) A and B are synchronized to C
  c) B and C are synchronized to D, and A is synchronized to C
2) monitoring
3) debugging

If I understand it correctly, hiding the refid using the not-you value
will break everything except 1a.

-- 
Miroslav Lichvar

---

From: Daniel Franke <[email-masked]>
Date: Tue, 5 Feb 2019 09:16:58 -0500

Sorry, won't be able to make it today due to a dental emergency.

On Tue, Jan 29, 2019 at 11:49 AM Karen O'Donoghue <[email-masked]> wrote:
>
> Folks,
>
> The Network Time Protocol (ntp) Working Group will hold a virtual interim meeting on Tuesday 12 February 2018 from 16:30 to 18:30 UTC.  The primary focus of this meeting will be to progress ongoing WGLCs on a number of working group documents. Additional agenda requests can be sent to the working group chairs for inclusion.
>
> Draft Agenda:
>
> 1.  Administrative and Agenda Bashing
> 2.  TICTOC quick document status (documents we hopefully won’t need to discuss)
> 3.  NTP quick document status (documents we hopefully won’t need to discuss)
> 4.  Network Time Security for the Network Time Protocol (next steps)
> 5.  Planning for NTS interoperability testing
> 6.  Network Time Protocol REFID Updates (next steps)
> 7.  NTP Interleaved Modes (next steps)
> 8.  NTP Client Data Minimization (next steps)
> 9.  A YANG Data Model for NTP
> 10.  Other working group documents
> 11. Next steps in time security beyond NTS
> 12.  AOB (Any Other Business?)
>
> The meeting will be held on Zoom. You can join via the link or by calling in using the provided phone numbers.
>
> Topic: NTP WG Virtual Interim meeting
> Time: Feb 12, 2019 4:30 PM GMT
>
> Join Zoom Meeting
> https://isoc.zoom.us/j/583983466
>
> One tap mobile
> +16465588656,,583983466# US (New York)
> +16699006833,,583983466# US (San Jose)
>
> Dial by your location
>         +1 646 558 8656 US (New York)
>         +1 669 900 6833 US (San Jose)
> Meeting ID: 583 983 466
> Find your local number: https://zoom.us/u/aeoTGQ1PbS
>

---

From: Daniel Franke <[email-masked]>
Date: Tue, 5 Feb 2019 09:28:35 -0500

Nevermind, Sam Weiler just pointed out that this meeting is next week.
Was thinking it was today.

---

From: Heiko Gerstung <[email-masked]>
Date: Wed, 6 Feb 2019 08:46:10 +0100

Hi Miroslav, 

the RefID based loop prevention in NTP implementations works only if a client has access to the source of its source, which is very rarely the case in corporate networks (and which is often prevented by firewalls to avoid that people for example directly use one of the core NTP servers as a reference). I would also doubt that such a RefID based loop prevention mechanism is working reliably with hashed IPv6 addresses. 

It is probably a good idea to define a mechanism which is  based on an extension field to cover debugging / monitoring use-cases more effectively. You would certainly need a unique ID instead of relying on the IP addresses of all your upstream servers. Suggestion: use the MAC address of the first physical network interface NTP runs on, which should be sufficiently unique (unless your server runs in a VM). Every NTP node then adds the Unique ID of its source to the chain. If A is synchronized to GPS, it will send a traceability chain that looks like this : "GPS". When B synchronizes to A: "GPS,[MAC_ADDR_OF_A]", when C synchronizes to B: "GPS, [MAC_ADDR_OF_A], [MAC_ADDR_OF_B]" and so on. Maybe the extension could also include some additional data like precision of a source etc. to be able to calculate error bounds. 

For legal / compliance use cases this is not going to help as you would need a digitally signed chain and would have to be able to verify the signatures of all involved NTP nodes on the path.

All in all this looks like we need to put some more thoughts into it. But I personally believe that the refid is not sufficient for a lot of situations, especially not for IPv6 and whenever there is no access to upstream servers. 

Best Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn: 

On 05.02.19, 09:19 "Miroslav Lichvar" <[email-masked]> wrote:

    That was in NTPv3.

    
    
    -- 
    Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 6 Feb 2019 00:14:16 -0800

Heiko,

The core purpose of the REFID in NTPv4 is to act as a degree-1 loop
preventer.

Are you saying it does not fulfill that role?

H

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 06 Feb 2019 09:52:31 +0100

Hello!

A different thought: if you would propagate the refid of stratum 1 servers
down to the clients (if client C is using server S as peer, then C's refid
would be that of S), there is another interesting problem: There are too many
refids like "GPS " then, making it hard to decide, which is which.
However it would ultimately prevent a client using GPS multiple times ;-)

So actually while discussing the REFID for stratum > 1, shouldn't there be a
discussion for stratum 1 as well? When IPv6 addresses are hashed as suggested
in RFC 5905, why not also hash the REFID for stratum 1? One could add
manufacturer, device model, serial number, etc. to that primary refid.
What I thought is: If the refid of stratum > 1 does not really reveal the
identity of the time source, why keep it at stratum 1? And: if propagating the
refids down from stratum 1, wouldn't that prevent a timing loop as well, maybe
even better?

Before using the MAC as source for some REFID, why not create some random GUID
(64 bit should be enough) and store that in persistent storage?

Regards,
Ulrich Windl

>>> Heiko Gerstung <[email-masked]> schrieb am 06.02.2019 um 08:46
in
Nachricht <[email-masked]>:
> Hi Miroslav, 
> 
> the RefID based loop prevention in NTP implementations works only if a 
> client has access to the source of its source, which is very rarely the case

> in corporate networks (and which is often prevented by firewalls to avoid 
> that people for example directly use one of the core NTP servers as a 
> reference). I would also doubt that such a RefID based loop prevention 
> mechanism is working reliably with hashed IPv6 addresses. 
> 
> It is probably a good idea to define a mechanism which is  based on an 
> extension field to cover debugging / monitoring use-cases more effectively.

> You would certainly need a unique ID instead of relying on the IP addresses

> of all your upstream servers. Suggestion: use the MAC address of the first 
> physical network interface NTP runs on, which should be sufficiently unique

> (unless your server runs in a VM). Every NTP node then adds the Unique ID of

> its source to the chain. If A is synchronized to GPS, it will send a 
> traceability chain that looks like this : "GPS". When B synchronizes to A: 
> "GPS,[MAC_ADDR_OF_A]", when C synchronizes to B: "GPS, [MAC_ADDR_OF_A], 
> [MAC_ADDR_OF_B]" and so on. Maybe the extension could also include some 
> additional data like precision of a source etc. to be able to calculate
error 
> bounds. 
> 
> For legal / compliance use cases this is not going to help as you would need

> a digitally signed chain and would have to be able to verify the signatures

> of all involved NTP nodes on the path.
> 
> All in all this looks like we need to put some more thoughts into it. But I

> personally believe that the refid is not sufficient for a lot of situations,

> especially not for IPv6 and whenever there is no access to upstream servers.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 6 Feb 2019 01:32:06 -0800

I've been thinking about this problem for many years' time.

It ends up boiling down to "what is the real, underlying problem you
want to solve?" coupled with "how often does this happen?" and "what are
ways around it?"

GPS could catastrophically fail.  In that case, no GPS refclocks will be
working.  There might be a problem with a given vendor (at the box or
chip level).  Or the problem might be in specific firmware.

This is still an interesting exercise, but there are likely bigger or
more likely problems afoot.

H

---

From: Heiko Gerstung <[email-masked]>
Date: Wed, 6 Feb 2019 10:45:39 +0100

Hi Ulrich,

passing on the RefID from the Stratum 1 (root) source would require a unique ID (as described by you). I am not sure if this would avoid timing loops (GPS->A->B->C->A, all nodes would just see "GPS" as the RefID, so would B and C but only C formed a loop) but it would certainly not cover the use case of ntptrace.pl (i.e. debugging, monitoring) and certainly not the traceability. A "sync" trail would be covering all of the use cases, in combination with NTS it could be also cryptographically secured and therefore might even cover the legal/compliance requirements of some of our end users. You can of course use any other unique ID, I just thought that the MAC address is already there and also maybe helps with identifying a box on the network. However, for the described purpose (unique id) a hash of some unique information (like vendor/model/serialnumber) would do, too.

Best Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn: 

On 06.02.19, 09:53 "Ulrich Windl" <[email-masked]> wrote:

    Hello!

    
    
    Regards,
    Ulrich Windl
    
    in

    

    error

---

From: <[email-masked]>
Date: Wed, 6 Feb 2019 15:59:46 +0000

Good idea Heiko.  I think the idea of a "ntptrace" via an extension field would be a great use of the functionality, at least in the developer/debugger community.  How widespread the utility value is might be debatable.  Elements in the path could choose whether or not to contribute, although it would be important to include a "NULL" to at least show the where the hop data was bridged.  Ideally the data contributed by each element would be flexible, maybe a TLV structure.  It could have a default encoding scheme using something simple like mac or something much broader (e.g., clock hw definition, clock inputs, gps/other mfg data for S0 input, #of peer connections, uptime, etc).  If you are seeing a root dispersion of X, you may be able to find that most of the chain is fine and better manage ntp networks.  You may also find out that your 3 upstream servers are actually all synchronized to the same set of servers upstream, providing redundancy but not diversity.  

Greg Dowd
Principal Engineer, FTD
Microsemi 
3870 N. First St. | San Jose | CA 95134 | USA
Office: 408.964.7643
Email: [email-masked]
Company Website:  www.microsemi.com

-----Original Message-----
From: ntp [mailto:[email-masked]] On Behalf Of Heiko Gerstung
Sent: Tuesday, February 5, 2019 11:46 PM
To: Miroslav Lichvar <[email-masked]>
Cc: Ulrich Windl <[email-masked]>; Harlan Stenn <[email-masked]>; [email-masked]
Subject: Re: [Ntp] Antw: NTP WG Virtual Interim, Tuesday 12 February, 1630-1830 UTC

EXTERNAL EMAIL

Hi Miroslav,

Best Regards,
   Heiko

--
Heiko Gerstung
Managing Director

Email:

Connect via LinkedIn:

    That was in NTPv3.

    --
    Miroslav Lichvar

---

From: Heiko Gerstung <[email-masked]>
Date: Thu, 7 Feb 2019 16:32:53 +0100

Harlan,

> will break everything except 1a.

As he pointed out, a degree-1 loop is prevented by the "not-you" refid, but not any degree-1+n loops. I did not yet test if ntpd detects degree-1 loops in case of a host having multiple IPv4 and IPv6 adresses, did you test that? 

In general I believe that a degree-1 loop misconfiguration is much easier to find than a degree-1+n loop. 

Best Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn: 

On 06.02.19, 09:15 "Harlan Stenn" <[email-masked]> wrote:

    Heiko,

    
    H