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"
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
