Subject: Re: [Ntp] [[email-masked]: New Version Notification for draft-gruessing-ntp-ntpv5-requirements-02.txt]

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 14 Jun 2021 13:04:09 +0200

On Sat, May 22, 2021 at 06:31:13PM +0000, James wrote:
> URL:            https://www.ietf.org/archive/id/draft-gruessing-ntp-ntpv5-requirements-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-gruessing-ntp-ntpv5-requirements/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-gruessing-ntp-ntpv5-requirements
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-gruessing-ntp-ntpv5-requirements-02

I'd like to see this draft considered for adoption. We need to agree
on the NTPv5 requirements before we can discuss the details of the
actual protocol.

I have few comments on some specific parts of the document:

- "The specification MUST have support for servers to notify clients
   that the service is unavailable, and clients MUST have clearly
   defined behaviours honouring this signalling."

  This looks like a good goal but I suspect we may not be able to
  define a useful behavior for an unauthenticated context.

- "Leap second smearing SHOULD NOT be part of the wire specification"

  I think the protocol needs to have some way to indicate that the
  server has leap smearing enabled. Servers implementing leap smear,
  but clients not knowing about it (e.g. using its own leap second
  source) is a major concern in some environments.

- "Encryption and authentication MUST be provided by the protocol
   specification as a default"

  It's not clear to me what the default means here. That it is enabled
  by default in all implementations that support it?

-- 
Miroslav Lichvar

---

From: Dieter Sibold <[email-masked]>
Date: Mon, 14 Jun 2021 17:38:26 +0200

>   source) is a major concern in some environments.

I would prefer that leap smearing is processed on the client side only. We are going to specify the version 5. This would make the specification much cleaner and would minimize the risk of misbehavior during leap second events in infrastructures where leap smearing might be needed.

In case of NTPv4 clients the server might respond with NTPv4 packets and might also do server-side leap-smearing. But a NTPv5 client can do it itself.

> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Danny Mayer <[email-masked]>
Date: Mon, 14 Jun 2021 14:25:21 -0400

I haven't had a chance to read the draft yet, but I wanted to respond 
based on Miroslav's comments.

>    define a useful behavior for an unauthenticated context.
If this is equivalent to the NTP v4 KOD packets that's okay. I don't 
know what "unavailable" means otherwise.
>    source) is a major concern in some environments.
The protocol needs to STRONGLY indicate how they are handling leap 
seconds so that recipients can decide whether or not to use the 
timestamps being returned. There are clients who CANNOT use smeared leap 
seconds so they would need to drop the packet if it is in the smear 
mode. I have a proposal to deal with leap seconds in a more general way 
which I will send out later.
>    by default in all implementations that support it?

We should certainly NOT be doing encryption on an NTP packet? What are 
you trying to hide? Timestamps are obsolete almost before you use them 
and there is nothing confidential about them. Authentication IS 
important and should be secured by protocols like NTS or MAC's or (let 
me say it anyway!) Autokey.

Danny

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 15 Jun 2021 14:53:43 +0200

>From a clock synchronization point of view it is certainly better to
perform the leap smear on clients, but I'm not sure how practical that
is in larger networks with many different client implementations. It's
easier to configure a small number of servers than all their clients.
There would need to be some way for the servers to tell their clients
they should perform a leap smear and the smear would need to be
parametrized (e.g. time of start, smear function, duration) so they
all do it in the same way.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 15 Jun 2021 14:58:11 +0200

On Mon, Jun 14, 2021 at 02:25:21PM -0400, Danny Mayer wrote:
> We should certainly NOT be doing encryption on an NTP packet? What are you
> trying to hide? Timestamps are obsolete almost before you use them and there
> is nothing confidential about them. Authentication IS important and should
> be secured by protocols like NTS or MAC's or (let me say it anyway!)
> Autokey.

Encryption is needed for privacy. It's an NTS feature. It encrypts
cookies in server responses to prevent a passive observer from
matching client requests using the cookies.

-- 
Miroslav Lichvar

---

From: Doug Arnold <[email-masked]>
Date: Tue, 15 Jun 2021 13:29:16 +0000

I think that Miroslav is correct.  That is why it is better to have leap smearing be indicated in the NTP response message, as it is in his ntpv5 proposal. That is ugly, but not as ugly as sending a leap smear extension that some of the clients use, and some don’t.

Doug

From: ntp <[email-masked]> on behalf of Miroslav Lichvar <[email-masked]>
Date: Tuesday, June 15, 2021 at 8:54 AM
To: Dieter Sibold <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Ntp] [[email-masked]: New Version Notification for draft-gruessing-ntp-ntpv5-requirements-02.txt]

--
Miroslav Lichvar

---

From: Danny Mayer <[email-masked]>
Date: Tue, 15 Jun 2021 13:19:13 -0400

> matching client requests using the cookies.

On the cookie, it's okay as long as it's not the whole packet.

Danny