[ntp:questions] Re: Public servers?

Brad Knowles brad.knowles at skynet.be
Mon Aug 4 09:31:25 UTC 2003

At 7:29 AM +0100 2003/08/04, David Woolley wrote:

>                                             For most users, fighting through
>  an ISP's support system is much more expensive than using the first
>  stratum 1 server in the public servers list (people will assume that a
>  stratum two may not be as good quality), or using a program that finds the
>  nearest NTP capable router.

	Auto-discovery tools that are not implemented client-side are not 
going to reach many users, and therefore will not be usable to most.

>  For a vendor, using USNO, which they can assume will always be there,
>  is much cheaper than providing advice to their users and leaving the
>  system unconfigured would make the product less saleable.

	I disagree.  The USNO could always decide to set up new Stratum 1 
time servers on different (unpublished) IP addresses, then contact 
their authorized time service clients (i.e., owners of certain 
specified Stratum 2 time servers) and tell them what the new IP 
address is.  Anyone other than their authorized time service clients 
should get a kiss-of-death packet.  Once that is done and a suitable 
amount of notice time passes, they set up a new server at the old IP 
address(es) which is designed to do nothing but issue kiss-of-death 

	This would really get people's attention, and vendors who 
stupidly abused them in the past would pay the price.

>  Decisions ceased to be made on the basis of anything other than "what's
>  best for me in the short term" when the internet was commercialised.

	Agreed.  This is why the old "default accept" policy should be 
eliminated, regardless of the type of service we're talking about -- 
SMTP, DNS, or NTP.  We should instead have a "default reject" policy, 
which we can then selectively open up to allow certain specific 
clients to pass through.

	Indeed, I'm also thinking that we should eliminate unicast and 
unauthenticated time servers, instead using multicast authenticated 
services exclusively.

>  Note that you cannot enforce good behaviour in a client, without heavy
>  use of intellectual property law, as market forces will result in more
>  successful competing products that are the same but without the
>  restriction.

	True enough.  This is why the security you trust must be 
implemented in the server.  The client can decide how much security 
they want to implement, if they're not sure they can trust the server.

>  (This is potentially true of kiss-of-death; there is no benefit to a mass
>  market commercial vendor in supporting that in their clients, only the
>  cost of actually finding and removing the code will stop them removing it.)

	Not true.  There is an amazingly high cost of maintaining your 
own codebase, which is what would be required if they wanted to 
remove kiss-of-death.  The least painful option for them would be to 
actually implement the access control policies as specified by the 
owners of the time servers in question, or set up their own time 
servers for their customers to use (as Apple has done, and as 
Microsoft has apparently done).

>  PS Please do not duplicate postings in email,

	Fair enough.

>                                                and if insist on doing so,
>  please don't post through a mechanism that corrupts the Message-ID, making
>  it impossible to anticipate the posting's arrival.

	That's probably a side-effect of the news gateway function 
provided by mailman.  I'm not sure that there's much we can do about 
this, but I will check with the developers for mailman to see if they 
can suggest any solutions.

>                                                     Actually, the original
>  Message-ID is an example of users doing things for ease rather than best
>  operation of the internet.  Message-IDs include the host name to define
>  the scope of uniqueness of the rest of the identity, but yours contains
>  a non-unique network 10 address, so could clash with other network 10
>  users.

	Looking at the other message-ids in this thread, I see things 
like <mailman.10.1059686736.1777.questions at ntp.org> and 
<mailman.16.1059945885.1777.questions at ntp.org>, both of which can be 
guaranteed to be unique -- they identify the domain that the message 
is passing through, the mailing list in question, the mailing list 
management software, and pretty unique strings of numbers on top of 
all that.

	I don't see anything like what you're suggesting.

Brad Knowles, <brad.knowles at skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

More information about the questions mailing list