Harlan Stenn st...@ntp.org wrote:
Jason Rabel writes:
There are two obvious ways to go for an embedded client.
One way would be to use the sntp code as the base.
The other would be to either use the current NTP codebase and use the
configure options to disable all the refclocks and
John Hasler writes:
I wrote:
Would it be useful to offer an official minimal implementation
intended for embedded systems so that these people won't feel the need
to code their own? Maybe add minimal NTP support to Busybox?
Brian Inglis writes:
AIUI an updated v4 sntp client will be
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Jan Ceuleers jan.ceule...@computer.org wrote:
I recommend providing motivation for the undesired clients to stop using
the server, by the server sending a regular response indicating that it
is not synchronised or replying in some other way
On Mon, Jul 07, 2014 at 07:04:01PM +0200, Jan Ceuleers wrote:
I'm not sure why sending the requester's timestamp back to him is better
than an immutable timestamp.
The effect of the former is slow drift, the effect of the latter is (I
suspect) no lock at all due to the lack of passage of
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Jan Ceuleers jan.ceule...@computer.org wrote:
I recommend providing motivation for the undesired clients to stop using
the server, by the server sending a regular response indicating that it
is not synchronised or replying in
There are two obvious ways to go for an embedded client.
One way would be to use the sntp code as the base.
The other would be to either use the current NTP codebase and use the
configure options to disable all the refclocks and anything else you
didn't want, or wait until we're done with
On 07/08/2014 12:11 PM, Jason Rabel wrote:
There are two obvious ways to go for an embedded client.
One way would be to use the sntp code as the base.
The other would be to either use the current NTP codebase and use the
configure options to disable all the refclocks and anything else you
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Harlan Stenn st...@ntp.org wrote:
Rob writes:
Jan Ceuleers jan.ceule...@computer.org wrote:
I recommend providing motivation for the undesired clients to stop using
the server, by the server sending a regular response indicating that it
Jason Rabel writes:
I do not know if this is the case with NTP, but quite often it takes
considerable hacking of sources to get code to compile on non-x86
embedded hardware (i.e. ARM MIPS)... It would probably help boost
usage if someone was assuring NTP sources compile on those platforms
Jason Rabel wrote:
I do not know if this is the case with NTP, but quite
often it takes considerable hacking of sources to get
code to compile on non-x86 embedded hardware (i.e. ARM MIPS)
... It would probably help boost usage if someone was
assuring NTP sources compile on those
Jason Rabel writes:
There are two obvious ways to go for an embedded client.
One way would be to use the sntp code as the base.
The other would be to either use the current NTP codebase and use the
configure options to disable all the refclocks and anything else you
didn't want, or
On 06/07/2014 07:42, Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Discussion appreciated.
I think it is best to remove KOD from ntpd.
It does not serve a useful purpose, because precisely the kind of
clients that you want to say goodbye to, do not support it.
In real life it has either no
detha de...@foad.co.za wrote:
There are some differences between open SMTP relays and networks not
implementing BCP38. TCP versus UDP, and to quote Paul Vixie from
https://queue.acm.org/detail.cfm?id=2578510
] ... but the big reason why SAV isn't the default is: SAV benefits only
] other
On Mon, 07 Jul 2014 07:50:16 +, Rob wrote:
detha de...@foad.co.za wrote:
The biggest problem with NTP is the amplification factor. With a 1:1 or
even 1:1.5 amplification factor, the attacker won't bother, and move to
the next target - SNMP is a good candidate. With a 1:12 or better
On 7/6/2014 2:42 AM, Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Discussion appreciated.
I think it is best to remove KOD from ntpd.
It does not serve a useful purpose, because precisely the kind of
clients that you want to say goodbye to, do not support it.
In real life it has either
I have to agree on some points with these two below. From my experience also,
using KOD usually results in more packet pounding from
bad clients (from what I can only assume is poor coding of custom clients).
The realization is that many clients don't run the standard NTP distribution,
but
Has that *always* been the case? Or has the code be changed over time?
Remember, not everyone is running the latest development (or even stable)
version of NTP...
KOD already sets a timestamp that is the requesters timestamp. See my
previous response. It's better than your idea since it is
On 7/6/2014 12:29 PM, Magnus Danielson wrote:
Detha,
On 07/06/2014 03:23 PM, detha wrote:
On Sun, 06 Jul 2014 12:28:09 +, Magnus Danielson wrote:
For cases like that, KOD won't help at all.
All the state table/KOD/filter rules mitigation approaches I have seen so
far are limited to
On 7/6/2014 7:22 AM, Jan Ceuleers wrote:
On 07/06/2014 11:23 AM, Rob wrote:
Jan Ceuleers jan.ceule...@computer.org wrote:
I recommend providing motivation for the undesired clients to stop using
the server, by the server sending a regular response indicating that it
is not synchronised or
On Mon, Jul 07, 2014 at 08:35:25AM +0100, David Taylor wrote:
Seconded.
Why remove KOD when it has to be expressly enabled (via
restrict kod and limited)?
I'd rather see a two tier system, where you can enable
the use of KOD beyond the initial rate limit, and a second limit
Danny,
On 07/07/2014 04:00 PM, Danny Mayer wrote:
On 7/6/2014 2:42 AM, Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Discussion appreciated.
I think it is best to remove KOD from ntpd.
It does not serve a useful purpose, because precisely the kind of
clients that you want to say goodbye to,
On 07/07/2014 04:10 PM, Danny Mayer wrote:
The experience with blocking has actually being negative and we have
seen traffic actually INCREASE after it is blocked because the client,
not having received a response, tries more often. This has been observed
in the wild.
This might be true for
On 07/07/2014 04:50 PM, Majdi S. Abbas wrote:
On Mon, Jul 07, 2014 at 08:35:25AM +0100, David Taylor wrote:
Seconded.
Why remove KOD when it has to be expressly enabled (via
restrict kod and limited)?
I'd rather see a two tier system, where you can enable
the use of KOD
On 7/7/2014 10:08 AM, Jason Rabel wrote:
Has that *always* been the case? Or has the code be changed over time?
I'm not sure how far back this goes. I can try and find out. I do
remember the discussion I had with Dave Mills on this but that was just
a couple of years ago. I will need to find
On 2014-07-07, Majdi S. Abbas m...@latt.net wrote:
On Mon, Jul 07, 2014 at 08:35:25AM +0100, David Taylor wrote:
Seconded.
Why remove KOD when it has to be expressly enabled (via
restrict kod and limited)?
I'd rather see a two tier system, where you can enable
the use of KOD
Danny Mayer ma...@ntp.org wrote:
On 7/6/2014 2:42 AM, Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Discussion appreciated.
I think it is best to remove KOD from ntpd.
It does not serve a useful purpose, because precisely the kind of
clients that you want to say goodbye to, do not support
Danny writes:
You haven't read the code. Any client that ignores the KOD flag will
find (if they ever looked) that their clock will be drifting away
further and further from the proper time. When KOD is set the value of
the received and sent timestamps are the same as the initial client
sent
Jason writes:
The realization is that many clients don't run the standard NTP
distribution, but rather some old hacked down / self-coded minimal NTP
/ SNTP version to run on embedded hardware. Likewise many of the
routers don't even use NTPD code with a constantly running daemon, but
rather
On 07/07/2014 04:04 PM, Danny Mayer wrote:
I have no particular preference for the immutable time stamp value to
pick. Could be zero, could be some other meaningful value (such as
0xeee4baadeee4baad - twice Eek! Bad!).
KOD already sets a timestamp that is the requesters timestamp. See my
Magnus Danielson mag...@rubidium.dyndns.org wrote:
On 07/07/2014 04:10 PM, Danny Mayer wrote:
The experience with blocking has actually being negative and we have
seen traffic actually INCREASE after it is blocked because the client,
not having received a response, tries more often. This
Would it be useful to offer an official minimal implementation
intended for embedded systems so that these people won't feel the need
to code their own? Maybe add minimal NTP support to Busybox?
Actually, Busybox does have a ntp daemon... Where the code comes from I do not
know. I've tried
Rob wrote:
All those problems were not solved by sending KOD
and some of them even not by sending no reply at all.
In fact, some of those broken clients re-try after 1-2 seconds
when you don't reply,
and when you do reply KOD they immediately re-try.
When you reply with correct time
Hi--
On Jul 7, 2014, at 2:03 PM, E-Mail Sent to this address will be added to the
BlackLists Null@BlackList.Anitech-Systems.invalid wrote:
Which product / abused NTP Server / Network / ...
immediately re-tried if they got a KOD?
I've seen that sort of misbehavior from a Lucent / Avaya PBX.
Rob writes:
Jan Ceuleers jan.ceule...@computer.org wrote:
I recommend providing motivation for the undesired clients to stop using
the server, by the server sending a regular response indicating that it
is not synchronised or replying in some other way that has no
timekeeping value to the
On 2014-07-07 10:00, John Hasler wrote:
Jason writes:
The realization is that many clients don't run the standard NTP
distribution, but rather some old hacked down / self-coded minimal NTP
/ SNTP version to run on embedded hardware. Likewise many of the
routers don't even use NTPD code with a
Jochen Bern wrote:
The straightforward approach to doing so would be to send
out not plain go DIAFs, but messages along the lines
of I'm willing to service your further requests *if*
you label them with this random ID (and behave).
More modern ntpd with the Command Line Option -I,
and /
Jason Rabel wrote:
I think the best thing to do would be to keep it simple
and not reply to a bad client...
It might make a few follow-up queries,
but eventually it would (hopefully) give up.
Broken ones might not {didn't}.
Most of the big abuse issues I read about,
no reply was one of
John Hasler wrote:
Would it be useful to offer an official minimal implementation
intended for embedded systems so that these people won't feel the
need to code their own? Maybe add minimal NTP support to Busybox?
http://wiki.openwrt.org/doc/howto/ntp.client
--
E-Mail Sent to this address
I wrote:
Would it be useful to offer an official minimal implementation
intended for embedded systems so that these people won't feel the need
to code their own? Maybe add minimal NTP support to Busybox?
Brian Inglis writes:
AIUI an updated v4 sntp client will be released to replace ntpdate.
Brian Inglis writes:
On 2014-07-07 10:00, John Hasler wrote:
Jason writes:
The realization is that many clients don't run the standard NTP
distribution, but rather some old hacked down / self-coded minimal NTP
/ SNTP version to run on embedded hardware. Likewise many of the
routers
Harlan Stenn st...@ntp.org wrote:
Discussion appreciated.
I think it is best to remove KOD from ntpd.
It does not serve a useful purpose, because precisely the kind of
clients that you want to say goodbye to, do not support it.
In real life it has either no effect at all, or it even has a
On 07/06/2014 08:42 AM, Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Discussion appreciated.
I think it is best to remove KOD from ntpd.
It does not serve a useful purpose, because precisely the kind of
clients that you want to say goodbye to, do not support it.
In real life it has
Jan Ceuleers jan.ceule...@computer.org wrote:
I recommend providing motivation for the undesired clients to stop using
the server, by the server sending a regular response indicating that it
is not synchronised or replying in some other way that has no
timekeeping value to the offending
Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Discussion appreciated.
I think it is best to remove KOD from ntpd.
It does not serve a useful purpose, because precisely the kind of
clients that you want to say goodbye to, do not support it.
In real life it has either no effect at all, or it
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
On 07/06/2014 11:23 AM, Rob wrote:
Jan Ceuleers jan.ceule...@computer.org wrote:
I recommend providing motivation for the undesired clients to stop using
the server, by the server sending a regular response indicating that it
is not synchronised or replying in some other way that has no
On 07/06/2014 12:38 PM, Terje Mathisen wrote:
Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Discussion appreciated.
I think it is best to remove KOD from ntpd.
It does not serve a useful purpose, because precisely the kind of
clients that you want to say goodbye to, do not support it.
In
On Sun, 06 Jul 2014 12:28:09 +, Magnus Danielson wrote:
On 07/06/2014 12:38 PM, Terje Mathisen wrote:
Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Discussion appreciated.
I think it is best to remove KOD from ntpd. It does not serve a useful
purpose, because precisely the kind of
Detha,
On 07/06/2014 03:23 PM, detha wrote:
On Sun, 06 Jul 2014 12:28:09 +, Magnus Danielson wrote:
For cases like that, KOD won't help at all.
All the state table/KOD/filter rules mitigation approaches I have seen so
far are limited to one server. Maybe time to take a look at a
On 2014-07-05 15:40, 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
On Sun, 06 Jul 2014 16:29:27 +, Magnus Danielson wrote:
Detha,
On 07/06/2014 03:23 PM, detha wrote:
On Sun, 06 Jul 2014 12:28:09 +, Magnus Danielson wrote:
For cases like that, KOD won't help at all.
All the state table/KOD/filter rules mitigation approaches I have seen
so far
detha de...@foad.co.za wrote:
Maybe. For the moment I think it is sufficient if we provide a mechanism
by which offenders gets reported to *some* system. We *could* also provide
a method by which white/black-list can be dynamically set from an external
source, so enough hooks exists, but I do
On Sun, 06 Jul 2014 18:51:16 +, Rob wrote:
detha de...@foad.co.za wrote:
Maybe. For the moment I think it is sufficient if we provide a
mechanism by which offenders gets reported to *some* system. We *could*
also provide a method by which white/black-list can be dynamically set
from an
On -10.01.-28163 20:59, Harlan Stenn wrote:
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?
Can't say much about KOD as-is, but here's my .02 on the net-behind-NAT
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
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
Magnus,
Yes, we know that if we decide to track finely-grained behavior we'll
need to watch how {IP,port} responds when getting {no,KOD} responses.
We might just want a syslog entry for KOD, because it's clear that there
can come a time when we don't want to rely on the remote side doing
Harlan,
On 07/06/2014 02:18 AM, Harlan Stenn wrote:
Magnus,
Yes, we know that if we decide to track finely-grained behavior we'll
need to watch how {IP,port} responds when getting {no,KOD} responses.
Just want to gently remind you.
We might just want a syslog entry for KOD, because it's
58 matches
Mail list logo
