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

[Ulrich Windl <[e-mail]>]

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