On Thu, Mar 09, 2017 at 10:56:22AM -0500, Majdi S. Abbas wrote: > On Thu, Mar 09, 2017 at 03:16:57PM +0000, Moser, Stefan wrote: > > Now assume that one of the remote NTP clients turns bad, deliberately > > configures forged > > time, and enters "peer <IP_of_my_local_NTP_server>" in its ntp.conf. This > > (correct me > > if I'm wrong) creates a dynamic mobilization with my local NTP server, and > > my local > > NTP server will eventually believe in the client's (now it's a peering > > server....) time.
> The peer, even if authenticated and malacious, needs to pass all > the filtering and selection algorithms any source of time does. > Authentication authenticates the peer and the the timestamps -- it does > not assure quality of the time provided, and ntpd does not make that > assumption. Couldn't the malicious client create a larger number of ephemeral associations, using multiple IP addresses, in order to outvote good servers? To me it seems the only defense against this is the new extended keyfile format which can restrict keys to specific IP addresses. If each client had its own key and the key was restricted to one address, the client could create just one ephemeral symmetric association. Of course, if multiple clients coordinated in this attack, it would be still be a problem. The documentation clearly says the nopeer option applies only to unauthenticated packets, but it's not very clear to me what was the reason for that. Do you think it would make sense to modify its behavior to apply to both authenticated and unauthenticated packets? -- Miroslav Lichvar _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
