[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