[ntp:questions] Thoughts on KOD

Terje Mathisen terje.mathisen at tmsw.no
Sun Jul 6 10:25:29 UTC 2014


Magnus Danielson wrote:
> Harlan,
>
> On 07/05/2014 11:40 PM, Harlan Stenn wrote:
>> Folks,
>>
>> I was chatting with PHK about:
>>
>>   http://support.ntp.org/bin/view/Dev/NtpProtocolResponseMatrix
>>
>>   http://bugs.ntp.org/show_bug.cgi?id=2367
>>
>> and how we probably want to extend KOD coverage to more than just the
>> "limited" case.
>>
>> I was assuming folks would want finer-grained control over this
>> behavior, and thought about being able to choose any of kod-limited,
>> kod-noserve, and kod-query.
>>
>> PHK suggested that we consider going the other way - KOD would mean
>> "Send KODs whenever appropriate".

We want KOD generation to be at worst equally expensive as a normal 
reply, particularly for a high-performance multi-threaded/wire-speed server.

This is actually _very_ hard to do, since a default reply to a client 
request is by far the most common pattern, something that people have 
already implemented in FPGAs.

1 Gbit/s corresponds to more than a million request/reply pairs per 
second, this is just within the realm of the possible for a 
multi-core/multi-thread server where every thread can handle these 
requests autonomously, passing more complicated stuff on to a regular 
(full ntpd) backend thread. Even simple KOD processing might well slow 
this code down too much to keep up.
>>
>> I wonder what the costs/benefits will be when weighing the extra
>> complexity of "multiple choices" against "when the defaults change and
>> we get new behavior that we can't tune, that costs us in X and Y."
>>
>> This gets a bit more complicated when taking into consideration:
>>
>> - we'll get more traffic from a NAT gateway
>> - - do we need to be able to configure a threshhold for this case?
>>
>> - we should pay attention to how a client, whom we find to be abusive,
>>    reacts to:
>> - - getting no response
>> - - getting a KOD response
>>    and adapt accordingly.

Seems like an obviously good idea, but see below: Any forced extra 
processing becomes another way to DOS the ntp server.
>>
>> Discussion appreciated.
>>
>
> There is also the aspect when KOD does not "bite". We have seen that.
> Like other forms of defenses, inserting drop rules into firewall rules
> for the offending node is an alternative to consider. KOD only bites for
> nodes which follows the protocol, but somehow is offending in their
> configuration. More offensive configuration or packet generation will
> render KOD relatively useless.
>
> Thus, there might be a limit on how much effort should be going into
> perfecting KOD-generation when maybe raising the bar even further is
> needed.
>
> Then, we should also consider how KOD and drop-rule triggering can be
> used to trigger denial of service, and how to potentially protect
> against them.

This was my immediate worry:

Forcing KOD to maintain even more state per session would make it easier 
to overload the NTP server.

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



More information about the questions mailing list