Miroslav Lichvar writes: > 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.
How do you define "the attacker would be able to succeed" in this case? Refclocks are increasingly easy to use, too, and this sort of knowledge/attack is not useful if somebody has a local refclock. I don't know how valid it is to assume your geo location claim. Finally, if an attacker is going after somebody's servers that means the "victim" will be getting unsolicited responses, and we now alert on that case. There are other protections against these attacks in the current codebase, too. > 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. What do you suggest? How does the current proposal make things worse in any way? > I'd rather see this extension field used as a way to improve the > robustness of the protocol. Huh? I think you are conflating things here. The proposal is a *mechanism* and the value it contains is *policy*. > As Danny pointed out, if servers announced > the same refid to all clients, they could reliably detect multihomed > hosts. Then all a bad guy has to do is to send a time request to a target, see what refid it gets, and then use that knowledge as an attack vector. Also, there has been no demonstrated benefit that this "wider scope" loop detection will be of any useful value. > 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. Can you demonstrate tangible problems with the current scheme and tangible benefit with your solution? Please also consider the security ramifications. I've seen lots of mesh setups - they have all worked fine. H _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
