Alternatives to port 123

[Fred Wright]

On Thu, 2 May 2024, Hal Murray via devel wrote:

> Note that for AT&T, the normal case of an NTP client goes through NAT so 
> NTP isn't using port 123 and doesn't get blocked.

Many, if not most, NAT implementations avoid remapping "privileged" client 
ports, on the theory that specific port numbers may be required by the 
protocol (e.g. rsh).  That's why using 123 as the client port is almost 
always a bad idea, not because of blocking, but because of possible NAT 
collisions.  That's a far more important reason to avoid it than the 
really minor security benefit of "client port randomization".  Some people 
have been known to switch from classic NTP to chrony for this reason 
alone.

I'm not sure exactly how the practice originated.  In the very original 
NTP, there were no packet types, and the packet type had to be inferred 
from the combinations of source_port == 123 and dest_port ==123.  In that 
environment, using 123 as the client port was prohibited.  Once packet 
types were introduced, it was no longer prohibited, but I'm not sure how 
"not prohibited" became "normally expected"

I can think of a couple of *bad* reasons for it:

1) If one is behind a really dumb stateless firewall, then using a 
constant client port allows one to poke an appropriate hole in the 
firewall, and using the server port means only one hole rather than two. 
But a firewall that dumb would be mostly useless for today's networks.

2) It allows the same socket to be used for client and server.  But that's 
a bad idea for other reasons, anyway.


IMO, the proper fix is:

1) Add a new config parameter, possibly called "clientport".

2) If clientport !=0, then use that specific client port.

3) If clientport == 0, let the OS assign an ephemeral client port in the 
usual way.

4) Without --enable-classic-mode, default clientport to 0.

5) With --enable-classic-mode, default clientport to 123.


This would have the following properties:

1) Without --enable-classic-mode, the default behavior would be the most 
generally useful.

2) With --enable-classic-mode, the default behavior would be the same as 
it's always been.

3) In either case, the default behavior could be overridden in the config 
file if needed.


Fred Wright