The fix for NtpBug2952 was incomplete, and while it fixed one problem it created another. Specifically, it drops bad packets before updating the "received" timestamp. This means a third-party can inject a packet with a zero-origin timestamp, meaning the sender wants to reset the association, and the transmit timestamp in this bogus packet will be saved as the most recent "received" timestamp. The real remote peer does not know this value and this will disrupt the association until the association resets.

References:

http://support.ntp.org/bin/view/Main/NtpBug3453