On Wed, Apr 06, 2016 at 09:52:29PM +0000, Harlan Stenn wrote: > Miroslav Lichvar writes: > > 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?
Your draft says: A system that decides to send a Suggested REFID extension field SHOULD generate a new Suggested REFID for each new association. I'm assuming this is about client associations distinguished by IP address (ignoring the fact the multiple clients may be behind one address). If the server sends different refids to different clients, the clients won't be able to detect that they are a client of another client of the same server. Older ntpd versions had a check for that. While we may argue about how useful it really is, it will no longer be possible if the suggestion is implemented. > > 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? The cookie (aka origin timestamp) in the reply doesn't match the request. > > 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. It would complicate the selection algorithm, no doubt about that, but that's the choice of the implementation. > > 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? Yes. > Are they set up in orphan mode? No. > What would have happened if this loop had been prevented? Alarms monitoring the synchronisation would not be triggered. The servers would stay in a synchronised state with a real reference and could be used by their clients and clients of their clients for few hours until the upstream servers were reachable again. -- Miroslav Lichvar _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
