Re: Alternatives to port 123
On 2024-05-02 22:20, Hal Murray via devel wrote: I don't like adding a new top level (extra) to the config file syntax. In general, I agree with you on that. I'd keep it under nts. -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Alternatives to port 123
Richard Laager said: > Why two options that do the same thing? Thanks for asking. I meant to say something about that. I think the reason there are two is that I had a typo or such and couldn't get >extra port < to work. After banging my head against the wall for a while, I gave up and added the other one. Eventually I found the typo. Anybody got good suggestions for what to do here? Should we split things into two options? Using only nts port may not work if we have disabled NTS at configure time. Do we care about that case? I don't like adding a new top level (extra) to the config file syntax. There is already tinker, but that is all (maybe just mostly) for tweaking geeky parameters. I was looking for a friendly place for a new option. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Alternatives to port 123
On Thu, 2 May 2024, Hal Murray via devel wrote: Note that for AT, 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
Re: Alternatives to port 123
On 2024-05-02 15:48, Hal Murray via devel wrote: There are 2 new options for the config file: nts port extra port They do the same thing. Pick one. Why two options that do the same thing? -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Alternatives to port 123
I've pushed the code for alternatives to port 123. It's working for me, but could use more testing. You might hit a case I didn't consider. There are 2 new options for the config file: nts port extra port They do the same thing. Pick one. There are two parts. If a server uses either, the NTS-KE step will tell the client to use the alterante port. (Be sure your firewall lets that port in.) If a client uses either, it will send requests from the alternate port. Note that if both client and server use this feature, neither end will use port 123 so typical filtering is very unlikely to be a problem. That does require action on both ends. --- UDP port 123 filtering is still a black art, at least to me. If you had asked me a few weeks ago, I would have said that AT blocks traffic going in to UDP port 123 and traffic going out from UDP port 123. When I tested the first try at this code, it didn't work. I was testing with port 8123. Plain NTP (48 bytes) and NTP+AES (68 bytes) from a client using UDP port 123 to a server on AT using 8123 worked as expected. But NTP+NTS (232 bytes) from port 123 didn't make it in to my server. Sending from other than port 123 worked. So I added a trivial change to send from the alternate port and now it works. But note that requires changes on both ends. (I don't know where that new filtering is happening. It might be some ISP between my test client on DigitalOcean and AT) If anybody gets data on NTP blocking/filtering, please send me details. Note that for AT, the normal case of an NTP client goes through NAT so NTP isn't using port 123 and doesn't get blocked. -- We should teach the server config stuff to allow: server name:port The complication is that IPv6 literals contain colons. So we need [] around the address literal. Therer is code in libntp/decodenetnum.c that does much of the work, but it also does the DNS lookup so we would have to split that. (There is some ugly code someplace in NTS that could get cleaned up after we get that working.) -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
