[Ntp] Antw: [EXT] Re: Mandatory confidentiality for ntpv5

[Ulrich Windl <[e-mail]>]

>>> Martin Burnicki <martin.burnicki=[e-mail]> schrieb am
21.10.2021 um 15:33 in Nachricht
<[e-mail]>:
> Hal Murray wrote:
>> [e-mail] 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?
> 
>  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.
> 
>> 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.
> 
> 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.

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