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

[Danny Mayer <[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. 
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.

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

Danny