[ntp:questions] Thoughts on KOD
terje.mathisen at tmsw.no
Sun Jul 6 10:25:29 UTC 2014
Magnus Danielson wrote:
> On 07/05/2014 11:40 PM, Harlan Stenn wrote:
>> I was chatting with PHK about:
>> 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
> 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.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
More information about the questions