RE: NAT devices not translating privileged ports

[Jean St-Laurent via NANOG <nanog () nanog org>]

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.

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?

Jean


-----Original Message-----
From: Fernando Gont <fernando.gont () edgeuno com> 
Sent: June 10, 2021 7:09 AM
To: jean () ddostest me; nanog () nanog org
Subject: Re: NAT devices not translating privileged ports

Hi, Jean,

On Thu, 2021-06-10 at 06:54 -0400, Jean St-Laurent via NANOG wrote:
> Hi Fernando,
>
> NTP sounds simple but it could be very complex when you dig deep down 
> and/or get lost in details.
> Here are 2 things to consider:
>
> 1. NTP clients can query NTP servers by using SRC UDP ports > 1024. 

This is indeed the case we're addressing. The NTP spec mandates srt port=123, even for client-to-server cases.