Hi, Jean, On Thu, 2021-06-10 at 08:23 -0400, Jean St-Laurent wrote:
Let's start with this example. When I click sync my clock in windows, this happened.
On the inside or Private side 08:15:07.434344 IP 192.168.254.205.123 > 13.86.101.172.123: NTPv3, Client, length 48 08:15:07.473681 IP 13.86.101.172.123 > 192.168.254.205.123: NTPv3, Server, length 48
You are indeed right that the client must use UDP port 123. Is the RFC saying must or should on the client SRC port? I'm not sure.
Section 9.1 ("Peer Process Variables") of [RFC5905] SAYS: dstport: UDP port number of the client, ordinarily the NTP port number PORT (123) assigned by the IANA. This becomes the source port number in packets sent from this association. That said, as noted in https://datatracker.ietf.org/doc/html/draft-ietf-ntp-port-randomization-06#s... , other client implementations don't bind the local port to 123, and hence assign an ephemeral port.
But, on the Public, this happened. 08:15:07.434381 IP 192.2XX.XXX.58291 > 13.86.101.172.123: NTPv3, Client, length 48 08:15:07.473656 IP 13.86.101.172.123 > 192.2XX.XXX.58291: NTPv3, Server, length 48
// Public ip obfuscated. I know, it indeed starts with 192.2. It's EBOX in Canada.
What we see on the public side, is that a network device did a NAT translation of the SRC UDP port to 58921. My clock synced perfectly.
So your goal is to find the devices that don't follow this behaviour, right?
No. The goal of our I-D is that NTP clients randomize their source port -- there's no need for clients to use port 123, and using that port on the client side has negative security implications.
Thanks, -- Fernando Gont Director of Information Security EdgeUno, Inc. PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531