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
_______________________________________________
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
