Subject: Re: [Ntp] Mandatory confidentiality for ntpv5

From: Hal Murray <[email-masked]>
Date: Thu, 21 Oct 2021 04:36:35 -0700

[email-masked] said:
> How much of the packet would be encrypted?
> If it's fully encrypted, how could a NIC find out that an incoming packet is
> an NTP packet that may need to be timestamped (if timestamping of NTP packets
> is supported at all)? 

Why not have the NIC timestamp everything and let the driver discard the ones 
that the client software desn't want?

I assume there is some good reason or you wouldn't have asked the question.

How does current NIC firmware decide which packets to time stamp?

Are you using "timestamp" in the PTP sense of modify the packet?  I don't know 
how to do that with encrypted data.  I was thinking of "timestamp" in the 
sense of SO_TIMESTAMP.

-- 
These are my opinions.  I hate spam.

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 21 Oct 2021 15:33:27 +0200

> that the client software desn't want?

 From what I've yet heard from kernel developers, collecting data in 
which no one is interested would be too expensive.

In my opinion this is similar to multicast: if a consumer is interested, 
it tells in *what* it is interested, and only the requested information 
is provided.

> How does current NIC firmware decide which packets to time stamp?

I#m not familiar with too many different NICs, but I know that some have 
a hard-coded pattern e.g. for PTP packets, and others have a 
configurable packet matcher, to which you can download a specific pattern.

Anyway, as far as I know, you would have problems to detect the network 
packets that are to be timestamped if the packets are fully encrypted.

And, similar to the topic above, IMO it would be too expensive to 
timestamp all packets and drop most of them in which no NTP or PTP 
daemon is interested.

> how to do that with encrypted data.  I was thinking of "timestamp" in the

See above. It would be hard to even *detect* the packets that need to be 
timestamped, regardless whether you try to put the timestamp into the 
encrypted packet (which isn't possible, of course) or make it available 
in a different way.

Lately I haven't been too much involved in the PTP stuff, but from the 
past I remember that it was also important at which point/bit the 
timestamp is taken when it comes in and passes along the packet matcher.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [email-masked]
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 21 Oct 2021 17:37:46 +0200

On Thu, Oct 21, 2021 at 03:33:27PM +0200, Martin Burnicki wrote:
> I#m not familiar with too many different NICs, but I know that some have a
> hard-coded pattern e.g. for PTP packets, and others have a configurable
> packet matcher, to which you can download a specific pattern.

The hardware that has L4 PTP-specific timestamping that I have
experimented with seems to check for UDP port 319 and 320, and that
the PTP message type is between 0 and 3, or it is one specific value
(this is useful for server-only or client-only configurations).
Interestingly, it doesn't seem to match in the upper range of
(currently unspecified) event messages (4-7), so I suspect PTP might
be stuck with the existing four types unless it's willing to break
compatibility with existing hardware.

> packets that are to be timestamped if the packets are fully encrypted.

Right.

> And, similar to the topic above, IMO it would be too expensive to timestamp
> all packets and drop most of them in which no NTP or PTP daemon is
> interested.

I think it's more about being able to save the actual timestamps. Some
hardware has only a small number of registers for receive timestamps,
so the rate of the timestamping has to be limited by timestamping only
messages that need it (i.e. PTP event messages). Other hardware can
provide a timestamp for every received packet, which just wastes a bit
of the PCIe bandwidth.

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 22 Oct 2021 09:59:18 +0200

>>> Martin Burnicki <martin.burnicki=[email-masked]> schrieb am
21.10.2021 um 15:33 in Nachricht
> encrypted packet (which isn't possible, of course) or make it available 

Hi!

I think the real problem is that some layer-4 (or higher) requests time stamping, that is done at layer-2 (NIC hardware), and must be stored on layer-4 (or higher) again (if it were kept in layer-2, it would be lost at the next router). Obviously encrypting the payload (layer-4 or higher) makes things hard to impossible.

Regards,
Ulrich
...