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

From: Magnus Danielson <[email-masked]>
Date: Wed, 28 Aug 2019 13:30:33 +0200

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.

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.

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.

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.

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
>

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 02 Sep 2019 08:35:58 +0200

>>> Magnus Danielson <[email-masked]> schrieb am 28.08.2019 um 13:30 in
Nachricht <[email-masked]>:
> For loop‑protection, keeping a list of nodes from the source is a very

But remember that a "note" is NOT "an IP address". With multi-homed hosts you
can have interesting synchronization loops... ;-)

> it has a number of built‑in assumptions which is not useful or correct.
> 
> 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
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ntp

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 02 Sep 2019 08:42:48 +0200

>>> "Ulrich Windl" <[email-masked]> schrieb am 02.09.2019
um
08:35 in Nachricht <[email-masked]>:
> But remember that a "note" is NOT "an IP address". With multi-homed hosts 

s/note/node/ # Sorry!

> you

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 2 Sep 2019 09:59:44 +0200

> where as if any of the nodes is oneself, a loop is for sure detected.

NTP clients can be synchronized to multiple sources at the same time,
so it's not just a list - it's a graph. In any case, this probably
requires a new extension field and it could work equally well in both
NTPv4 and NTPv5. I was hoping the suggested-refid EF could evolve in
that.

> it has a number of built-in assumptions which is not useful or correct.

Well, maybe we could start with a list of issues of NTPv4 to get an
idea of what needs to be fixed in NTPv5 (and what just needs a new
extension field)? I have a few items. I think we could use the NTP WG
wiki.

-- 
Miroslav Lichvar

---

From: Heiko Gerstung <[email-masked]>
Date: Mon, 2 Sep 2019 10:00:41 +0200

Hi Ulrich,

good point. That is why NTP would use that "ID" instead of the IP address to identify itself. That means ntpd could find out timing loops even if they are caused by a routing loop.

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

---

From: Hal Murray <[email-masked]>
Date: Mon, 02 Sep 2019 02:37:50 -0700

[email-masked] said:
> But remember that a "node" is NOT "an IP address". With multi-homed hosts you

Is there a problem with using an IPv6 address to identify a system?  (if you are multi-homed, just pick one)

You have to skip over fe80::, Link-Scoped Unicast.  Are there other ranges?

There is some way to map IPv4 addresses to IPv6 if you aren't using IPv6.  RFC-1918 addresses won't be globally unique.  They should work if you are on an isolated network.  That doesn't work if you have more than one system going through the same NAT box.

Would it be simpler/cleaner to use an Ethernet host addresses?  (what are they called these days?)  Are there any potential cases where an NTP server wouldn't have one?

-- 
These are my opinions.  I hate spam.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 2 Sep 2019 11:58:54 +0200

> Is there a problem with using an IPv6 address to identify a system?  (if you are multi-homed, just pick one)

If the system has multiple addresses, its clients may not know all of
them and may fail to detect loops. Addresses are no good.

We need each server (or rather the clock) to have an ID and extend the
protocol to exchange this ID so clients (that operate also as servers)
can reliably detect 1-degree loops. The suggested-refid EF basically
does that.

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 02 Sep 2019 12:12:33 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 02.09.2019 um 09:59 in
Nachricht <20190902075944.GB15024@localhost>:
> so it's not just a list ‑ it's a graph. In any case, this probably
> NTPv4 and NTPv5. I was hoping the suggested‑refid EF could evolve in
> that.
> 

I think such a list would be a good idea. Maybe even before actually wortking
on NTPv5, that list could be distributed in two sub-lists:

* issues intended to be fixed in NTPv5
* issues not intended to be fixed in NTPv5

That would make a good abstract for NTPv5 anyway ;-)

Regards,
Ulrich

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 2 Sep 2019 03:21:16 -0700

The refid has meaning on the system that issues it.

The refid is a nonce to any system that receives it.

Any meaning of the refid outside of the issuing system relies on
higher-level knowledge that is not part of the protocol.

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

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 02 Sep 2019 12:36:34 +0200

>>> Hal Murray <[email-masked]> schrieb am 02.09.2019 um 11:37 in
Nachricht <[email-masked]>:

> [email-masked]‑regensburg.de said:
>> But remember that a "node" is NOT "an IP address". With multi‑homed hosts
you
>> can have interesting synchronization loops... ;‑) 
> 
> Is there a problem with using an IPv6 address to identify a system?  (if you

> are multi‑homed, just pick one)
> 
> You have to skip over fe80::, Link‑Scoped Unicast.  Are there other ranges?

Once we tried anycast (see NTP bug 3366). It was IPv4 only (eccept maybe
link-local IPv6 addresses assigned automatically)

> 
> There is some way to map IPv4 addresses to IPv6 if you aren't using IPv6.  
> RFC‑1918 addresses won't be globally unique.  They should work if you are on

> an isolated network.  That doesn't work if you have more than one system 
> going through the same NAT box.
> 
> Would it be simpler/cleaner to use an Ethernet host addresses?  (what are 
> they called these days?)  Are there any potential cases where an NTP server

> wouldn't have one?

I think the only reasonable solution would be "server ID" that covers all
possible network adresses of one server. Whether that server ID is just a
random value or maybe a hash of the FQHN is an open question, but IMHO 64 bits
should be enough (128 seems overkill, and 96 doesn not make much sense IMHO).

Regards,
Ulrich

> ‑‑

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 02 Sep 2019 12:38:56 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 02.09.2019 um 11:58 in
Nachricht <20190902095854.GC15024@localhost>:
> On Mon, Sep 02, 2019 at 02:37:50AM ‑0700, Hal Murray wrote:
>> 

> are multi‑homed, just pick one)

So in principle that ID could change at a server restart?

> them and may fail to detect loops. Addresses are no good.

Yes, especially if virtual IP addresses come and go.

> can reliably detect 1‑degree loops. The suggested‑refid EF basically
> does that.

Yes.

---

From: Heiko Gerstung <[email-masked]>
Date: Mon, 2 Sep 2019 12:45:54 +0200

Not talking about the refid. An "InstanceID" could be a unique identifier of an NTP instance. It could be used as a refid as well in the NTP responses of an instance. Every server in a chain would be able to ask its upstream NTPv5 servers for their chain and passes that chain down to its clients (upon request) adding its own instanceID to the list. Any NTPv5 server receiving that chain could check if its own instanceID is already in the chain and then reject the upstream server due to a time loop detection issue. 

This higher level knowledge is not part of the *NTPv4* protocol, but it could be part of the NTPv5 protocol. If we add a flag to each entry in that chain indicating if that instance was protected with NTS, we could come up with a "chain of trust" thing and we could not only detect timing loops but would also be able to find out if the chain of clocks is fully NTS protected. 

There might be other benefits, I am just tossing ideas around..

Best Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn: 

On 02.09.19, 12:22 "ntp im Auftrag von Harlan Stenn" <[email-masked] im Auftrag von [email-masked]> wrote:

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 2 Sep 2019 03:47:12 -0700

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

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.

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

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

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.

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

H
--

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 02 Sep 2019 12:52:50 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 02.09.2019 um 12:21 in
Nachricht
<[email-masked]>:
> higher‑level knowledge that is not part of the protocol.

Actually this description holds for NTPv4. For NTPv3 the formal description
also is like that, but the specificvation of the clock update procedure (page
27 in the PDF version of RFC 1303) says:
sys.refid ˿ peer.peeraddr

Also on page 37:
peer.refid = peer.hostaddr

And, maybe most important, what's missing in RFC 5905 is a section "Chages
from the previous version": I guess many implementations just continued to
treat the REFID as some network address...

>> good point. That is why NTP would use that "ID" instead of the IP address
to 
> identify itself. That means ntpd could find out timing loops even if they
are 
> caused by a routing loop.
>> 
>> Regards,
>>    Heiko
>> 
>> 
> 
> ‑‑ 
> http://nwtime.org ‑ be a Member!
>

---

From: Heiko Gerstung <[email-masked]>
Date: Mon, 2 Sep 2019 12:59:45 +0200

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? ;-)

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.

Best Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn: 

On 02.09.19, 12:48 "ntp im Auftrag von Harlan Stenn" <[email-masked] im Auftrag von [email-masked]> wrote:

    

    

    

    

    

    H
    --

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 2 Sep 2019 13:19:21 +0200

On Wed, Aug 28, 2019 at 03:37:03AM +0000, Karen O'Donoghue wrote:
> 1.  Network Time Protocol Extended Information Extension Field
> https://datatracker.ietf.org/doc/draft-stenn-ntp-extended-information/

I don't support adopting this draft. There are currently only two
pieces of information specified: the TAI offset and the interleaved
flag. The former would be better supported by the Daniel's
leap-seconds draft and the latter is unnecessary (as the draft notes).

> 2.  Network Time Protocol I-Do Extension Field
> https://datatracker.ietf.org/doc/draft-stenn-ntp-i-do/

I support adoption of this draft. I don't think this belongs to NTS-KE
or NTPv5 header as others have suggested. It might be possible to
determine the support by sending a request with a given extension
field and see if the server responds correctly, but with the I-Do
field that should scale better and also allow the requests and
responses to have a symmetric length.

> 3.  Network Time Protocol MAC/Last Extension Fields
> https://datatracker.ietf.org/doc/draft-stenn-ntp-mac-last-ef/

I don't support adoption of this draft. It doesn't seem to make
parsing of NTPv4 packets easier or allow them to contain shorter
extension fields.

> 4.  Network Time Protocol Suggested REFID Extension Field
> https://datatracker.ietf.org/doc/draft-stenn-ntp-suggest-refid/

I don't support adoption of this draft as it currently stands. I think
we do need a better reference ID, but it should be separate from the
refid field in the NTPv4 header. We need an ID that's independent from
IP addresses (e.g. randomly generated) and we need to detect
higher-degree loops. If the draft could be reworked in that direction,
I'd support its adoption. I don't think it should be specific to
NTPv5. It will most likely need an extension field and that can work
in both NTPv4 and NTPv5.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 2 Sep 2019 04:29:12 -0700

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

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

How do you propose getting that refid chain "downstream"?

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?

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.

When did NTS evolve to provide assertions about the intentions of the
"middle players"?

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 2 Sep 2019 13:32:11 +0200

Dear Harlan,

> decide it no longer identifies the structure/content of the fields in
I have never said that. Rather the opposite.
> 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.

> 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.
> communicate this information.  It also begs the question of *where* this

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.

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

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

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 surpression of asymmetric delays.

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.

Cheers,
Magnus

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 2 Sep 2019 04:43:15 -0700

> 27 in the PDF version of RFC 1303) says:

You mean 1305.

> peer.refid = peer.hostaddr

It doesn't hold when IPv6 enters the mix.

And while NTPv3/RFC1305  is interesting it was published in March of
1992 and the last change to the NTPv3 code was in October of 1996, and
the first development code for what would become NTPv4 was released in
September of 1997.

The first *draft* of NTPv4 happened in July of 2005, after we had put *9
years work* into the development and testing of the NTPv4 protocol,
algorithms, and codebase.  RFC5905 was published 5 years after that, at
which point we had 14 years of demonstrably working protocol,
algorithms, and code.  For those keeping count, that was 9 years ago.

Yes, we can and should make conscious, well reasoned and tested changes
in NTPv5 and beyond.

> treat the REFID as some network address...

How many implementations are we talking about?  How many of these
implementations are "significant", and what's your definition of
"significant"?

H

---

From: Heiko Gerstung <[email-masked]>
Date: Mon, 2 Sep 2019 13:49:20 +0200

On 02.09.19, 13:30 "ntp im Auftrag von Harlan Stenn" <[email-masked] im Auftrag von [email-masked]> wrote:

    

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

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.

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. 

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.

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

Email:

Connect via LinkedIn:

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 2 Sep 2019 05:08:03 -0700

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

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

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

> There is other methods, too.

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

> weak method. It will break a loop, but way too late and the collateral

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.

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

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

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

> incorrect. There is simpler methods with much better error-handling.

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

H
--

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 2 Sep 2019 05:30:07 -0700

Heiko,

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

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.

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

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

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

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

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.

---

From: Daniel Franke <[email-masked]>
Date: Mon, 2 Sep 2019 08:37:13 -0400

> should respond with a v4 packet.

If a v4 server gets a v5 packet and doesn't know anything about v5,
then how can it know that it's parsing the request correctly or
understand its semantics well enough to give a meaningful v4 reply?
Servers should not respond at all to packets with unrecognized
versions.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 2 Sep 2019 14:43:03 +0200

> incorrect. There is simpler methods with much better error-handling.

If I understand it correctly, those are not a problem of the NTPv4
format or protocol, but rather RFC 5905. I'm not sure if a new NTP
version is needed to fix that. A draft could specify that NTPv4
implementations are free to use different algorithms and models of the
clock than what is specified in RFC 5905. That would just describe the
current state. I think it was an idea for the NTPv5 specifications
that it would have no algorithms, only the message format and
protocol.

What I wanted to collect were issues that may require changes in the
format itself. Like insufficient resolution of the root delay and
dispersion, missing timescale identification, minimum length of
extension fields, etc.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 2 Sep 2019 05:52:33 -0700

> that it would have no algorithms, only the message format and

This was discussed for NTPv4 as well.

The thing is that NTP is a complete specification with a goal of time
synchronization that includes *known behavior in the face of impulse
response*.

If one uses different algorithms with different impulse response
behaviors, this can trigger oscillations and even unstable tracking (the
wheels fly off the bus).

Be careful what you wish for.

---

From: Heiko Gerstung <[email-masked]>
Date: Tue, 3 Sep 2019 09:59:03 +0200

Hi Harlan,

On 02.09.19, 14:31 "Harlan Stenn" <[email-masked]> wrote:

    Heiko,

    

I am fine with that. No objections whatsoever. 

Harlan, you can at any time implement optional EFs in ntpd, they do not need to be standardized in an RFC. If they are picked up by the users, it might happen that they are ending up in a standalone RFC later (or in v5). 

I do not want to prevent this, I want to prevent that we end up adding this and that (optional) feature to v4 and see a ton of v4 implementations, each providing a different subset of all the features. I also do not want to wait another 10 years before we start working on v5, we should shorten the release cycle to a handful of years instead, making more incremental changes to the protocol instead of introducing a new version every 20 years and keep it alive by adding optional features to it during those two decades.

I think I explained it below.

If a bad actor can abuse an upstream system, all downstream systems are toast anyway, right? But again, the InstanceID is a way to avoid that mapping and at the same time provides a unique ID for each NTP instance. 

You have a great memory. I have no idea what I did 20 years ago to be honest. But just because it was shot down 20 years ago does not mean it is useless, unreasonable or not helpful today. And it definitely does not mean that we should leave it alone because something like this has been discussed in another time and people then decided it is not worth it. 

This probably depends on the length of the InstanceID. If that ID is created in a randomized way and the random ID is long enough to make it very unlikely that two NTP instances talking to each other end up having the same ID, it can work just fine without any negotiations etc. What happens to IPv6 addresses that are hashed into 4 bytes to create a refid, what is the probability that two systems talking to each other come up with the same value? I know that a chain of 3-4 servers multiplies the chance that any two of them create the same random ID, but if we choose to have a 16byte InstanceID for example, this should be fine. 

The pool typically provides stratum 2 or 3 servers. I think that the pool especially would benefit from being able to identify that my stratum 3  pool servers A,B and C are in fact synchronized to the same stratum 1 server and therefore do not really represent a multi-source solution for my client. At the moment I do not really have a chance to find that out. If I would know, the client could re-resolve the pool dns entries until it finds 4 servers all with different stratum 1 sources.

The worst thing that can happen in the very unlikely event of two servers in a chain accidentally ending up with the same random InstanceID is that the downstream server wrongly detects a loop and rejects this reference. It would be possible to solve this by making it mandatory for an instance to recreate a new random InstanceID if all upstream servers are ruled out due to this loop detection. There are two possibilities here: if this is a false positive and there is no loop, changing my own instanceID will solve it because the upstream server will stick to its InstanceID and the resulting chain does not trigger the loop detection anymore. If it really is a loop, the chain will, after a few polling cycles, again trigger the loop detection because the new InstanceID shows up in the chain. If we add information in the chain about the polling intervals or the age of the InstanceID entries, the instance that recreated its random InstanceID could wait until it is clear that the IntanceID triggering the loop detection remains unchanged. 

    

I would not want something like a registry and I believe we do not need one. I am not sure about the dependency on an authoritative source. Can you explain why you believe that we do not need the loop detection as long as we have an authoritative source?

That's what I said. 

Well, we can only trust our direct upstream server. That server, in turn, can only trust its own upstream servers. This is a chain of trust and as I said, if I do not have any access, information or trust in any of the upstream servers of my own upstream server, I cannot assert anything. The intention of this approach/flag is to make sure that a client chooses a chain of NTS protected servers over an alternative that uses unauthenticated NTP. It would also allow the user to tell their clients to not accept any upstream source when its chain does not contain only NTS protected servers.

This is why I would like to see that a) the InstanceID is used as the RefID - but make it 16 bytes (or longer) and randomize it. This requires a change in the packet format (which was the start of this discussion). Using the InstanceID to create the chain, offering n-degree loop detection and an indication whether the upstream server relies on NTS/protected information, would be optional and can be implemented using EFs. 

I do not see unintended consequences, but that is probably the nature of unintended consequences (if you would see them, they become intended consequences). The fact that this quickly sketched InstanceID thing can lead to unwanted side effects should not hold us back from investigating this and other possible enhancements. The chance of "unintended consequences" is *always* there. You can deal with that by discussions and research. My whole point here is that we should do this. I am not married to the idea of the InstanceID and the chain and n-degree loop detection etc.  - I just believe it would improve NTP and is worthwhile to be investigated further. 

    
    
Thank you for the discussion, Harlan. It helps to point out potential problems as this allows everyone to think about a solution for that problem. 

Best Regards,
    Heiko

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn:

---

From: Hal Murray <[email-masked]>
Date: Tue, 03 Sep 2019 01:13:35 -0700

>     system should respond with a v3 packet. 

It can't.  There are fields in a NTP v3 reply that are copied from the request 
packet.  The v3 only system doesn't know how to find them in a v4 packet.

(For v3 and v4, they may be in the same place, but that may not be true for 
v5.)

---

From: Heiko Gerstung <[email-masked]>
Date: Tue, 3 Sep 2019 10:31:42 +0200

Hal, 

I believe you quoted Harlan (although I agreed to him), most probably this is caused by Outlook for Mac's incredibly bad quoting behavior... Apologies for this ...

I would think that we either carefully craft the v5 packet format in a way that the information required to create a v3/v4 response is still in the same place or, if that is not possible, face the fact that a v4 server cannot respond to a v5 request. This is, IMHO, acceptable. In this case we might change the packet format for v5 so dramatically that the most common v4 implementations will end up ignoring this request. 

But I believe it should be possible to make sure that the v5 packet format allows a v4 server to respond with a v4 packet. The location in the packet for things like the timestamps could be preserved, I guess. What else is copied from the request in v4 implementaions?

Regards,
  Heiko

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn: 

On 03.09.19, 10:21 "Hal Murray" <[email-masked]> wrote:

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 3 Sep 2019 02:05:26 -0700

> Harlan, you can at any time implement optional EFs in ntpd, they do not need to be standardized in an RFC. If they are picked up by the users, it might happen that they are ending up in a standalon…

For this to be true we'd need to fix the IANA EF table registry, and
I've been trying to do that for years.

> I do not want to prevent this, I want to prevent that we end up adding this and that (optional) feature to v4 and see a ton of v4 implementations, each providing a different subset of all the featu…

We haven't seen that many implementations yet.

And with what I'm proposing there's a clear path forward for negotiating
what EFs are supported.

Without my proposals, and with no plan in sight to fix the EF table
registry, and if you're correct that optional EFs can be implemented
without an RFC, please tell me how you forsee interoperabililty.

As for the time it takes to produce a new standard, I'm pretty sure you
won't be happy with the results you  get from the path you want to take.

I am also having difficulties understanding how you are advocating for
"more incremental changes to the protocol" in v5 while at the same time
fighting "adding optional features" to v4.

> If a bad actor can abuse an upstream system, all downstream systems are toast anyway, right? But again, the InstanceID is a way to avoid that mapping and at the same time provides a unique ID for e…

I wrote about this in my response too.  The issue goes to making sure
InstanceIDs are unique.  To do this with 100% certainty seems to require
communications between all directly participating parties along with at
least 1 more degree of "neighbors".

This seems to require a lot of traffic, with ongoing updates.

I don't think this passes the cost/benefit analysis.

We could go to UUIDs which we can *assume* are unique.  But we're also
talking about UDP packets for lots of this traffic, which have limited
payload size.

Unless you believe that there should be 2 ongoing communications streams
here, a UDP-based time sync channel and a TCP-based "ancillary
information" channel.

I don't think that passes the cost/benefit analysis, either.

> This probably depends on the length of the InstanceID. If that ID is created in a randomized way and the random ID is long enough to make it very unlikely that two NTP instances talking to each oth…

We agree that space in an NTP UDP packet is limited, right?

And the most expensive part of this scenario is when a client (which may
be a leaf, and it might be another "collection" of nodes that need to
agree on the uniqueness of InstanceIDs) joins a new group.

This initial joining is going to be the predominant case during startup,
when a clear goal is getting time synchronized quickly.

Do you see where this is going?

I'm not saying we shouldn't discuss this more, I'm just saying there are
some really difficult and intricate tradeoffs here, and I'm pretty sure
it's going to take a fair amount of time and a LOT of testing to get
something that is as robust, predictable and reliable as the protocol
and reference implementation have proven themselves to be.

> The pool typically provides stratum 2 or 3 servers. I think that the pool especially would benefit from being able to identify that my stratum 3  pool servers A,B and C are in fact synchronized to…

It's not about the pool servers - it's about the folks who *sync* with
the pool.  Are you suggesting that *all* of the members of the pool
should make sure they are using unique InstanceIDs to make it easier on
folks who connect to the pool?  If so, what would force different pool
operators to cooperate here?

And why do you think it's important to find upstream servers that sync
with different S1 sources?  There's no timing loop involved there, so
what exactly are you testing for?

At some point is it important to identify different S0 sources?  At what
level of granularity do we need to identify "time sources"?  GPS v. some
other GNSS source?  The receiver chip used?  The firmware?  The vendor
of the refclock?

> The worst thing that can happen in the very unlikely event of two servers in a chain accidentally ending up with the same random InstanceID is that the downstream server wrongly detects a loop and…

What am I missing?  Why would a downstream care if more than one of its
upstreams have the same source?  That is *not* a loop.

> I would not want something like a registry and I believe we do not need one. I am not sure about the dependency on an authoritative source. Can you explain why you believe that we do not need the l…

I was too sparse with my words.

My point is that with a registry (that has a means to authenticate
entries) we don't need to worry about more than 1 machine using the same
InstanceID.

If we don't have a registry with a validation mechanism, one other
option is to query all of the involved nodes (out to at least 1 degree
of their  involved nodes) to make sure InstanceIDs are unique.

Or we can decide that we don't care about InstanceIDs that are not
unique and sometimes collide.

Or we can find other ways to address making sure InstanceIDs are unique.

> Well, we can only trust our direct upstream server. That server, in turn, can only trust its own upstream servers. This is a chain of trust and as I said, if I do not have any access, information o…

This "protection" is not unique to NTS.  Private key can be just as
trustworthy, it just doesn't have the ephemeral negotiation that NTS
offers.  There are other choices here as well, that offer equivalent
protection.

And there are limits to what this protection "offers".

I'll note again that Daniel and some others promised that NTS would be
able to offer protection for peer associations as well, and that promise
still hasn't materialized.  This level of protection was a foundational
aspect of the plan Dave Mills submitted years ago.

If folks want robust and reliable enterprise time sources, I submit that
peer mode is an important part of that mechanism.  Peering also goes to
better behavior for loop detection/avoidance as well as for things like
orphan mode.

> This is why I would like to see that a) the InstanceID is used as the RefID - but make it 16 bytes (or longer) and randomize it. This requires a change in the packet format (which was the start of…

Do you see a way to do this with NTPv4?

We have a 3 bit version field for the packets.  I expect that a "7" in
that field will mean "version 7 or later" and that there will be a
presumably immutable base structure that will give folks access to some
other data value that will identify the actual (>6) version number.

And while NTS may be one way to do this, it should not be the *only* way
to do this.

And to do this with EFs would require folks to allow EFs to be created,
which means they'd have to start understanding that there's a difference
between mechanism and policy, and that just because somebody doesn't
agree with a policy choice doesn't mean the should not allow the
mechanism to decide if that policy choice is used or not.

> I do not see unintended consequences, but that is probably the nature of unintended consequences (if you would see them, they become intended consequences). The fact that this quickly sketched Inst…

Happy to discuss it.

And sooner or later it needs to be implemented and tested, and holding
off on that until a committee decides it's suitable advanced is, IMO,
far too late.

The other side of this is that unless these changes are carefully and
consciously made, we're going to be living with the "pollution" for a
very long time.

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 3 Sep 2019 02:12:49 -0700

> packet.  The v3 only system doesn't know how to find them in a v4 packet.

Of course it can.

We made a conscious choice to make sure the base packet format didn't
change between v3 and v4.

So there's clearly no problem in this case.

> (For v3 and v4, they may be in the same place, but that may not be true for 

I'm being kind and gentle with you here, Hal.

That would be true if we decided to change the base packet format for v5
(or later) in a way that was not backward compatible.

But even if it was a backward incompatible changes, it would fall to the
WG to justify this change and come up with a way forward.

Offhand, I can think of several ways to do this.

---

From: Heiko Gerstung <[email-masked]>
Date: Tue, 3 Sep 2019 12:34:22 +0200

OK, I was so fed up with the quoting of emails by Outlook that I put together a workaround involving a shell script, apple script and a tool that allows me to run an Applescript using a keyboard shortcut.... Nevermind, it seems to work though ..
 
I trimmed the quoted text in an attempt to make this all more readable. 
 
> On 03.09.19, 11:06 "ntp im Auftrag von Harlan Stenn" <[email-masked] im Auftrag von [email-masked]> wrote:
[...]
> I've been trying to do that for years.

I believe you can have EFs that only ntpd instances understand and let people activate them in the configuration, if they want to use them and can be sure that they are only using ntpd an no other implementation (or make sure that they do not break other implementations). 

> We haven't seen that many implementations yet.
There is a growing number of implementations, as you may have noticed. 

> And with what I'm proposing there's a clear path forward for negotiating
And I believe this is a good thing, but I do not want to see this mechanism in v4. Adding it to v5 makes it easy to make all new features mandatory for v5 (those who should not be optional of course) and does not require any negotiation because a client knows that each v5 server supports that feature set. If the client wants to use optional features, it should be able to ask the server whether it supports them or not. 
 
> without an RFC, please tell me how you forsee interoperabililty.
How interoperable was NTPv4 in the period before RFC 5905 was published? I preferred an RFC, but if people do not understand the requirement for a specific EF and do not agree that there is a such a strong demand for it that we all should start working on publishing a separate RFC for it, just implement it and let the users decide. If a lot of people start using it, you have a strong argument for adding it as a mandatory part of v5 or, if that really again takes a decade or two, come up with a separate RFC for it later. 
  
> won't be happy with the results you get from the path you want to take.
No, this is *exactly* the reason why I do not want to work on 4 separate RFCs at the same time instead of kicking of work on a v5 RFC. It will take time, it will take lots of discussions and reviews and edits,  and I would not want the working group to end up with 10 small RFCs instead of one larger one. 

> fighting "adding optional features" to v4.
I wanted to shorten the release cycle for new NTP RFCs in general from 15-20 years to maybe 5 years. That IMHO requires to limit the number of changes that go into v5. I do not think this is a problem as v4 just introduced a lot of additional things in the RFC compared to v3. If we stick to v4 and create v5 based on it plus some additional features and changes, we can probably avoid having to debate another 10 years about the v5 RFCs. This all needs to be more efficient, list all the problems and possible improvements we all see for v4, debate which of the problems we want to solve and which of the improvements we want to include as mandatory or optional in v5 (and which we do not want to include at all), then find a way to add those changes to the v4 RFC. 

[...]
> I don't think this passes the cost/benefit analysis.

Again: you do not need additional communication except for the "chain of InstanceIDs". We can create unique random InstanceIDs with an appropriate level of certainty (it might not be 100%, maybe we end up with 99.9999999999%).

> talking about UDP packets for lots of this traffic, which have limited
Oh Harlan, come on. The typical chain would consist of probably 2-5 NTP servers (I rarely seem stratum 6 servers in the wild). If a chain entry would be 4 bytes for flags etc plus 16bytes for the InstanceID, you have 20bytes per entry, 6*20 bytes = 120 bytes for a chain of 6 servers. The maximum depth of a chain is IMHO 15, resulting in 15*20=300 bytes. UDP and other headers will still keep this below 500 bytes, which is fine for a UDP packet as far as I can see.

> here, a UDP-based time sync channel and a TCP-based "ancillary
No, not for this thing.

> I don't think that passes the cost/benefit analysis, either.
I agree. 

> > This probably depends on the length of the InstanceID. If that ID is created in a randomized way and the random ID is long enough to make it very unlikely that two NTP instances talking to each other end up having the same ID, it can work just fine without any negotiations etc. >
> > What happens to IPv6 addresses that are hashed into 4 bytes to create a refid, what is the probability that two systems talking to each other come up with the same value? I know that a chain of 3-4 servers multiplies the chance that any two of them create the same random ID, 
> > but if we choose to have a 16byte InstanceID for example, this should be fine. 
> 

Sigh, see above. A chain of 15 servers (which is not very common) would be 300 bytes. Do you think this creates any problem?

> agree on the uniqueness of InstanceIDs) joins a new group.
Why? What happens in this scenario?

> when a clear goal is getting time synchronized quickly.
Yes, but why do you expect this to be a problem? 

> Do you see where this is going?
No, unfortunately not. 

> and reference implementation have proven themselves to be.
OK, agreed. If you agree we should discuss this more, let's do it. 

> > The pool typically provides stratum 2 or 3 servers. I think that the pool especially would benefit from being able to identify that my stratum 3 pool servers A,B and C are in fact synchronized to the same stratum 1 server and therefore do not really represent a multi-source solution 
> > for my client. At the moment I do not really have a chance to find that out. If I would know, the client could re-resolve the pool dns entries until it finds 4 servers all with different stratum 1 sources.
> 

It would be possible to let the pool maintainers assign (a part of) the InstanceID for each registered pool server instead of creating it randomly at each startup. The pool monitoring system could check if that assigned (part of the) InstanceID is actually used by a server, otherwise it is not allowed in the pool. Seems to be something that can easily be automated. Please note this is only required if a pool server runs v5, all the existing pool servers already out in the field do not need to care about this if they choose not to touch their configuration.
 
> what exactly are you testing for?

I would like to avoid a single source of failure and make sure that a client gets its time from different sources to be protected better against manipulations. If all your upstream servers are synchronized from one stratum 1 server, a bug or attack resulting in bad time on this stratum 1 server can end up impacting all your upstream servers and then your client. I know that those upstream servers should have multiple sources, too. But I do not know for sure and cannot tell if they do. 
 
> other GNSS source? The receiver chip used? The firmware? The vendor

Differentiating between the various hardware reference clocks and their source could be useful, too. I would certainly want to be able to identify which of my servers are using GPS, which are using Galileo and which are using GLONASS. Just like you can change the refID string for your hardware reference clocks, we could allow users to define an InstanceID for each of their refclocks with a default that represents "GPS", "GLONASS", "GALILEO" etc.. This would allow clients to choose a group of upstream servers which all have a different "root source of time", or at least as many different ones as possible. I can protect my NTP infrastructure against GPS spoofing if I can make sure that the selection of servers I use in a client is using different GNSS constellations. If the end user wants  to allow clients to identify different GPS receiver chips etc., it is possible to assign different InstanceIDs to different receiver chips, for example. You could also tackle this problem by allowing to define a chain of InstanceIDs for your hardware refclock. This would allow you to say that your server is synchronized to "GPS" via "GNSS receiver chip x", for example. Of course this would increase the theoretical maximum of entries in the InstanceID chain, but if you do not have more than 4-5 stratum levels in your infrastructure, you do not really increase the maximum UDP packet size to a point where it exceeds the UDP limit.

> upstreams have the same source? That is *not* a loop.
No, it is not a loop. But it represents a single point of failure and if you can avoid this because your clients can identify which of its upstream sources are using which root time source, why not?

[...]
> of their involved nodes) to make sure InstanceIDs are unique.
Yes, good suggestion! If, at startup, a node does not respond to incoming requests and instead first of all asks all its configured upstream sources for their "chain", it will get a list of all used InstanceIDs. By choosing one that is not included in any of the upstream chains, you can dramatically reduce the probability of a random InstanceID being accidentially used twice. Obviously, the chains only contain the *currently used* InstanceIDs, if an upstream server switches to another reference later which has the same InstanceID that you came up with, you have a collision again. 

> unique and sometimes collide.
Yes, as I proposed your instance could simply throw away its InstanceID and create a new random one, whenever it detects that its current ID is used upstream. If it is a loop, the new InstanceID will show up again in the chain after a while, if it is not a loop, you solved the situation. 

> Or we can find other ways to address making sure InstanceIDs are unique.
Yes, although I believe that the two suggestions above should be good enough.

[...]
> > Well, we can only trust our direct upstream server. That server, in turn, can only trust its own upstream servers. This is a chain of trust and as I said, if I do not have any access, information or trust in any of the upstream servers of my own upstream server, I cannot assert anything. 
> > The intention of this approach/flag is to make sure that a client chooses a chain of NTS protected servers over an alternative that uses unauthenticated NTP. It would also allow the user to tell their clients to not accept any upstream source when its chain does not contain only NTS 
> > protected servers.
> 
That's why I proposed that the flag does not say "this entry in my chain is protected by NTS", it just says that "I trust this upstream server of mine because I am reasonably sure that I can talk to it in a secure way". 

> better behavior for loop detection/avoidance as well as for things like
Not part of this discussion, therefore I take the freedom to not comment on it to avoid that this thread is getting even more messy than it already is ;-) ...

> > This is why I would like to see that a) the InstanceID is used as the RefID - but make it 16 bytes (or longer) and randomize it. This requires a change in the packet format (which was the start of this discussion). Using the InstanceID to create the chain, offering n-degree loop 
> > detection and an indication whether the upstream server relies on NTS/protected information, would be optional and can be implemented using EFs. 
> 
Not without breaking interoperability with other NTPv4 implementations that have no idea about an InstanceID.

> And while NTS may be one way to do this, it should not be the *only* way
I agree. If the version is 7, another additional version field in the v7 packet format would be required. No problem with this approach, problem solved.

> mechanism to decide if that policy choice is used or not.
No need to do this with EFs. I would prefer that the version number is defined in the base packet header, as it needs to be the first information that any receiving node requires.

> > I do not see unintended consequences, but that is probably the nature of unintended consequences (if you would see them, they become intended consequences). The fact that this quickly sketched InstanceID thing can lead to unwanted side effects should not hold us back from 
> > investigating this and other possible enhancements. The chance of "unintended consequences" is *always* there. You can deal with that by discussions and research. My whole point here is that we should do this. I am not married to the idea of the InstanceID and the chain and n-
> > degree loop detection etc. - I just believe it would improve NTP and is worthwhile to be investigated further. 
> 
> Happy to discuss it.
Great!

> off on that until a committee decides it's suitable advanced is, IMO,
I disagree. You and I know that implementation and testing resources are precious and if we can, we should avoid wasting them until we know that we agree on a feature/function.

Yes.

[...]

All the best,
    Heiko

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn:

---

From: Hal Murray <[email-masked]>
Date: Tue, 03 Sep 2019 05:05:44 -0700

[email-masked] said:
> If the system has multiple addresses, its clients may not know all of them
> and may fail to detect loops. Addresses are no good.

> protocol to exchange this ID so clients (that operate also as servers) can
> reliably detect 1-degree loops. The suggested-refid EF basically does that. 

Sorry for not being clear.

I agree with what you said.  I was trying to explore a source for an ID.  I'm 
assuming it is important to avoid collisions.  Harlan's proposal has other 
ideas tangled up in there.  I wasn't considering of them them.

I think there are two approaches.

One is to use random data.  The probability of a collision can be made 
arbitrarily small by making the number of bits in the ID big enough.  That 
needs good randomness.

The other approach is to piggyback on some other scheme that has already 
solved the problem.

Can we assume that every server will have a globally routeable IPv6 address?  
This seems slightly iffy to me, but I expect an IPv6 wizard could tell us 
about all the corner cases and it might work if we made a list of address 
ranges to not use.  IPv4 only systems add to the complications.  So does NAT.

I can't rule out that approach, but it seems like it will be complicated.

Can we assume that every server will have an Ethernet host address?  I don't 
know of any corner cases for those.  There may be some networking technologies 
where the hardware level address is assigned randomly - try again if somebody 
is using it.  We would have to avoid those.

In both cases, for multi homed servers, just pick one.  After that choice, 
it's an ID, no longer an address.

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 4 Sep 2019 11:51:11 +0200

> The other approach is to piggyback on some other scheme that has already 

The former makes more sense to me. We don't need the ID to be static.
Generating a random number on each start should be fine.

> Can we assume that every server will have a globally routeable IPv6 address?  

No. IPv6 is not universally available. Address translation is
common, so we cannot assume an IPv4 or IPv6 address is unique.

> Can we assume that every server will have an Ethernet host address?

The vast majority will, but I'm not sure we can rely on them being random.

> it's an ID, no longer an address.

Yes. And it's important that all clients get the same ID.

-- 
Miroslav Lichvar

---

From: Heiko Gerstung <[email-masked]>
Date: Wed, 4 Sep 2019 12:05:47 +0200

Using a Ethernet mac address or an IP address will allow to identify a server if it is included in the "sync chain" data set, I therefore would definitively go for a random ID. I am not yet decided if it should be allowed to let the user assign a static ID via configuration as that would make duplicates/collisions more likely than the random ID approach. 

Regards, 
    Heiko

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn:

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 04 Sep 2019 12:23:08 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 04.09.2019 um 11:51 in
Nachricht <20190904095111.GJ15024@localhost>:
> On Tue, Sep 03, 2019 at 05:05:44AM ‑0700, Hal Murray wrote:

> The vast majority will, but I'm not sure we can rely on them being random.

Hi!

Also if you specify it to be random, there won't be interpretation even if it
is not ;-)
(meaning: those who like to use a global IPv6 address could do so)
The other way round you woudn't be allowed to make it random.
Likewise as said before (for the paranoid): Don't require it to be constant
over a long time. So implementations would be allowed to change it periodically
(like once per day), each boot, each daemon restart, etc.
BTW: A new ID after a daemon restart might have the positive effect that
clients could detect that it's a "new server" (as the NTP variables are quite
different after a restart, that would even be a valid assumption)...

> Yes. And it's important that all clients get the same ID.

At least short- and mid-term. See above.

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 04 Sep 2019 12:27:10 +0200

>>> Heiko Gerstung <[email-masked]> schrieb am 04.09.2019 um 12:05
in
Nachricht <[email-masked]>:
> Using a Ethernet mac address or an IP address will allow to identify a
server 
> if it is included in the "sync chain" data set, I therefore would 
> definitively go for a random ID. I am not yet decided if it should be
allowed 
> to let the user assign a static ID via configuration as that would make 
> duplicates/collisions more likely than the random ID approach. 

It there an RFC about "Operators aren't allowed to do silly things" already?
;-)
Maybe the default (recommended setting) should be random on every daemon
start, but I do not like seemingly arbitrary restrictions...

Regards,
Ulrich

> 
> Regards, 
>     Heiko
> 
> 
> On 04.09.19, 11:52 "ntp im Auftrag von Miroslav Lichvar" 
> <[email-masked] im Auftrag von [email-masked]> wrote:
>>

---

From: Watson Ladd <[email-masked]>
Date: Wed, 4 Sep 2019 08:19:33 -0700

As someone who has far less experience of black magic I don't quite get the
problem or proposed solutions. New thread maybe?

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 9 Sep 2019 15:32:09 +0000

I think this is a very interesting idea and deserves careful thought.

Are there unique error codes in v3 and v4 that a v5 client could recognize as "you're too modern for me" ?

---

From: Daniel Franke <[email-masked]>
Date: Mon, 9 Sep 2019 11:46:28 -0400

> Are there unique error codes in v3 and v4 that a v5 client could recognize as "you're too modern for me" ?

No, but we could always introduce a new KISS code. Asking a v4 server
to know how to respond to a v5 client with an error cognizable to the
client is reasonable. But what Harlan seems to be asking, which I
think is a terrible idea, is that v4 servers be able to respond
*successfully* to v5 clients by assuming that v5 header fields are no
different from v4 header fields, thus basically locking us into old
design decisions for eternity.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 9 Sep 2019 16:08:04 +0000

So that could be a signal to the sender that the receiver does not know the version, right?

---

From: Daniel Franke <[email-masked]>
Date: Mon, 9 Sep 2019 12:18:01 -0400

> So that could be a signal to the sender that the receiver does not know the version, right?

The only thing that would really paint us into a corner would be if
there were a lot of v4 servers out there that reply to v5 packets with
something structured like a v4 packet but with a 5 in the version
field. That would create a big mess for the client to figure out
whether what it's getting back a response from a correct v5 server or
a broken v4 server. As long as v4 servers never put any version higher
than 4 in their replies, then a v5 client can interpret any v4
response as an error signal no matter whether that was what the server
intended. But it's really silly for a v4 server to attempt to reply to
a v5 request with anything but an error.

I propose we just avoid this situation entirely by making NTS a
mandatory part of v5. NTPv5 gets a separate NTS Next Protocol code
from NTPv4, so version negotiation happens during NTS-KE. And then no
correct client will ever emit a v5 time packet without already knowing
that the server supports v5.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 9 Sep 2019 20:21:49 +0000

>  is that v4 servers be able to respond
    
If that is the suggestion, I agree it is not something we should do.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 9 Sep 2019 20:25:04 +0000

That makes sense.  I support this.

---

From: Hal Murray <[email-masked]>
Date: Mon, 09 Sep 2019 13:28:57 -0700

[email-masked] said:
> But it's really silly for a v4 server to attempt to reply to a v5 request
> with anything but an error.

Agreed, but it's more complicated than that.  Error replies can be forged.

I think error handling needs more thought.

Another tangle in this area is rate-limiting.  With NAT, you can get 
legitimate traffic from many hosts funneled through one IPv4 address.

Are there any error-cases where the client should do something because the 
amount of trouble from not doing anything is higher than the amount of trouble 
from processing a forged packet?

"Amount of trouble" probably depends on whether you are the server or client.  
How should we think about that?

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 9 Sep 2019 21:25:57 -0700

Just to be thorough, I support the adoption of all 4 of these documents.

On 8/27/2019 8:37 PM, Karen O'Donoghue wrote:
> Folks,
> 
> The following four drafts are four different proposals for new extension fields. Please review each draft and indicate whether these should be adopted by the working group. I am sending them all as one set because they are all extension fields, but we need a response for each draft listed below. 
> 
> Thanks!
> Karen and Dieter
> 

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

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 10 Sep 2019 08:11:01 +0200

>>> Daniel Franke <[email-masked]> schrieb am 09.09.2019 um 17:46 in
Nachricht
> design decisions for eternity.

Yes I think the RFC for NTPv5 should place clear rules to forbid that.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 9 Sep 2019 23:24:44 -0700

On Mon, Sep 9, 2019, 11:11 PM Ulrich Windl <
[email-masked]> wrote:

> >> Are there unique error codes in v3 and v4 that a v5 client could
> recognize
> > as "you're too modern for me" ?
> >

There are quite a few v3 clients that just look at the timestamp and ignore
the other fields.

Are there compelling reasons to change the wire format in v5 and not use
extensions/NTS?  If so we should do it if not we shouldn't but the wire
format is secondary.

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 10 Sep 2019 09:25:23 +0200

>>> Watson Ladd <[email-masked]> schrieb am 10.09.2019 um 08:24 in Nachricht
> There are quite a few v3 clients that just look at the timestamp and ignore

I don't see how this is related: If a v5 server does not answer v3 queries in v5 format, that's a non-issue.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 10 Sep 2019 09:47:04 +0200

On Mon, Sep 09, 2019 at 12:18:01PM -0400, Daniel Franke wrote:
> field.

IIRC, there are few implementations that do that. openntpd is probably
the most widely used one. As a server, it just checks if the packet is
48 or 64 octets long and that the mode is 1 or 3. It doesn't support
extension fields. Sending requests with length != 48 would be a simple
way to prevent it from responding (correctly).

> mandatory part of v5.

I don't think that is a good idea. I'm sure we can figure out
something simple that doesn't require TCP or TLS. For instance, moving
the origin field in the header would prevent such broken servers from
sending a valid response.

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Tue, 10 Sep 2019 02:36:23 -0700

[email-masked] said:
> IIRC, there are few implementations that do that. openntpd is probably the
> most widely used one. As a server, it just checks if the packet is 48 or 64
> octets long and that the mode is 1 or 3. ...

What's the 64 byte case?

I'm trying to make it fit with old style shared key authentication (no 
extension field) but that's 20 or 24 bytes, 4 bytes for the key-ID and 16 or 
20 for MAC.

-----------

[email-masked] said:
> I don't think that is a good idea. I'm sure we can figure out something
> simple that doesn't require TCP or TLS. For instance, moving the origin field
> in the header would prevent such broken servers from sending a valid
> response. 

I'm looking for a way to ask a server what it supports without knowing what it 
supports.  That would be simple if we had thought about it back when designing 
version 0 of the protocol.

NTS-KE uses ALPN so you get version info as part of the TLS handshake.

But I'd like something light weight.  The complication is that we also have to 
determine if the server supports telling us what it supports.  I don't see how 
to do that in a simple clean way.  No response can mean either it doesn't 
support that packet or the server is down.  You can try something 
simpler/older to see if the server is up, but no response doesn't tell you if 
the server is down or the network is lossy.  We can probably work around that, 
but by that time it's no longer clean and simple.

We should be sure to put something like this into the v5 protocol so it will 
be there when v6 comes along.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 10 Sep 2019 12:17:19 +0200

> extension field) but that's 20 or 24 bytes, 4 bytes for the key-ID and 16 or 

You are right. I didn't look correctly. It's actually 68. It doesn't
verify the MAC and always responds with a plain 48 octet packet, so
I'm not sure what is the point of accepting such request.

-- 
Miroslav Lichvar

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Sep 2019 14:40:26 +0300

Hello, Karen,

I support the adoption of all four documents.

I will provide review for each of them.

Thanks,
Fernando

On 28/8/19 06:37, Karen O'Donoghue wrote:
> .

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 12 Sep 2019 11:46:03 +0200

> behaviors, this can trigger oscillations and even unstable tracking (the

This was discussed a bit on the last meeting.

Does anyone have an example of a PLL that is unstable when cascaded
with a different loop? If something works well enough to be stable
when synchronizing a clock of an NTP client to a stable reference
clock in different network conditions, how could it cause its own
clients to become unstable?

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 12 Sep 2019 12:15:53 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 12.09.2019 um 11:46 in
Nachricht <20190912094603.GN21704@localhost>:
> On Mon, Sep 02, 2019 at 05:52:33AM ‑0700, Harlan Stenn wrote:

I think it was the old Dave Mills consensus like: "It's only NTP if it
provides the same output for the same input". So if you think of some
improvements, they still would not be allowed (I had some discussions while
implementing PPS in the Linux kernel)

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 12 Sep 2019 04:03:19 -0700

> implementing PPS in the Linux kernel)

It's not only about instability.

It's about known and agreed-upon impulse behavior.

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 12 Sep 2019 13:16:53 +0200

> It's not only about instability.

Well, do you have any examples of instability between different
algorithms?

> It's about known and agreed-upon impulse behavior.

That doesn't seem so useful to me that it should discourage people
from implementing more advanced algorithms.

FWIW, in PTP there is no specification of how the clock should be
controlled. There is a problem with poor performance in long chains of
boundary clocks (one of the reasons why transparent clocks were
invented), but as I understand it, that is not specific to an
implementation or protocol.

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 12 Sep 2019 14:33:31 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 12.09.2019 um 13:03 in
Nachricht

> It's about known and agreed-upon impulse behavior.

But is the overshoot really well-defined NTP behavior? Are you saying that
anything that doesn't overshoot is not NTP?

---

From: Watson Ladd <[email-masked]>
Date: Thu, 12 Sep 2019 07:10:42 -0700

On Thu, Sep 12, 2019, 5:33 AM Ulrich Windl <
[email-masked]> wrote:

> >>>>> Miroslav Lichvar <[email-masked]> schrieb am 12.09.2019 um
> 11:46
> in

The problem is cascading can cause the overshoot to grow as I understand it.

---

From: Hal Murray <[email-masked]>
Date: Sun, 15 Sep 2019 23:36:49 -0700

> The vast majority will, but I'm not sure we can rely on them being random. 

They are definitely not random.  They are unique.  (unless somebody screws up)

Within a batch of Ethernet cards, they will probably be sequential.  (I'll say 
more if anybody wants.)

My handwave guess is that the chances of a collision is in the same ballpark 
as the chances of poor random numbers.

---

From: "Mark Atwood" <[email-masked]>
Date: Mon, 16 Sep 2019 15:35:25 -0700

> Within a batch of Ethernet cards, they will probably be sequential.  (I'll say 

In a past life, I've written the scripts that generate the mapping of manufacturing serial number to ethernet MAC addresses, and then generated the text files in the format requested by various manufacturing vendors so that they can fuse the MAC address into the device at manufacturing time, and so that the manufacturer and packaging vendors can print the necessary pcb labels and external case and box labels and barcodes.    And I've seen a lot of such other files that are sent to similar manufacturers.

I've never seen one that wasn't sequential.

The sequential relationship is so strong that it's used to identify supply chain and logistics glitches.

On the other other hand, you must not bet your life or your security on them being truly globally unique.   There are lots of chips in the supply chains and in warehouses that were manufactured off-label, grey market, unlicensed, and off-shift.   And anyone with kernel level or UEFI write level access to a box can persuade a chip or it's driver to lie about it's MAC.

..m

---

From: "Mark Atwood" <[email-masked]>
Date: Mon, 16 Sep 2019 15:35:25 -0700

..m

---

From: Steven Sommars <[email-masked]>
Date: Mon, 16 Sep 2019 22:05:36 -0500

Ethernet MAC addresses may be globally or locally unique; see "Ethernet LG
bit".
The same locally assigned Ethernet address may be used in hosts on
different L2 networks.

Each equipment cabinet in a project I was involved with used the same set
of local(internal to frame) MAC addresses.
Globally unique MAC addresses were unavailable.  (NTP was used.)
This worked fine, since the Ethernet layer 2 was confined within the
cabinet.

On Mon, Sep 16, 2019 at 5:35 PM Mark Atwood <[email-masked]> wrote:

> In a past life, I've written the scripts that generate the mapping of
> manufacturing serial number to ethernet MAC addresses, and then generated
> the text files in the format requested by various manufacturing vendors so
> that they can fuse the MAC address into the device at manufacturing time,
> and so that the manufacturer and packaging vendors can print the necessary
> pcb labels and external case and box labels and barcodes.    And I've seen
> a lot of such other files that are sent to similar manufacturers.
>
> On the other other hand, you must not bet your life or your security on
> them being truly globally unique.   There are lots of chips in the supply
> chains and in warehouses that were manufactured off-label, grey market,
> unlicensed, and off-shift.   And anyone with kernel level or UEFI write
> level access to a box can persuade a chip or it's driver to lie about it's
> MAC.
>
> ...m
>