[Ntp] Re: [EXT] [EXT] Server identifier ID Extension Field

["Windl, Ulrich" <[e-mail]>]

Hi!

First I think the algorithm suggested is not safe, as a server (client) may have to change the random ID depending on its servers (which may change) and their IDs.
Apart from that a 32-bit random number is probably not "random enough" (not talking about servers that may lack a good random source). Why not use a 64-bit (GUID) random number or a 128-bit (UUID)? 

Kind regards,
Ulrich Windl

> -----Original Message-----
> From: Danny Mayer <[e-mail]>
> Sent: Wednesday, July 15, 2026 10:41 PM
> To: [e-mail]
> Subject: [EXT] [EXT] [Ntp] Server identifier ID Extension Field
> 
> Sicherheits-Hinweis: Diese E-Mail wurde von einer Person außerhalb des UKR
> gesendet. Seien Sie vorsichtig vor gefälschten Absendern, wenn Sie auf Links
> klicken, Anhänge öffnen oder weitere Aktionen ausführen, bevor Sie die
> Echtheit überprüft haben.
> 
> On 7/15/26 9:15 AM, Miroslav Lichvar wrote:
> 
> > On Wed, Jul 15, 2026 at 11:08:29AM +0200, Giovane C. M. Moura wrote:
> >> I don't think this should be an issue for real clients -- I assume chrony
> >> and ntpd-rs, and others, bind one source port per association and
> >> keep it,
> >> so the hash is constant and a real client stays pinned.
> > chrony by default changes source port with each request. That should
> > be ok per RFC 9109. The filtering algorithm prefers measurements from
> > the closest server.
> >
> > As for the server identification, I'd be ok with a new optional
> > extension field to provide a server ID as a string, something along
> > the lines of the current draft ID.
> 
> Yes. There should be a server identifier ID extension field. This will
> allow for Loop detection as well as differentiating between servers
> coming from the same IP address.
> 
> The ID field should be a 32-bit field and if it is all zeros then it is
> not yet available to serve time.
> 
> This is what I propose.
> 
> 1. When an NTP server starts the ID needs to be set to 0.
> 
> 2. Once it is ready to serve time, it should generate a random 32-bit
> number and check to ensure that none of the servers from which it is
> getting time have that same ID. If it does it should generate a new ID
> and try again until it is different.
> 
> 3. The same server ID should be used for all outgoing packets from all
> interfaces and IP addresses. Currently you cannot tell if a packet is
> coming from different interfaces but is from the same server.
> 
> 4. For Loop detection this will enable receiving clients be able to
> differentiate the source of the packet.
> 
> 5. A MAC Extension Field should be included with the packet though that
> won't detect spoofing.
> 
> Danny
> 
> 
> 
> _______________________________________________
> ntp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]