[ntp:questions] better rate limiting against amplification attacks?
Jochen.Bern at LINworks.de
Sun Dec 29 04:04:31 UTC 2013
Charles Elliott wrote:
> I looked up "amplification attack." [...] But the same
> website that defined amplification attack also described the solution: Use
> Is not that just one more reason to switch ntpd, nptq, and ntpdc from UDP to
> TCP for query processing?
I'ld like to make another - possibly *mostly* identical - suggestion
along more immediately relevant technical dependencies:
-- Any requests where the timing of query and answer are relevant should
use UDP (so as to keep the OS' TCP stack's packet resends out of the
-- Any requests where packets beyond "the Internet's minimum usable MTU"
(current consensus 400 Byte IIRC) may be created should use TCP (so
as to benefit from path MTU discovery without having to reimplement
-- (Corrolary: Any requests that require both assembly of a lot of data
*and* relevance of timing are a problem in and of themselves.)
-- The remainder can be distributed in such a way as to smoothen the
-- (Nonetheless, admins should be allowed to enable backward
>From the POV of amplification attacks mitigation, all challenge-response
systems should work more or less the same - whether the challenge is a
TCP sequence number, a random number, a HMAC(request,current time,PSK)
that allows well-known requestors to know the PSK beforehand and solve
the "challenge" right with the *first* request, a "normal" auth system
of NTP, or whatever.
Greg Troxel wrote:
> Do people think that simply replying to the basic time measurement
> protocol exchange is a security bug? If so, why?
(Probably not what you meant, but there are platforms where manipulating
the machines' time is a possible preparatory step for an attack - think
CA. If so, being able to read back whether that step succeeded is, of
course, helpful to the attacker.)
More information about the questions