Re: [Ntp] [EXT] Re: I‑D Action: draft‑ietf‑ntp‑ntpv5‑requirements‑00.txt

[David Venhoek <[e-mail]>]

Apologies for the somewhat late replies, especially to danny's
messages. Below are responses to points raised in the previous 2 mails
from danny and the previous mail from ulrich.

On Mon, Aug 15, 2022 at 9:15 PM Danny Mayer <[e-mail]> wrote:
> > 1. A server provided identifier for logging and allow/deny listing
> > I'm not a hundred percent sure on whether we should want this in
> > NTPv5, but if we do, it seems weird to me to rule out something like
> > an FQDN since those are basically the identity building blocks on the
> > internet. If we want this name to be anything more than just something
> > the server claims about itself and want any trust-based backing for
> > it, FQDNs seem to me at least an option worth considering given the
> > existing trust infrastructure around them.
> This makes no sense. NTP is based on UDP which is both connectionless
> and stateless. There is no way to validate that something sent to you
> can be relied upon to deal with allow/deny listing. DDOS exploits take
> advantage of this to fake the from IP address. There's nothing to ensure
> that an identifier added can be trusted.
Connectionless is not neccessarily a problem from a cryptographic
point of view, see for example NTS. Especially in that context it is
definitely possible for a server to show that it has the private key
for a certificate in a way that is bound to the nts session in such a
way that replay outside of the specific nts session is not possible.
Whether we should is a secondary question, but I at least see it as
worth exploring, or at least not excluding as part of a requirements
document.

On Mon, Aug 15, 2022 at 9:15 PM Danny Mayer <[e-mail]> wrote:
> > 2. Loop detection
> > Thinking about it, I think refids are unnecessary for loop detection,
> Actually they ARE necessary. The problem has to do with the fact that
> packets can be sent out on different IP addresses and that includes
> broadcast and multicast ones.
> > and although they do accelerate rejection of some connections faster,
> > I think we can do with just the stratum mechanism for loop rejection.
>
> Nope, the most reliable result may be the one you sent out to the server
> that's sending you it's own packet.

Perhaps I was a bit unclear on what I meant with loop rejection, with
which I meant that any loop is broken in bounded time, not that it
won't form in the first place (since this seems to me to be the
strongest property ntpv4 can promise). For this specifically, refIDs
are not necessary, as without them a two server loop (which is what
refids can prevent) would cause both servers to continually increase
their stratum until one of them is stratum=16 and hence no longer
suitable for synchronization.

On Mon, Aug 15, 2022 at 10:43 PM Danny Mayer <[e-mail]> wrote:
> >>> 2. Loop detection
> >>> Thinking about it, I think refids are unnecessary for loop detection,
> >>> and although they do accelerate rejection of some connections faster,
> >>> I think we can do with just the stratum mechanism for loop rejection.
> >> If clients are allowed to synchronize to servers with equal or higher
> >> stratum (like in NTPv4), stratum alone cannot prevent a loop from
> >> forming. It can only stop one that already formed.
> > That is true, but refids only stops loops in very specific cases,
> > namely when two servers point to each other directly.
>
> No, servers have multiple interfaces and multiple ways of sending out
> packets, including multicast and broadcast as well as IPv4 and IPv6. You
> do NOT know what the server preferred for it's preferred NTP source.

I am not sure what you mean to say here? As I read the spec, a server
(or peer) sets the ReferenceID in its repsonse to be the ID (from its
perspective in the case of ntpv4, but even if we fix that just the ID)
of the server it designated as its primary time source. Furthermore, a
client (or peer) only rejects the incoming time source only if its
time source contains a ReferenceID matching (one of) its interface, so
ReferenceIDS do nothing unless there specifically is a loop of length
two, unless I am missing something.

On Mon, Aug 15, 2022 at 9:15 PM Danny Mayer <[e-mail]> wrote:
> > In general though, I think it would be worthwhile to reconsider the
> > way we require stratum to be calculated, especially in light of
> > clients potentially using an average of more than 1 server as their
> > reference. In such cases, I think rather than the current mechanism
> > (appoint 1 as "the" upstream and add 1 to its stratum) we should at
> > least consider specifying that the nodes stratum should be at least 1
> > higher than the largest stratum of a server which it "used" (in the
> > sense that it directly influenced steering, rather than just
> > truth-finding) in synchronization. Similar updates should probably
> > also be considered around path-length/error estimates included in the
> > information send by an NTP server. Wording of both however is going to
> > be somewhat tricky in light to the loosening (which we definitely
> > should keep in my opinion) on algorithms.
>
> That's what a server should be doing. It's always 1 higher than it's
> chosen server. I don't think that this is clear enough in RFC5905.
On Mon, Aug 15, 2022 at 10:43 PM Danny Mayer <[e-mail]> wrote:
> > Any other
> > configuration with a loop still needs to rely on stratum to eliminate
> > the loop. Furthermore, something like a refid for indicating source of
> > time only really works when there is a clear single source, which even
> > in ntpv4 seems unlikely when following guidance in the spec.
> > (everything seems aimed at averaging from multiple remotes) That
> > combined with the potential trouble around getting a good value for
> > this field seems to me a reason to at least look critically at if we
> > really need it (and not paint ourselves into a corner by explicitly
> > requiring it in the requirements document).
> NTP does NOT average multiple sources. It analyzes and then select which
> one is providing the best source of time. stratum is only on of the
> criteria used to decide.

Both of these seem to rely on the same mistaken idea that NTPv4 per
the spec requires a single time source to which the eventual error in
local time is calculated. They do not. Section 11.2.3 specifies a
combine algorithm which (as far as I have been able to decipher from
reading it and the related code samples) specifies an averaging
procedure on the peers left after the earlier selection phases, which
averages the time offset to those peers to give the best estimated
offset THETA and related variables.

On Tue, Aug 16, 2022 at 9:48 AM Ulrich Windl
<[e-mail]> wrote:
> > In general though, I think it would be worthwhile to reconsider the
> > way we require stratum to be calculated, especially in light of
> > clients potentially using an average of more than 1 server as their
> > reference. In such cases, I think rather than the current mechanism
> > (appoint 1 as "the" upstream and add 1 to its stratum) we should at
> > least consider specifying that the nodes stratum should be at least 1
> > higher than the largest stratum of a server which it "used" (in the
> > sense that it directly influenced steering, rather than just
> > truth-finding) in synchronization. Similar updates should probably
>
> Well, so what would be the definition of the stratum then? I'm not convinced:
> Using a pool, a client/server may sync to a stratum-1, but could also be
> accepting contributions from stratum-2 or stratum-3 servers.
> Should it be stratum-4 then? Or is the root dispersion enough?
> What would be an example for a sync-loop where a client/server just
> incremented the reference stratum by one?

For me, such a server (assuming those stratum 2 and 3 servers
contribute in the algorithm of section 11.2.3 or something similar,
and not just in selection algorithms) would indeed be stratum 4. In
other words, I would very much prefer stratum to provide an upper
bound on the path length from the server to a "ground truth" source of
time.

That is because from a loop rejection standpoint (which to me at least
seems to be the major purpose for stratum at least right now) taking
another value could lead to problematic situations. For example,
consider a network of time servers consisting of servers R, A, B and
C. R is a stratum 1 server, and each of servers A, B and C synchronize
to all servers except themselves in the network. Suppose now that each
has server R as their primary upstream server, and its contribution is
weighted .4 in their THETA average, with a .3 contribution coming from
each of the other servers in the set ABC. Then if only R is considered
for stratum calculation, then these servers will be stratum 2, even
though their local clock is majority constructed from stratum 2
servers, and in fact is majority from loops! (clock drift should
eventually fix this problem in that at some point one of the servers
switches away from R because of disagreement with the other servers,
but this (in my opinion) shouldn't be relied on)

On Tue, Aug 16, 2022 at 9:48 AM Ulrich Windl
<[e-mail]> wrote:
> > also be considered around path-length/error estimates included in the
> > information send by an NTP server. Wording of both however is going to
> > be somewhat tricky in light to the loosening (which we definitely
> > should keep in my opinion) on algorithms.
>
> Don't the error estimates consider all the contributing sources already?

True, my bad, I think I just meant to say that the wording for these
may be challenging when we loosen algorithms, but that is of separate
concern.

On Tue, Aug 16, 2022 at 9:48 AM Ulrich Windl
<[e-mail]> wrote:
>
> >>> David Venhoek <[e-mail]> schrieb am 12.08.2022 um 16:26 in
> Nachricht
> <CAPz_-SX8iE0aaS8vyQF1oH4mcZ5K3OqT5kmjnWUd-CeB=[e-mail]>:
> > Given the comments on the refid and its uses and desires around it, I
> > think it would be good to rework that section of the requirements
> > document somewhat.
> >
> > As I can tell, there seem to be two desires here, each of which has
> > different requirements. Perhaps we should reformulate (and even split)
> > this section to better reflect the two desires here. If i have some
> > time this weekend I will try to make a suggestion via the drafts
> > github repo.
> >
> > Going into the nitty gritty for discussion right now, I see the
> > following two parts to the future of refids:
> >
> > 1. A server provided identifier for logging and allow/deny listing
> > I'm not a hundred percent sure on whether we should want this in
> > NTPv5, but if we do, it seems weird to me to rule out something like
> > an FQDN since those are basically the identity building blocks on the
> > internet. If we want this name to be anything more than just something
> > the server claims about itself and want any trust-based backing for
> > it, FQDNs seem to me at least an option worth considering given the
> > existing trust infrastructure around them.
>
> It seems FQHN was considered to be an "Internet UUID" in the past.
> Somewhat later (domain selling is common nowadays) that the FQHN may be time
> based to be unique (Type "iqn." (iSCSI Qualified Name)).
> So maybe define the expected lifetime of an ID: During server lifetime (i.e.:
> uptime), software lifetime (i.e.: specific compile of the NTP software), or
> server lifetime (i.e. lifetime of the hardware or the software installation),
> or lifetime of the Internet address assignment (IP address/domain).
>
> > 2. Loop detection
> > Thinking about it, I think refids are unnecessary for loop detection,
> > and although they do accelerate rejection of some connections faster,
> > I think we can do with just the stratum mechanism for loop rejection.
>
> Maybe ref-IDs just make manual debugging and tracing easier.
>
> > In general though, I think it would be worthwhile to reconsider the
> > way we require stratum to be calculated, especially in light of
> > clients potentially using an average of more than 1 server as their
> > reference. In such cases, I think rather than the current mechanism
> > (appoint 1 as "the" upstream and add 1 to its stratum) we should at
> > least consider specifying that the nodes stratum should be at least 1
> > higher than the largest stratum of a server which it "used" (in the
> > sense that it directly influenced steering, rather than just
> > truth-finding) in synchronization. Similar updates should probably
>
> Well, so what would be the definition of the stratum then? I'm not convinced:
> Using a pool, a client/server may sync to a stratum-1, but could also be
> accepting contributions from stratum-2 or stratum-3 servers.
> Should it be stratum-4 then? Or is the root dispersion enough?
> What would be an example for a sync-loop where a client/server just
> incremented the reference stratum by one?
>
> > also be considered around path-length/error estimates included in the
> > information send by an NTP server. Wording of both however is going to
> > be somewhat tricky in light to the loosening (which we definitely
> > should keep in my opinion) on algorithms.
>
> Don't the error estimates consider all the contributing sources already?
>
> Regards,
> Ulrich
>
>
> >
> > Kind regards,
> > David
> >
> > On Mon, Aug 1, 2022 at 11:03 AM Ulrich Windl
> > <[e-mail]> wrote:
> >>
> >> >>> Danny Mayer <[e-mail]> schrieb am 31.07.2022 um 00:04
> in
> >> Nachricht <[e-mail]>:
> >>
> >> > On 7/26/22 5:52 AM, James wrote:
> >> >> David,
> >> >> Thanks for taking a look, you're definitely asking in the right place.
> >> >>
> >> >> Answers in‑line.
> >> >>
> >> >>> On 26 Jul 2022, at 10:50, David Venhoek <[e-mail]> wrote:
> >> >>>
> >> >>> Dear James, All,
> >> >>>
> >> >>> Having taken a look through this latest draft, I have several
> >> >>> questions regarding some of the proposed requirements:
> >> >>>
> >> >>> Regarding the server identifiers for use by the peer identified as
> >> >>> needed in section 3.1, what would the purpose of these identifiers be?
> >> >> JG: The purpose is to have capability to identify servers without
> tightly
> >> > coupling to their FDQN/IP address(es) etc, allowing clients to implement
> >> > allow/deny lists, logging/monitoring etc. One of NTPv4's flaws is the
> tight
> >>
> >> > coupling of refid to host, which in part leads to traffic management
> >> issues.
> >> >
> >> > No, it has nothing to do with that. This is needed for loop detection
> >> > and prevention. The refid is actually rather loosely coupled to a host.
> >>
> >> The main issue is that multihomed hosts can have multiple refids that way.
>
> > See
> >> the NTP bugzilla.
> >> There's also another issue when peers are manually configured, that does
> not
> >> prevent corresponding hosts to be found via multicast (.ACST.) and
> > associated a
> >> second time that way.
> >>
> >> Example:
> >>  # ntpq -p
> >>      remote           refid      st t when poll reach   delay   offset
> >> jitter
> >>
> >
> =============================================================================
> > =
> >> ...
> >> #h18.domain.org  172.20.2.25      2 s   13   64   77    0.166   +1.217
> >> 0.268
> >> ...
> >> -h18.domain.org  172.20.2.25      2 u  171  128    7    0.150   +0.928
> >> 0.028
> >> ...
> >>
> >> > Currently the refid in the packet is basically the IP address the packet
> >> > that the upstratum server used was sent out on that the server receiving
> >> > it saw. With multiple IP addresses and broadcast and multicast packets
> >> > being sent from the same system this is a poor way to detect loops.
> >>
> >> Correct.
> >>
> >> >
> >> >>> With respect to provisions for NAT, what specifically are the issues
> >> >>> that NAT is causing with current NTPv4 deployments?
> >> >> JG: Not all requirements are based on known existing problems with
> NTPv4.
> >> > Some requirements in the document (like this and the one below) are
> >> > explicitly mentioned to remind us that they should be covered. NTPv5
> should
> >>
> >> > not incidentally make things worse for deployments, and NAT in general
> >> > doesn't make things easier :(
> >> > It's not clear from your statement what you think that the protocol can
> >> > do about NAT's. They're opaque and the clients behind the NAT won't have
> >> > unique post‑NAT addresses.
> >>
> >> The problem is that from remote those NATs look like multiple NTP servers
> >> running on the same host, but using the same REFID.
> >>
> >> >>> What is the reason for wanting a larger rollover timescale for NTPv5?
> >> >>> I have done a number of tests with rollover scenarios recently with
> >> >>> NTPd and a new implementation, and when implementing the wrapping
> >> >>> arithmetic as specified rollover seems to me a non‑issue. It didn't
> >> >>> cause any issues as far as I could tell in the NTP client/server.
> >> >> JG: If we're changing the data model that represents time within NTP to
> >> > support things like linear timescales (and possibly even changing things
> >> like
> >> > epoch) then this is another explicit requirement to cover. You're right
> the
> >>
> >> > current data model is good for a long time (provided implementations
> don't
> >> > skip over implementing era numbers).
> >> > You shouldn't be changing the data model. Changing the timescale does
> >> > not change that and would only affect the calculations in how you do
> >> > arithmetic on the timestamps.
> >> >>> Finally, in section 3.7, the requirement of injectable hardware
> >> >>> timestamps without modification of authentication/confidentiality
> >> >>> seems at odds to me with the larger security goals, as in such a
> >> >>> scenario the hardware timestamper is acting exactly as a man in the
> >> >>> middle. Do we have any ideas on how that could be achieved in a secure
> >> >>> way?
> >> >> JG: The point is that middleboxes must not overwrite authenticated data
> in
> >> a
> >> > packet as the trust is between the client and server, not the box in
> >> between.
> >> > If middleboxes want to include authenticated timestamps and provide the
> >> > information to verify them, then the protocol should probably support
> that
> > ‑
> >>
> >> > but from what I've heard so far folks don't seem to be interested in it
> as
> >> > middleboxes are more common in protected private networks than on "big
> I"
> >> > internet.
> >>
> >> I think "middleboxes" would add more problems than they solve.
> >>
> >> > Hardware timestamps cannot be authenticated since they won't be able to
> >> > fix up a MAC or other authentication mechanism. Tal and I had a
> >> > discussion on this when he wrote RFC7821, which you should read.
> >>
> >> If they know the keys, why not? But I still think it's a bad idea (like
> >> breaking up TLS encryption to examine the streams for undesired contents).
> >>
> >> Regards,
> >> Ulrich
> >>
> >> >
> >> > Danny
> >> >
> >> > _______________________________________________
> >> > ntp mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/ntp
> >>
> >>
> >>
> >
> > _______________________________________________
> > ntp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ntp
>
>
>