Public servers abuse

2715 views
Skip to first unread message

David L. Mills

unread,
Jan 21, 2003, 4:47:35 PM1/21/03
to
Folks,

At the request of a national time standards laboratory I have removed
their NTP servers from the public lists. The timekeepers cited gross
violations of their access policy and the expense of the network
service, especially for unintended international users. As you know from
my previous grouse to this list, this is a growing problem and may well
lead to the loss of public time service altogether.

You may not have noticed it, but provisions added to recent NTP versions
includes symmetric and public key cryptography, which is my recommended
method for source authentication. It is a trivial matter to require this
for access control as well and I am preparing to do exactly this for our
public time servers and recommending it for the national laboratories.

It is to work like this. With NTPv4 you will need OpenSSL and an
encrypted identity key, as well as public/private keys you generate
yourself. We can provide the identity key by electric mail and the
password by ordinary mail. Unless you have the proper key, our servers
will respond with a kiss-of-death packet, a crypto-NAK, contrived really
bad time or no time at all. There are several cryptographic methods
already implemented in NTPv4, including one in which we can revoke
client keys individually without affecting others.

You will be asked to hold the password secret. A client can't use
another client's key without the password and every client password is
different. NTP maintains cryptographic auditing logs (cryptostats) so we
can find and prosecute villians.

You can find information on the how the schemes work and the procedures
to create and use keys in the latest NTP documentation on the web and on
the NTP project page linked from www.ntp.org. The documetns include
briefings, executive summaries and various scenario descriptions. There
is an Internet Draft now in the RFC standards pipeline that reveals the
technical model and protocol. See the citations on the NTP project page
for availability.

We will phase the crypto requirement in over a transition period of a
few months. Some of the UDel servers already support the cryptographic
means and we will be handing out trial keys on request. However, at some
future flag day we will suspend all service unless cryptographically
enabled. Our experience will no doubt be a model for the national
laboratories, who without a doubt will be forced along the same path at
some point in the future.

It will take a little while to set up administrative procedures. I will
announce when we are ready for experimental use.

Dave Mills
University of Delaware

Don Payette

unread,
Jan 21, 2003, 7:38:39 PM1/21/03
to
Thanks for the head-up.

I have written an SNTP client for our Unisys mainframe.
My client currently supports MD5 authentication only.

It appears that, sometime in the future, I might have to
support this stuff in my client. Where is the best place
to look for guidance in coding this? Would it be this:
>. . . There


>is an Internet Draft now in the RFC standards pipeline that reveals the
>technical model and protocol. See the citations on the NTP project page
>for availability.
>

-----------
Don Payette
Unisys Corporation
I speak only for myself; not my employer
Please reply in the newsgroup. Don't try
sending e-mail.

David L. Mills

unread,
Jan 21, 2003, 11:45:05 PM1/21/03
to
Don,

The latest Autokey draft is at
http://www.ietf.org/internet-drafts/draft-ietf-stime-ntpauth-04.txt.

Almost all the cryptographic means is in ./ntpd/ntp_crypto.c in the
latest distribution. Unfortunately, this version is not yet on the web
due circumstances beyond my control. Until this rock is turned, find the
latest at ftp.udel.edu/pub/ntp/software/ntp-4.1.72c.tar.gz.

Dave

Dale R Worley

unread,
Jan 22, 2003, 12:46:18 AM1/22/03
to
"David L. Mills" <mi...@udel.edu> writes:
> At the request of a national time standards laboratory I have removed
> their NTP servers from the public lists. The timekeepers cited gross
> violations of their access policy and the expense of the network
> service, especially for unintended international users. As you know from
> my previous grouse to this list, this is a growing problem and may well
> lead to the loss of public time service altogether.

Is there a quick way for people to verify that they haven't made a
mistake of this sort? Off the top of my head, verifying that one's
organization's NTP servers do not report a peer of stratum 1 would do
a good job.

> We will phase the crypto requirement in over a transition period of a
> few months.

Who is the "we" you are speaking for here? You don't seem to have
introduced them, unless you mean the unnamed "national time standards
laboratory" above. But in that case, how are the people who need to
know that the laboratory is changing its procedures to know that you
are talking about that particular laboratory?

I'm not meaning to be contentious here, but looking in from the
outside, this message wasn't as clear as it probably needs to be.

Dale

David J Taylor

unread,
Jan 22, 2003, 4:13:50 AM1/22/03
to
"David L. Mills" <mi...@udel.edu> wrote in message
news:3E2DBFF7...@udel.edu...
[]

> As you know from
> my previous grouse to this list, this is a growing problem and may well
> lead to the loss of public time service altogether.

If that happens, then we might as well scrap ntp!

David


Terje Mathisen

unread,
Jan 22, 2003, 7:49:47 AM1/22/03
to
Dale R Worley wrote:
> "David L. Mills" <mi...@udel.edu> writes:
>>We will phase the crypto requirement in over a transition period of a
>>few months.
>
> Who is the "we" you are speaking for here? You don't seem to have
> introduced them, unless you mean the unnamed "national time standards

'We' is probably all the people who take part in the ntp.hackers mail
list, and helps develop/maintain the ntp source code.

There's lots of people, I'd put Harlan Stenn, Danny Mayer, John Hay and
Ulrich Windl high on the list.

There's several others as well, with Prof. Mills on top as a sort of
benevolent dictator.

Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

Judah Levine

unread,
Jan 22, 2003, 1:15:44 PM1/22/03
to
> At the request of a national time standards laboratory I have removed
> their NTP servers from the public lists.

I am aware of the problem that David Mills is talking about, but we have no
plans to limit public access to the NIST time servers at this time. Our
network is currently handling about 9,000 requests per second with no
particular difficulties. The main problem is load balancing -- we have 14
servers, but they do not all carry an equal share of the total load. I am
implementing a load-balancing scheme to address this problem, which I hope
will be completely transparent to the user community. (If you are currently
using any of our servers in Boulder, Colorado or in Redmond, Washington, you
could help balance the load by moving to one of our other systems.)
Although we have a formal access policy, I enforce it rarely and only
against serious abusers, most of whom turn out to be ignorant rather than
malicious. Part of the reason for this laid-back attitude is that many of
our users are required to use NIST services for reasons of legal
traceability and part of the reason is that we have always been strongly
encouraged to provide as wide an access as is possible to our time and
frequency standards.
I cannot guarantee that this service model will continue forever, of course.
All NIST programs are affected by budgetary issues and by political
pressures. However, there is nothing on the horizon at the moment that would
suggest a change to our current services.

Judah Levine
Time and Frequency Division
NIST, Boulder, Colorado


Maarten Wiltink

unread,
Jan 22, 2003, 3:19:03 PM1/22/03
to
David J Taylor wrote in message ...


Or perhaps people might have to start using their ISP's
NTP servers more, or set up their own reference clocks.
Or switch to the remaining public-access servers. I don't
think there will be a _total_ loss of public time service.

It might well be considered the end of an era. Which
might be (incorrectly) viewed as cataclysmic, or simply
as reflecting on the achievement in succumbing to one's
own success.

Groetjes,
Maarten Wiltink

B.A.Baumgart

unread,
Jan 22, 2003, 4:14:15 PM1/22/03
to
Maarten Wiltink wrote in news:3e2efcb8$0$49100$e4fe...@news.xs4all.nl:

> David J Taylor wrote


>>"David L. Mills" <mi...@udel.edu> wrote

<SNIP>

>>> this is a growing problem and may well
>>> lead to the loss of public time service altogether.
>>
>>If that happens, then we might as well scrap ntp!
>
>
> Or perhaps people might have to start using their ISP's
> NTP servers more, or set up their own reference clocks.

Not all ISPs offer it. When I asked my home ISP (broadband) if they had an
NTP server I could use, they said no, and sent me off to NIST.

--
Bruce Baumgart
b...@inel.gov

Dale R Worley

unread,
Jan 22, 2003, 8:21:23 PM1/22/03
to
"B.A.Baumgart" <b...@inel.gov> writes:
> Not all ISPs offer it. When I asked my home ISP (broadband) if they had an
> NTP server I could use, they said no, and sent me off to NIST.

Always check if your next-hop router has an NTP server. And whether
ntp.<isp>.net is an NTP server.

Dale

Michael Wouters

unread,
Jan 23, 2003, 1:50:11 AM1/23/03
to
The problem we are facing is simply paying for the traffic.

A year ago, life was simple. We got about 10 packets/server/s
and this was growing linearly, or at least close to linear
over a time scale of two years. Then, something changed.
Traffic started to grow exponentially and is now at 200 packets/s.
Projecting current growth we will have another factor of 10 in about
3 months.

200 packets/s is about 1.5 GB per day or roughly $40 per day or $15000
per year. Not so frightening now, but in 3 months it will be 10 times
more.

Here are a few things I have discovered while searching for a solution
to this problem:

(1) Not responding to an NTP query can be bad. When we tried dropping packets
at the firewall, traffic went up by a factor of 50. Sending back a "port
unreachable" didn't help. We only tried this for 24 hours before giving up
and there was no sign of a decrease in the traffic. The kiss of death
gets a less violent response - traffic only goes up by 10 or 20% after
a transient period of a day or so where it initially doubles.

(2) Traffic from a large chunk of networks has continued to grow (slowly)
during the four months they have been blocked.

(3) There are at least two companies who have hard-coded the
addresses of our NTP servers into their routers/NAT boxes.
They cannot be reconfigured.

(4) 85% of our traffic comes from a mere 7000 users, polling more than
1000 times per day each. That's not many users and there's clearly
plenty of room for growth here.

Finally, a question.

Has anyone else ever closed down a busy server and watched for NTP
traffic to this over a period of time to see how it dies away ?
I would be very interested to know.

Cheers
Michael Wouters

Brian Garrett

unread,
Jan 23, 2003, 2:17:02 AM1/23/03
to

"B.A.Baumgart" <b...@inel.gov> wrote in message
news:Xns930B90D645ED...@129.250.170.81...

Had the same experience here. I called my ISP, a broadband service which
shall remain nameless <coughCoxInternetcough> and was told they had no NTP
server for their users to sync to. Since an ISP needs synchronization as
much as any other network, I figured the real answer was "we do, but damned
if WE'RE going to tell you." Sure enough, somebody here on c.p.t.n pointed
out that
ntp.cox.net was alive and well and, as it turned out, serving up fresh
helpings of accurate time. So you might check ntp.your isp'sdomain.com and
see if there's a server there.


HTH,
Brian


David J Taylor

unread,
Jan 23, 2003, 5:10:16 AM1/23/03
to
"Maarten Wiltink" <maa...@kittensandcats.net> wrote in message
news:3e2efcb8$0$49100$e4fe...@news.xs4all.nl...
[]

> Or perhaps people might have to start using their ISP's
> NTP servers more, or set up their own reference clocks.

My ISP's public ntp server is 15msec off (asymmetrical routing, I
believe).

You expect me to use that?

David


Christopher Browne

unread,
Jan 23, 2003, 8:32:39 AM1/23/03
to

For the typical user, that is likely more than satisfactory. Getting
everyone within a minute of each other would be pretty impressive;
15ms is hardly stunningly off-base.

If you truly need better than 15ms, that means your needs are "greater
than average," and you'll be one of those looking for better quality
service. That doesn't seem an outrageous outcome...
--
output = ("cbbrowne" "@acm.org")
http://www3.sympatico.ca/cbbrowne/ntp.html
Have you ever considered beating yourself with a cluestick?

David J Taylor

unread,
Jan 23, 2003, 8:42:00 AM1/23/03
to
"Christopher Browne" <cbbr...@acm.org> wrote in message
news:b0oqtn$rg3u0$2...@ID-125932.news.dfncis.de...
[]

> > My ISP's public ntp server is 15msec off (asymmetrical routing, I
> > believe).
> >
> > You expect me to use that?
>
> For the typical user, that is likely more than satisfactory. Getting
> everyone within a minute of each other would be pretty impressive;
> 15ms is hardly stunningly off-base.
>
> If you truly need better than 15ms, that means your needs are "greater
> than average," and you'll be one of those looking for better quality
> service. That doesn't seem an outrageous outcome...

I suspect I was referring to the obvious lack of care in the way the
server was set up, rather than the absolute error. I agree that 15ms is
acceptable, but not when the provider neither acknowledges nor cares about
the error. Their own routers use ntp, and my local one is only a ms or so
out, but their public ntp service is the one with the errors.

Cheers,
David


Adrian 'Dagurashibanipal' von Bidder

unread,
Jan 23, 2003, 9:01:37 AM1/23/03
to
Behold! For Brian Garrett declaimed:

> server for their users to sync to. Since an ISP needs synchronization as
> much as any other network, I figured the real answer was "we do, but damned
> if WE'RE going to tell you." Sure enough, somebody here on c.p.t.n pointed

I think it's more often the case of 'ntp? Never heard, so we can't be
offering that'. I mean, your average hotline person is not the one you'd
trust to administrate your servers...

cheers
-- vbi

Thomas Schulz

unread,
Jan 23, 2003, 10:51:22 AM1/23/03
to
In article <6de742e4.03012...@posting.google.com>,

Michael Wouters <Michael...@csiro.au> wrote:
>The problem we are facing is simply paying for the traffic.
>
>A year ago, life was simple. We got about 10 packets/server/s
>and this was growing linearly, or at least close to linear
>over a time scale of two years. Then, something changed.
>Traffic started to grow exponentially and is now at 200 packets/s.
>Projecting current growth we will have another factor of 10 in about
>3 months.
>
>200 packets/s is about 1.5 GB per day or roughly $40 per day or $15000
>per year. Not so frightening now, but in 3 months it will be 10 times
>more.
>
>Here are a few things I have discovered while searching for a solution
>to this problem:
>
>(1) Not responding to an NTP query can be bad. When we tried dropping packets
>at the firewall, traffic went up by a factor of 50. Sending back a "port
>unreachable" didn't help. We only tried this for 24 hours before giving up
>and there was no sign of a decrease in the traffic. The kiss of death
>gets a less violent response - traffic only goes up by 10 or 20% after
>a transient period of a day or so where it initially doubles.
>
>(2) Traffic from a large chunk of networks has continued to grow (slowly)
>during the four months they have been blocked.
>
>(3) There are at least two companies who have hard-coded the
> addresses of our NTP servers into their routers/NAT boxes.
> They cannot be reconfigured.

Did they really hard-code the address instead of the host name? If so,
you could change your address but keep the same name. People accessing
you by name would follow the change. To be nice you could respond to
both addresses for a month or so to allow most everyone to switch to
the new address.


>
>(4) 85% of our traffic comes from a mere 7000 users, polling more than
> 1000 times per day each. That's not many users and there's clearly
> plenty of room for growth here.
>
>Finally, a question.
>
>Has anyone else ever closed down a busy server and watched for NTP
>traffic to this over a period of time to see how it dies away ?
>I would be very interested to know.
>
>Cheers
>Michael Wouters


--
Tom Schulz
sch...@adi.com

Hal Murray

unread,
Jan 23, 2003, 12:33:02 PM1/23/03
to
Here is a (crazy?) suggestion that might help discourage
anti-social users...

How about something like the GPS Selective Availability? Dither
the bottom bits of the answer. Increase the amount of dithering
more for the more abusive users.

Turn it off for properly authenticated users. (assuming they
aren't being abusive :)

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

Hans Jørgen Jakobsen

unread,
Jan 23, 2003, 12:36:15 PM1/23/03
to
Could it be a solution to have a number of ntpservers with the same name
and ip number distributed all over the internet as is done with reverse dns
for rfc1918 addr. (see http://www.as112.net/)
/hjj

David L. Mills

unread,
Jan 23, 2003, 2:10:37 PM1/23/03
to
Terje,

In context, "we" includes the 50 or so folks listed on the copyright
page. I may use "we" to designate the 300 or so timekeepers on the
public server lists. In a fit of naughtiness I may even stoop to the
royal "we" to include me as chief sorcerer in my lab plus my sorcerer's
apprentices. I agree my use is sometimes confusing. We should be more
careful.

Who says I am benevolent?

Dave

Maarten Wiltink

unread,
Jan 23, 2003, 3:17:07 PM1/23/03
to
Dale R Worley wrote in message ...

>"B.A.Baumgart" <b...@inel.gov> writes:
>> Not all ISPs offer it. When I asked my home ISP (broadband) if they had
an
>> NTP server I could use, they said no, and sent me off to NIST.

As a matter of personal opinion, I submit that any ISP worth
their cookies offer it.


>Always check if your next-hop router has an NTP server. And whether
>ntp.<isp>.net is an NTP server.


Or perhaps ntp0, ntp1, ntp2, ...

Groetjes,
Maarten Wiltink

David L. Mills

unread,
Jan 23, 2003, 3:42:42 PM1/23/03
to
Michael,

The thing that worries me most about your experience and others reported
to this list is the growing traffic when service is denied. Rascal
rackety.udel.edu has been a loyal primary server for over 16 years. The
machine is an ancient SPARC IPC running SunOS 4.1.3, so doesn't have a
lot of horsepower. In an effort to reduce the load, about a year ago I
denied service for all but the current NTP version (4). Today, nine
packets out of ten received are dropped as violators of that restriction
and there has been no noticeable decline in that fraction. I conclude
denial of service, with and without death, goes largely unnoticed by the
clients.

It's curious you noted that the increase after denial was less with
death than with discard. This may or may not be due to the clients
actually responding to death. Death packets are purposely coded so a
client won't believe the time. But, there is an Achilles heel: the
packet is marked unsyncrhonized and with stratum zero; however, the time
values are in fact valid. While stock NTP software of any version will
disregard those packets, some other software might use them anyway.

I'm evaluating a few changes that may help contain the problem. First,
the "nopeer" restriction bit applies to all broadcast and symmetric
active packets, not just ones that might mobilize an association. Since
Bill mistakenly uses symmetric active mode, setting this bit amounts to
a Bill filter. Second, I changed the behavior of the "notrust" bit.
Previously, it denied all service; now it denies service only if the
packet is not correctly authenticated by either symmetric or public key
cryptography. This makes it possible to implement a closed client group
we plan here.

Once upon a time the "limited" restriction was effective in denying
service when too many clients from the same network ganged up on the
server. This worked well when the population was only a few hundred and
just about all the time software in the world was NTP. The measure of
success in the scheme is how old the oldest monlist entry is. If it is
at least as old as the minimum poll interval - 64s - we find joy. Now,
at least for those servers I can reach out and touch, thelist overflows
quickly and the average entry lifetime is only a few seconds.

There's another way to go about this. While the overhead to properly
maintain a large MRU list in real time may be excessive, the scheme
might work better with random replacement rather than MRU. Rather than
search and order the list for every packet, search for multiple IP
addresses say once per second and insert a timeout entry on the restrict
list, as a crypto deny restriction does now.

I'm about to implement something like the GPS Selective Availability
(SA) we knew and hated, but in a much meaner way. Perhaps the simplest
means is to set all death packet timestamp fields to zero.

This stuff will in time appear in the development version on the web.
Your comments are welcome.

Dave

mike cook

unread,
Jan 23, 2003, 4:34:41 PM1/23/03
to
Dave,

I hope some of that was a joke. I see definite signs of megalonaia
creeping in there.

It's a bit like the "war against terror" or what ever Bush and his
cronies call their flavour of the month.

It is all right to treat the symptom using autokey etc, but you ( I
say you because You are the recognised guru on the block ) aught to
be treating the CAUSE, something that Bush hasn't got the brains to
address in the other context.

Problem: For whatever reason, we all need precise globally certified
time. (independent of .gov)
Current resources:
Less than a few dozen publicly available sources.

Where is the logic in that?

Whoever runs the time show need to address that. We should be
able to put certified sources on about every block, and what is
as important, guarauntee that THE protocol doesn't get its
knickers in a twist when trading on asymetric networks.

Mike

David L. Mills

unread,
Jan 23, 2003, 7:34:59 PM1/23/03
to worm...@club-internet.fr
mike,

Once upon a time when the Internet was young and only a few dozen knew
it wasn't a volleyball club, we asked ourselves "Who runs the Internet?"
Nobody. You know that. "Whoever runs the time show...?" Nobody, You knew
that, too.

When folks start dropping of the lists, most of us get really nervous
and try to find appropriate defenses. The only thing the victim NTP
server can do is craft something that persuades the client to go away.
Sometimes the best defense is to make like a black hole. My experience
is that doesn't work. The death packet does that quite well, but only if
the client software believes it. You might not like additional less
friendly measures, but hey, that will never happen to you, right?

One would expect the answer then is to force everybody to run NTPv4,
warts and all. Yes, I know the rumors will fly that NTP is completely
broken if it jiggles the client clock bigtime, and the operator doesn't
realize why. This is a no-win win. I say again, the only widely
acceptable countermeasure is per-client cryptographic access control.

Granted, some are zombies, but there are currently 121 servers listed as
stratum 1 and 163 listed as stratum 2, somewhat more than the few dozen
you cite. Is it a terrorist campaign? I don't think so, just sloth and
ignorance and the very likely result of employee turnover.

I like your "megalonaia", which may indeed by politically applicable,
but hopefully not to me. I have indeed been accused a benevolent
dictator, but with regards your particular inventive spelling, maybe you
accuse me of spending to much time by myself.

As for "certified sources on every block," USNO and NIST both run
extensive time services and, as Judah points our, if automatic load
leveling works, maybe it will work in the wider community as well.

Dave

David L. Mills

unread,
Jan 23, 2003, 8:22:06 PM1/23/03
to
Hal,

Sometimes desperation drives me to enhance violence as you suggest. A
possible lose is that the generally naive user will conclude NTP itself
is broken and switch to something else which does not respond to death
kisses.

More constructively, there have been several prior discussions on this
frequency about NTP server servers. Our local DNS responds to a well
known host name by randomizing over a number of local servers. Let me
float an idea based on that experience.

The manycast paradigm is a really useful way for a bunch of ignorant
clients to find loving servers; however, that requires IP multicast,
which is not a ubiquitous Internet feature. The manycast paradigm is
described on the Autonomous Configuration page in the documentation. We
can, nowever, emulate that with clever unicasting.

It would work something like this. A cabal of maybe a dozen servers
would be preconfigured with each other as peers. DNS time.cabal.com
returns (some of or all of) their addresses. The client lights up
theassociations so revealed and plays manycast to prize out the best of
those servers and abandons the rest.

The problem with this is there is no way a servers can themself modulate
the replies on the basis of load leveling, for example. So, roll a
random value and compare with some kind of load indicator. The result
should be the server responds with less and less probability as the load
ramps up.

Needs work.

Dave

Ross

unread,
Jan 23, 2003, 9:27:08 PM1/23/03
to

15ms sounds pretty good; my ISP is about 60ms behind the CHU beat.
Yes, that's allowing for the ~ 9.4 ms of propagation delay :). Time
to get an Oncore.

regards,
Ross
--
Ross Alexander
(780) 975 3505 cell / (780) 433 6725 home
rale...@telusplanet.net

Robert A. Book

unread,
Jan 24, 2003, 12:47:20 AM1/24/03
to
"David L. Mills" wrote:
>
> At the request of a national time standards laboratory I have removed
> their NTP servers from the public lists. The timekeepers cited gross
> violations of their access policy and the expense of the network
> service, especially for unintended international users. As you know from
> my previous grouse to this list, this is a growing problem and may well

> lead to the loss of public time service altogether.

Prof. Mills,

Could you post a list of the servers you've removed from the list? If
you do, semi-ignorant users like me could check our ntp.conf files and
remove references to those servers immediately. I would gladly do that.

--Robert Book

David J Taylor

unread,
Jan 24, 2003, 4:56:31 AM1/24/03
to
"Ross" <r...@augly.bogons> wrote in message
news:86n0lre...@augly.bogons...

The ISP I mentioned (ntp.blueyonder.co.uk) is syncing off other NTP
servers, not a reference clock, that's why I find 15ms unusual - many
reports here have show ten times better accuracy than that. 60ms is
certainly unacceptable for an NTP referenced server, but I can see how
other references could be that much out.

Cheers,
David


Theodore Heise

unread,
Jan 24, 2003, 7:27:51 AM1/24/03
to
On Thu, 23 Jan 2003 21:17:07 +0100,
Maarten Wiltink <maa...@kittensandcats.net> wrote:
> Dale R Worley wrote in message ...
> >
> >Always check if your next-hop router has an NTP server. And whether
> >ntp.<isp>.net is an NTP server.
>
> Or perhaps ntp0, ntp1, ntp2, ...

I recently uncovered one named "time" at my ISP.

--
Theodore Heise <th...@heise.nu> West Lafayette, IN, USA

Wolfgang S. Rupprecht

unread,
Jan 24, 2003, 11:00:02 AM1/24/03
to

"David L. Mills" <mi...@udel.edu> writes:
> The manycast paradigm is a really useful way for a bunch of ignorant
> clients to find loving servers; however, that requires IP multicast,
> which is not a ubiquitous Internet feature. The manycast paradigm is
> described on the Autonomous Configuration page in the documentation. We
> can, nowever, emulate that with clever unicasting.

There is another hack you might want to consider. How about a BGP4
hack where many ntp servers are sprinkled around the world all
answering to the exact same IP address. BGP itself would work out the
shortest "distance" to each server, and magically route the packets to
the closest server. Probably you'd have to burn a /24 (or perhaps
larger) so that folks didn't drop the BGP advertisement as being too
small, but that would be a small price to pay.

-wolfgang
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/
Decoding genes for the sake of cloning is against the DMCA

(NOTE: The email address above is valid. Edit it at your own peril.)

David L. Mills

unread,
Jan 24, 2003, 1:57:27 PM1/24/03
to
Wolfgang,

Nifty idea, but most working netadmins and sysadmins I've run across
consider NTP to be an frivolous luxury and wont spend any time at all to
intall and maintain, especially to modify BGP. More important, NTP
service does not earn revenue or defray expenses, unless as in Canada
you charge for the keys.

Dave

David L. Mills

unread,
Jan 24, 2003, 1:58:46 PM1/24/03
to
Robert,

Already done; see the end of the lists.

Dave

Philip Homburg

unread,
Jan 24, 2003, 2:16:24 PM1/24/03
to
In article <3E308A33...@udel.edu>, David L. Mills <mi...@udel.edu> wrote:
>When folks start dropping of the lists, most of us get really nervous
>and try to find appropriate defenses. The only thing the victim NTP
>server can do is craft something that persuades the client to go away.
>Sometimes the best defense is to make like a black hole. My experience
>is that doesn't work. The death packet does that quite well, but only if
>the client software believes it. You might not like additional less
>friendly measures, but hey, that will never happen to you, right?
>
>One would expect the answer then is to force everybody to run NTPv4,
>warts and all. Yes, I know the rumors will fly that NTP is completely
>broken if it jiggles the client clock bigtime, and the operator doesn't
>realize why. This is a no-win win. I say again, the only widely
>acceptable countermeasure is per-client cryptographic access control.

One thing that seems to missing from the NTPv3 specification is an
exponential back-off protocol in case all peers are dead. In
retrospect, a 'do not call me again' error code would have been useful.

(I wonder if it would be possible to sue hardware/software vendors that have
hard coded NTP servers in their products without prior arrangements.)


Philip Homburg

Hal Murray

unread,
Jan 24, 2003, 4:17:19 PM1/24/03
to
>Nifty idea, but most working netadmins and sysadmins I've run across
>consider NTP to be an frivolous luxury and wont spend any time at all to
>intall and maintain, especially to modify BGP. More important, NTP
>service does not earn revenue or defray expenses, unless as in Canada
>you charge for the keys.

How much do they charge?

Could a company make money by setting up a good collection of
NTP servers with GPS clocks at various co-lo sites? Possibly
in trade for free access to customers of the host site?

those who know me have no need of my name

unread,
Jan 24, 2003, 4:59:32 PM1/24/03
to
in comp.protocols.time.ntp i read:

>In article <6de742e4.03012...@posting.google.com>,
>Michael Wouters <Michael...@csiro.au> wrote:

>>(3) There are at least two companies who have hard-coded the
>> addresses of our NTP servers into their routers/NAT boxes.
>> They cannot be reconfigured.
>
>Did they really hard-code the address instead of the host name? If so,
>you could change your address but keep the same name. People accessing
>you by name would follow the change. To be nice you could respond to
>both addresses for a month or so to allow most everyone to switch to
>the new address.

did you miss #1 ...

>>(1) Not responding to an NTP query can be bad. When we tried dropping
>>packets at the firewall, traffic went up by a factor of 50.

--
bringing you boring signatures for 17 years

David L. Mills

unread,
Jan 24, 2003, 11:50:36 PM1/24/03
to
Philip,

NTPv4 does backoff, but not exponentially, if the server becomes
unreachable. Seems I remember NTPv3 did, too, but that was so long ago
my NTPv3 neurons have lost all charge.

Dave

David L. Mills

unread,
Jan 24, 2003, 11:53:05 PM1/24/03
to Hal Murray
Hal,

I don't know. It's on their CHU web site.

Funny you should ask if a company could make money with NTP. Maybe so;
CertifiedTime tried bringing up a secure timestamping service which
involved NTP, but the company went bellyup leaving NIST holding the bag.

Dave

Philip Homburg

unread,
Jan 25, 2003, 3:22:07 AM1/25/03
to
In article <3E32179C...@udel.edu>, David L. Mills <mi...@udel.edu> wrote:
>NTPv4 does backoff, but not exponentially, if the server becomes
>unreachable. Seems I remember NTPv3 did, too, but that was so long ago
>my NTPv3 neurons have lost all charge.

In the context of independent re-implementations of the NTP protocol,
it is the contents of the RFCs that counts. A quick glance doesn't give
me anything in area, neither in RFC-1305 (NTPv3) nor in RFC-2030 (SNTPv4).
Relatively high poll rate from network devices may continue to be a problem.

Philip Homburg

David L. Mills

unread,
Jan 25, 2003, 9:08:33 AM1/25/03
to
Philip,

I have to think about this a bit. I think what you are saying is that
there is nothing in those protocol specifications to forbid or even
discourage folks from polling servers at twenty packets per second or
even two thousand packets per second. Darn, how absent of me; I should
have thought about that.

Dave

Philip Homburg

unread,
Jan 25, 2003, 4:11:16 PM1/25/03
to
In article <3E329A61...@udel.edu>, David L. Mills <mi...@udel.edu> wrote:
>I have to think about this a bit. I think what you are saying is that
>there is nothing in those protocol specifications to forbid or even
>discourage folks from polling servers at twenty packets per second or
>even two thousand packets per second. Darn, how absent of me; I should
>have thought about that.

As far as I can tell, a poll interval of 16 seconds is considered reasonable
by the RFCs. The default minimum is 64 seconds. Most of the text
suggests that the poll interval is increased (only) when a stable
(synchronization) state has achieved.

I'm not sure what kind of load the most popular NTP server can sustain.
A million machines polling once every 64 seconds probably generate more
load than most servers can tolerate.

Many RFCs (for example the ones about TCP) contain explicit instructions
about avoiding congestion and overload. I note that a discussion of
these issues is absent from the (S)NTP RFCs.

My own NTP implementation is designed for controlled environments. If it
were shipped with a hard-coded (or default) list of public NTP servers,
bad things might happen. Explicit text that discusses common failure modes
would be helpful to reduce the number of broken implementations (by
nature, most software is not far from a quick and dirty hack, it is
very unlikely that every programmer gives enough thought the scalability
issues).

Philip Homburg

Jeff W. Boote

unread,
Jan 25, 2003, 4:28:04 PM1/25/03
to
"David L. Mills" wrote:
>
> Hal,
>
> I don't know. It's on their CHU web site.
>
> Funny you should ask if a company could make money with NTP. Maybe so;
> CertifiedTime tried bringing up a secure timestamping service which
> involved NTP, but the company went bellyup leaving NIST holding the bag.

I don't know about the business model, but a company like Akamai sure
would be well positioned to provide a service like this.

jeff

Robert A. Book

unread,
Jan 26, 2003, 12:18:41 AM1/26/03
to
Thanks!

(Those are the ones listed simply as "discontinued service," right?

--Robert

David L. Mills

unread,
Jan 26, 2003, 9:10:21 AM1/26/03
to
Robert,

Should I call the "discontinued servers" something else? I thought it
was dramatically clear they have discontinued, abandoned, forfeited,
truned down, gone away, and otherwised closed doors, windows, shops and
fired the staff.

Koos van den Hout

unread,
Jan 27, 2003, 5:27:53 AM1/27/03
to
David L. Mills <mi...@udel.edu> wrote:

> Nifty idea, but most working netadmins and sysadmins I've run across
> consider NTP to be an frivolous luxury and wont spend any time at all to
> intall and maintain, especially to modify BGP. More important, NTP
> service does not earn revenue or defray expenses, unless as in Canada
> you charge for the keys.

It works for AS112 (see http://www.as112.net/). Maybe all AS112 blocks (a
/24 per location) can include a public ntp server as well. There are still
a lot of unassigned IP addresses in that block.

But.. would ntpd be able to deal with routing instabilities causing the
'nearest' AS112 IP to jump between different machines (maybe having a
different idea of time).

Koos van den Hout

--
Koos van den Hout, PGP keyid 0x27513781
ko...@cs.uu.nl herding Suns and networks
+31-30-2534104 Visit my site about books with reviews
http://idefix.net/~koos/ http://www.virtualbookcase.com/

Thomas Schulz

unread,
Jan 27, 2003, 10:13:15 AM1/27/03
to
In article <m1adhq6...@usa.net>,

I assumed that if the address was going to be abandoned completely, it
could be blocked at a higher level such as at the ISP.
--
Tom Schulz
sch...@adi.com

David L. Mills

unread,
Jan 27, 2003, 3:19:55 PM1/27/03
to
Koos,

Depending on the systematic offsets between the various servers, there
might or might not be a problem. For those expecting SNTP service and
not caring much about "little" timewarps, your suggestion would sound
just right.

Dave

Simon Lyall

unread,
Jan 28, 2003, 6:52:28 PM1/28/03
to
David J Taylor <david-...@blueyonder.co.uk> wrote:
> The ISP I mentioned (ntp.blueyonder.co.uk) is syncing off other NTP
> servers, not a reference clock, that's why I find 15ms unusual - many
> reports here have show ten times better accuracy than that. 60ms is
> certainly unacceptable for an NTP referenced server, but I can see how
> other references could be that much out.

I suspect the problem is that it's syncing off a couple of clocks on the
other side of the world. Finding a Stratum 1 clock closer would probably
help.

$ ntpq ntp.blueyonder.co.uk
ntpq> peers
remote refid st t when poll reach delay offset jitter
==============================================================================
+ntp.demon.co.uk ntp0.usno.navy. 2 u 65 256 377 1.890 12.384 2.120
+ntp0.pipex.net ntp1.NL.net 2 u 54 256 377 5.400 11.122 2.180
-ntp0.usno.navy. .USNO. 1 u 118 256 377 111.150 -0.938 9.350
*tock.usno.navy. .PSC. 1 u 24 256 377 83.390 13.862 32.030
NTP.MCAST.NET 0.0.0.0 16 - - 64 0 0.000 0.000 16000.0


--
Simon Lyall. | Newsmaster | Work: simon...@ihug.co.nz
Senior Network/System Admin | Postmaster | Home: si...@darkmere.gen.nz
ihug, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz

David J Taylor

unread,
Jan 29, 2003, 3:57:47 AM1/29/03
to
"Simon Lyall" <simon...@ihug.invalid> wrote in message
news:b1753s$kqn$1...@lust.ihug.co.nz...

Simon,

I completely agree, although it actually used to be OK, and I reported the
fault in case it actually indicated a routing problem for my ISP. Sadly,
the ISP have done nothing about it.

I did also e-mail our National Physics Laboratory who, I believe, are the
UK's timekeepers asking about the existance of any formal NTP chains in
the UK, but I got no reply to that e-mail. Today, many organisations that
were government funded research labs have to "make a profit", and perhaps
there is no profit in accurate timekeeping?

Cheers,
David


those who know me have no need of my name

unread,
Jan 30, 2003, 3:52:52 PM1/30/03
to
in comp.protocols.time.ntp i read:

[csiro has to find a way to cope with the addresses of their ntp servers
having been hard-coded into some software/devices]

>>>>(1) Not responding to an NTP query can be bad. When we tried dropping
>>>>packets at the firewall, traffic went up by a factor of 50.

>it could be blocked at a higher level such as at the ISP.

ahh, yes, involving the upstream(s) would solve that issue, at least from
csiro's (or others which are being overwhelmed) viewpoint -- i got the
impression that totally abandoning the address wasn't part of csiro's plan,
but it certainly should be considered. there's still a large, unnecessary,
increase in transmissions, which shouldn't be ignored.

Reply all
Reply to author
Forward
0 new messages