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. > 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. :) > > 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'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. 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. > > 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? > 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. > 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. -- Miroslav Lichvar _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
