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

[David Venhoek <[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.
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.
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.

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