Miroslav Lichvar writes: > On Wed, Apr 06, 2016 at 09:11:19AM +0000, Harlan Stenn wrote: > > Miroslav Lichvar writes: > > > 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? > > Sending a packet that will be accepted by the client and disrupting > the synchronisation.
I think we're approaching a workable definition there. It depends on "accepted by the client" and "disrupting". To me, the goal of the protocol includes (and this needs more tweaking, too): - weed out flagrantly bad packets - update some core peer state data - perform thorough packet checks - if these checks pass, send the packet to the filters Even then, bogus or otherwise bad packets will get thru. The algorithms are designed to deal with these problems. > > Refclocks are increasingly easy to use, too, and this sort of > > knowledge/attack is not useful if somebody has a local refclock. > > Well, if everyone had a reliable refclock, we wouldn't need NTP. :) I notice the smiley. Even so, that's an incomplete, myopic, and insufficient oversimplication. > > > 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? > > If the implementation follows the recommendation to change the refid > randomly, a client can't detect if it's talking to the same server as > its server for instance. I'm not seeing where you think the current proposal is worse in any way. As for your response/suggestion, where is this recommendation to change the refid randomly? In the case where I suggest a refid and you choose me as your server and use my suggested refid as your system peer, even if I change this on every poll interval it will be pretty easy for me to track these random refids and still detect a loop. Yes, it means saving some state. The server suggesting the refid has control over if it uses the same refid for everybody or not, and also for how often it chooses to change its suggested refid. This is a local policy choice. Even if the client is broken and uses us as their server giving us a refid we do not understand, in that case there will be a timing loop and each poll interval the stratum on each side will increase. Eventually, these systems will either find another peer to get time from or they'll both become unsync'd (because there is no other source of time). This is no different from A noticing that B is getting its time from A, refusing to take time from B, and either getting time from somewhere else or just changing its state to unsynch'd (S16). > > > 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*. > > From how I read the draft, it seems to suggest it's a security > mechanism. The word "attacker" is used quite a few times. I'd rather > see the proposal going in the other direction, giving clients a better > view of the NTP network instead of hiding information. Yes, it's a security mechanism. And please remember that we're trying to get away from the expectation that an S2+ refid is an IPv4 address, because that is increasingly incorrect. Also note we're about to make it easy to control "who can see what", so if you want to know who my upstream server really is and you have the authorization to get that information, that would be made available thru a mode 6 query. > If you don't see the benefits, that's ok. I just thought I should > write my suggestions and see if anyone agrees with that. I wouldn't do what you and Danny are suggesting, but if you want to do things that way it's your choice - that's why I'm saying my proposal offers a mechanism, and while we'll provide a default policy choice on what that suggested refid will be, there will also be mechanism in the config file to allow you to specify your local policy on what that suggested refid will be and the circumstances under which that suggesteed refid will change. > > > 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. > > If the client is fixed to not accept spoofed packets, what exactly the > attacker can do with that information? How can anybody detect that an incoming packet has a forged source address? > > 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. > > For instance, if the client knew the same stratum 1 server is used by > multiple stratum 3 servers and they didn't agree with other sources, > they could be rejected as one assuming the stratum 1 server is bad. How would you propose this work in practice? This seems to be a special case of a Sybil attack. I think the overhead this would introduce would be huge and is better addressed elsewhere, by proper monitoring and having enough upstream servers. > > I've seen lots of mesh setups - they have all worked fine. > > I've received reports on loops forming between three peers that > were polling one another when they stopped receiving time from their > upstream sources. I was able to reproduce that. It's not a critical > issue, but I think it would be nice if NTP could prevent that. Were these 3 machines the only source of time? Are they set up in orphan mode? What would have happened if this loop had been prevented? H _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
