On Tue, Apr 05, 2016 at 09:33:56PM +0000, Harlan Stenn wrote: > Sharon Goldberg writes: > > OK. To clarify: you are proposing an extension to NTP where a server > > that has multiple IP addresses can choose a special value as its > > refID, and communicate that to its clients. Then, if the clients > > choose to take time from that server, they put that special value in > > as their refID, instead of an IP address. > > My proposal for SUGGEST-REFID is simply a mechanism for an NTP instance > to tell others "If you use me as your system peer, please use <FOO> as > your refid."
I think an extension field that would allow servers to announce their own refids to clients is an excellent idea and I'm glad someone is working on it. However, I'm not sure about the intended security use case of the proposal. I'm still not convinced that hiding refid would be a major problem for an attacker. I think the number of servers that most clients use on the Internet is fairly small, it probably consist of pool.ntp.org and the list of public servers maintained on the ntp.org wiki. The attacker can probably restrict the list by geo location of the client to a country zone with few hundred of servers at most. I suspect in most cases the attacker would be able to succeed by sending spoofed packets from all these servers. If there is a security issue with clients accepting spoofed packets, I think it should be fixed directly instead of adding some security through obscurity. I'd rather see this extension field used as a way to improve the robustness of the protocol. As Danny pointed out, if servers announced the same refid to all clients, they could reliably detect multihomed hosts. My suggestion is to modify the field so it includes also refids of all upstream servers. The clients could then prevent synchronisation loops longer than 2. Loops between 3 peers polling one another can happen easily and currently the best recommendation to prevent them is to use a "line" configuration for the peers instead of a fully connected mesh. Also, if the clients knew all upstream refids, they could detect duplicate servers in the paths to the stratum 1 servers and ignore them or decrease their weight. -- Miroslav Lichvar _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
