Re: NTP, possible solutions, and best implementation

[Robert E. Seastrom]

"Nathan J. Mehl" <[EMAIL PROTECTED]> writes:

> > This is a Stratum 0 source so once placed behind a Unix/Cisco/Juniper
> > box you have a stratum 1 source.   This will cost you 30,000 -> 
> > 100,000 US per unit.   The beam tube will require replacement
> > approx every 5 years for about 20,000 US.
> 
> They only cost that much new-in-box. :)
> 
> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2560947055&category=25399

The device Nathan references above is a bunch of isolation amplifiers
in a box, used to distribute a standard timing signal to a number of
users without mutual interference to the pulse shape from the end-user
equipment.  It does not contain a primary frequency standard, but has
connections for up to three external references (which are hopefully
running in lockstep :).

While it's true that HP 5061B and 5071 Cs beam frequency standards are
available for far less than the list prices quoted above, they're not
available in working condition on eBay for $350.  :) I think last time
I checked refurbished tubes for the 5061B were a $5-7k proposition.

As others have noted, CDMA-disciplined NTP clocks such as those from
EndRun are indirectly disciplined by GPS in the vast majority of
cases.  It would probably be more honest to configure them to claim to
be stratum 2 NTP servers, but don't tell the marketing folks that;
they'll pitch a fit.

With GPS based NTP appliances, one must pay attention not only to the
manufacturer of the box, but to the actual manufacturer of the GPS
module inside the box.  In years past the Motorola VX and UT OEM
modules have been included by more than one player as the "guts" of
the machine.

Other likely sources are WWV/WWVH (2.5, 5, 10, 15, 20 mhz; medium term
jitter can be problematic due to propagation changes), WWVB (60 khz,
less jitter than WWV, but can be hard to receive ih a high-rfi
commercial environment), CHU (3330, 7335, 14670 khz if you prefer a
Canadian shortwave time/frequency service), DCF77 (for Europe, not too
useful in North America),

Loran-C is of limited life expectancy, and NIST is planning to cease
involvement with time code signals on the GOES satellites after 1
January 2005 (although the birds will continue to provide the
timecode, NIST will no longer be controlling and checking the signal).
Therefore, it's probably not a good idea to make future plans based on
either of these services (although equipment to implement them
short-term may be available at bargain prices!)

The following links may be of interest:

http://tycho.usno.navy.mil/
http://www.boulder.nist.gov/timefreq/
http://www.ntp.org/

---rob

Re: NTP, possible solutions, and best implementation

[Nathan J. Mehl]

In the immortal words of Scott McGrath ([EMAIL PROTECTED]):
> 
> 1 - Purchase a Cesium clock this is a Primary Time/Frequency standard 
> which does not require access to a reference standard to maintain 
> accuracy.
> 
> This is a Stratum 0 source so once placed behind a Unix/Cisco/Juniper
> box you have a stratum 1 source.   This will cost you 30,000 -> 
> 100,000 US per unit.   The beam tube will require replacement
> approx every 5 years for about 20,000 US.

They only cost that much new-in-box. :)

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2560947055&category=25399

-n

<[EMAIL PROTECTED]>
"`For Shame' isn't history; it's a rant -- another in a seemingly endless
parade of dumb books lamenting `the dumbing of America.'"   (--David Futrelle)

Re: NTP, possible solutions, and best implementation

[Marshall Eubanks]

On Fri, 03 Oct 2003 09:59:59 -0700
 Owen DeLong <[EMAIL PROTECTED]> wrote:
> 

I used to work with GPS navigation / calibration. The entire system is 
designed to "free wheel" for at least a month, and probably many months,
giving adequate performance 
even if all the ground control stations were destroyed. The only thing
I would worry about (besides failures of my own equipment) would be that
roof access might be blocked (say if debris fell on the roof), and thus
the signal could not be acquired, for some period of time.

Selective availability (SA, the jittering of the clocks on the public signal)
introduced timing errors only at the level of 100 
nanoseconds. If you need timing better than that, you should worry 
(a little) about having a backup time source, in case SA gets turned back
on in a dire national emergency.

Regards
Marshall Eubanks
> >> Derating GPS wouldn't affect the time reference functionality. Turning
> >> off GPS entirely would seriously affect military aviation operations.
> >
> > Not so:
> >
> > "Selective Availability (SA) is the deliberate introduction of error by
> > either altering the precise timekeeping of GPS satellites or the position
> > of the satellites in space, through the on-board software, thereby
> > reducing both positioning and timing accuracy for civilian users."
> >
> > GPS accuracy is generally reduced by adding noise to the timing. Now you
> > would have to derate GPS pretty significantly before timing accuracy would
> > be significantly affected. But it's possible that some time references
> > would refuse to lock on at all with sufficient derating. The affects of
> > more extreme derating than SA are, at least to some extent, unknown.
> >
> While this is true, the derating in common practice for SA when it was 
> turned
> on actually turned out to be somewhat less inaccurate than the combination
> of atmospheric error and other issues in most GPS-based time sources.  For
> NTP, network jitter would exceed SA jitter in most implementations.
> 
> >> > Aviators try very, very hard not to trust their lives to GPS.
> >
> >> As opposed to LORAN ?
> >
> > Generally, aviators don't like SPOFs. So they try very hard not to trust
> > their life to any one thing. GPS is used in conjunction with VORs,
> > pilotage (navigation by reference to fixed objects), and dead reckoning.
> >
> Pilotage is _VERY_ difficult in IMC.  Most IFR pilots don't rely much on
> pilotage most of the time, and almost never attempt pilotage in IMC.
> It is true that most of them use VORs and RADAR as their primary 
> navigational
> backups under IFR in IMC.
> 
> > GPS is used for instrument approaches, but only under extremely
> > controlled conditions by very experienced pilots. A significant fraction
> > of instrument training is how to cross-check instruments and detect
> > failures. GPS approaches are individually approved by the FAA and factors
> > such as runway lighting are critical. FAA approved GPS units must be used
> > and one of the things these GPS units must do is monitor signal integrity
> > (RAIM). From time to time, you will read FAA accident reports of people
> > who attempted to perform GPS approaches with just a handheld GPS.
> >
> Excuse me?  GPS is used for instrument approaches by virtually any
> instrument rated pilot.  A pilot can conduct a GPS approach solo with
> as little as 75 hours of PIC experience (35 hours part 141 private
> course and 40 hours instrument training) (14CFR parts 61 and 141).
> I would not consider a pilot with 75 hours or even 100 hours "very
> experienced".  Heck, I have over 650 hours and I don't consider myself
> "very experienced".  I haven't looked back at my logbook to be sure, but,
> if memory serves, I got my instrument rating at about 225 hours, and,
> shot my first solo GPS approach with around 250 hours of PIC experience.
> 
> You are right that a significant portion of instrument training is how
> to cross-check instruments and detect failures.  Mostly, however, this
> focuses on failures of instruments related to keeping the airplane
> right-side up.  Some cursory coverage is given to detecting navigational
> failurres, but, as much as I try to behave differently, and, as much
> as I wish this weren't true, the primary mode of navigational failure
> detection employed by most IFR pilots I've met is when the controller
> says "Where the heck are you going?" (no, this isn't from the Pilot
> Controller glossary, nor is it how they usually convey that message).
> 
> It is true that to begin a GPS approach, you must have an approach
> certified (TSO'd) unit in an installation that the FAA FSDO has
> signed off as an approach capable installation.  It's also true that
> you need RAIM, and, RAIM provides a certain amount of integrity more
> than standard GPS and more than ILS.  (Actually ILS glide-slope only
> failues are the ones that scare me the most as an IFR pilot).
> 
> I'm not saying the system is unsafe.  I think 

RE: NTP, possible solutions, and best implementation

[Owen DeLong]

Derating GPS wouldn't affect the time reference functionality. Turning
off GPS entirely would seriously affect military aviation operations.
	Not so:

"Selective Availability (SA) is the deliberate introduction of error by
either altering the precise timekeeping of GPS satellites or the position
of the satellites in space, through the on-board software, thereby
reducing both positioning and timing accuracy for civilian users."
GPS accuracy is generally reduced by adding noise to the timing. Now you
would have to derate GPS pretty significantly before timing accuracy would
be significantly affected. But it's possible that some time references
would refuse to lock on at all with sufficient derating. The affects of
more extreme derating than SA are, at least to some extent, unknown.
While this is true, the derating in common practice for SA when it was 
turned
on actually turned out to be somewhat less inaccurate than the combination
of atmospheric error and other issues in most GPS-based time sources.  For
NTP, network jitter would exceed SA jitter in most implementations.

> Aviators try very, very hard not to trust their lives to GPS.

As opposed to LORAN ?
Generally, aviators don't like SPOFs. So they try very hard not to trust
their life to any one thing. GPS is used in conjunction with VORs,
pilotage (navigation by reference to fixed objects), and dead reckoning.
Pilotage is _VERY_ difficult in IMC.  Most IFR pilots don't rely much on
pilotage most of the time, and almost never attempt pilotage in IMC.
It is true that most of them use VORs and RADAR as their primary 
navigational
backups under IFR in IMC.

GPS is used for instrument approaches, but only under extremely
controlled conditions by very experienced pilots. A significant fraction
of instrument training is how to cross-check instruments and detect
failures. GPS approaches are individually approved by the FAA and factors
such as runway lighting are critical. FAA approved GPS units must be used
and one of the things these GPS units must do is monitor signal integrity
(RAIM). From time to time, you will read FAA accident reports of people
who attempted to perform GPS approaches with just a handheld GPS.
Excuse me?  GPS is used for instrument approaches by virtually any
instrument rated pilot.  A pilot can conduct a GPS approach solo with
as little as 75 hours of PIC experience (35 hours part 141 private
course and 40 hours instrument training) (14CFR parts 61 and 141).
I would not consider a pilot with 75 hours or even 100 hours "very
experienced".  Heck, I have over 650 hours and I don't consider myself
"very experienced".  I haven't looked back at my logbook to be sure, but,
if memory serves, I got my instrument rating at about 225 hours, and,
shot my first solo GPS approach with around 250 hours of PIC experience.
You are right that a significant portion of instrument training is how
to cross-check instruments and detect failures.  Mostly, however, this
focuses on failures of instruments related to keeping the airplane
right-side up.  Some cursory coverage is given to detecting navigational
failurres, but, as much as I try to behave differently, and, as much
as I wish this weren't true, the primary mode of navigational failure
detection employed by most IFR pilots I've met is when the controller
says "Where the heck are you going?" (no, this isn't from the Pilot
Controller glossary, nor is it how they usually convey that message).
It is true that to begin a GPS approach, you must have an approach
certified (TSO'd) unit in an installation that the FAA FSDO has
signed off as an approach capable installation.  It's also true that
you need RAIM, and, RAIM provides a certain amount of integrity more
than standard GPS and more than ILS.  (Actually ILS glide-slope only
failues are the ones that scare me the most as an IFR pilot).
I'm not saying the system is unsafe.  I think it's very safe.  I also
agree about the accident reports regarding handhelds, however, I will
say that with a safety pilot on board, I occasionally do make sure that
I can do a panel-out (yes, that means put the sectional over the entire
panel) approach using my Garmin 195.  I would never do this in actual
IMC, and, I would never do it without a safety pilot looking out the
window and watching what I was doing.  However, I feel safer knowing
that I can, if evertyhing else goes to heck, get the plane down a
GPS approach using the handheld.  It is a _VERY_ challenging approach.
Owen

Re: NTP, possible solutions, and best implementation

[David Lesher]

Speaking on Deep Background, the Press Secretary whispered:
> 
> 
> 
> Two relevant points on GPS/LORAN
> 
> 1 - GPS has two positioning systems
> 
> 1 - SPS Standard Positioning Service which is what all civillian 
> uses of GPS utilize for positioning and timing uses and this can 
> be degraded or disabled with no notice to the user community
> by the National Command Authority.

I do not believe this is still true. To get ICAO approval for
using GPS as a intl. standard; DoD had to sign a MOU to maintain
the service.

They did this because they figured how easy it was to jam locally,
vs take down an entire region.


-- 
A host is a host from coast to [EMAIL PROTECTED]
& no one will talk to a host that's close[v].(301) 56-LINUX
Unless the host (that isn't close).pob 1433
is busy, hung or dead20915-1433

Re: NTP, possible solutions, and best implementation

[Ariel Biener]

  Hi,



I wish to thank all who answered, indeed, it was helpful. But, as it
was mentioned here, any further dwelling into this particular topic would
be more appropriate in the NTP forums available, be it mailing lists or
newsgroups.

So, I would like to request that further replies on this topic are
sent to me in private, and wish to thank again all that answered.

--Ariel

--
Ariel Biener
e-mail: [EMAIL PROTECTED]
PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html

Re: NTP, possible solutions, and best implementation

[Scott McGrath]

Two relevant points on GPS/LORAN

1 - GPS has two positioning systems

1 - SPS Standard Positioning Service which is what all civillian 
uses of GPS utilize for positioning and timing uses and this can 
be degraded or disabled with no notice to the user community
by the National Command Authority.

2 - PPS Precision Positioning Service this is the military GPS system
which uses encrypted signals on a different frequency to provide 
location services accurate to 30 cm.   SPS can be disabled with no 
effect on PPS.

I have no knowledge of why there are two systems since the system
was initially designed for military use only but as a guess the 
SPS system was designed as a test system so GPS system 
functionality could be checked without the need to disclose keys.


2 - GPS is more accurate than LORAN however the SPS is much less 
repeatable by design than LORAN.  A LORAN may not give you as accurate
a Fix as the GPS but the LORAN will always bring you back to the 
same spot +/- a few feet which is why Aviators and Sailors like LORAN
better than GPS.

2.5 - Both systems use atomic clocks for their time reference systems.

Scott C. McGrath

On Thu, 2 Oct 2003, joe mcguckin wrote:

> 
> 
> > It depends upon how low a probability failure you're willing to consider
> > and how paranoid you are. For one thing, the U.S. National Command Authority
> > could decide that GPS represents a threat to national security and disable
> > or derate GPS temporarily or indefinitely over a limited or unlimited area.
> > 
> 
> Derating GPS wouldn't affect the time reference functionality. Turning off
> GPS entirely would seriously affect military aviation operations.
> 
> > It is well known that GPS is vulnerable to deliberate attacks in limited
> > areas, perhaps even over large areas (see Presidential Decision Directive
> > 63). Backup systems are officially recommended for "safety-critical
> > applications" and the US government is actively intersted in developing
> > low-cost backup systems (presumably because they're concerned about GPS as a
> > SPOF too).
> > 
> > The US government, and other entities, do perform "GPS interference
> > testing". This basically means they interfere with GPS. The government is
> > also actively investigating "phase-over to private operation", which could
> > mean changes to operation, fee system, or reliability of the GPS system.
> > 
> > One could also imagine conditions that would result in concurrent failures
> > of large numbers of satellites. Remember what happened to Anik E-1 and E-2
> > (space weather caused them to spin out of control).
> > 
> > If you do develop a system with GPS as a SPOF, you should certainly be
> > aware of these risks and monitor any changes to the political and technical
> > climate surrounding GPS. I do believe that it is currently reasonable to
> > have GPS as a SPOF for a timing application that is not life critical (that
> > is, where people won't die if it fails).
> > 
> > Aviators try very, very hard not to trust their lives to GPS.
> >
> 
> As opposed to LORAN ?
> 

Re: NTP, possible solutions, and best implementation

[Scott McGrath]

The recommendations of others to place the Stratum 1 source behind another 
box is indeed good operational practice.  However if you _really_ want to 
provide Stratum 1 services there are a couple of options

1 - Purchase a Cesium clock this is a Primary Time/Frequency standard 
which does not require access to a reference standard to maintain 
accuracy.

This is a Stratum 0 source so once placed behind a Unix/Cisco/Juniper
box you have a stratum 1 source.   This will cost you 30,000 -> 
100,000 US per unit.   The beam tube will require replacement
approx every 5 years for about 20,000 US.

2 - Set up a stratum 1 source but use MD5 authentication to prevent 
unauthorized users from accessing the service.

 

Scott C. McGrath

On Thu, 2 Oct 2003, Ariel Biener wrote:

> 
> 
> 
>   Hi,
> 
> 
>Assuming one wanted to provide a high profile (say, at the TLD level) NTP 
> service, how would you go about it ?
> 
>The possibilities I encountered are diverse, the problem is not the 
> back-end device (be it a GPS based NTP source + atomic clock backup, based on 
> cesium or similar), but the front end to the network. Such a time service is 
> something that is considered a trusted stratum 1 server, and assuring that no 
> tampering with the time is possible is of very high priority, if not top 
> priority.
> 
> There are a few NTP servers solutions, I like the following comparison 
> between one company's products (Datum, merged into Symmetricom):
> 
> http://www.ntp-systems.com/product_comparison.asp
> 
> However, when you put such a device on a network, you want to have some 
> kind of clue about the investment made in that product when security comes to 
> mind, and also the turnaround time for bug fixes should such security bug 
> become public. Here is the problem, or actually, my problem with these 
> devices. I know that if I use a Unix machine or a Cisco router as front end 
> to the network for this back-end device, then if a bug in NTP occurs, Cisco 
> or the Unix vendor will fix it quickly. BUT!, if I want to put the device 
> itself on the network, as this is what a NTP device was built for, I feel 
> that I have no real sense of how secure the device really is, and how long it 
> would take for the vendor to actually fix the bug, should such be discovered. 
> It's a black box, and I am supposed to provide a secure time source based on 
> ... "what ?"
> 
>This is my dillema. While I don't want to put a NTP front end, which 
> becomes a stratum 2 in this case, but to provide direct stratum 1 service to 
> stratum 2 servers in the TLD in question, I do not know how can I safely 
> trust a device that I have no experience with how the vendor deals with bugs, 
> and also, I have no idea what is the underlying software (although it's safe 
> to assume that it is an implementation of xntpd, in one form or the other).
> 
>Did any of you have to create/run/maintain such a service, and does any of 
> you have experience with vendors/products that can be trusted when security 
> is concerned (including the vendor and the products I specified above).
> 
> thanks for your time,
> 
> --Ariel 
> 
> 
> --
> Ariel Biener
> e-mail: [EMAIL PROTECTED]
> PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html
> 

Re: NTP, possible solutions, and best implementation

[Michael Shields]

In message <[EMAIL PROTECTED]>,
"Robert M. Enger" <[EMAIL PROTECTED]> wrote:
> An alternate time source could be the GLONASS system.
> Receivers do exist, but I have never used one.

Note that GLONASS satellites are failing frequently, and unlike GPS
satellites, are not always being replaced.  Currently only eight are
operational out of a desired constellation of 24.
http://www.glonass-center.ru/nagu.txt

GLONASS is also subject to many of the same failure modes as GPS --
antenna failure, jamming, &c.

A very robust design would fall back to a local frequency standard
rather than to another transmitted one.  You need to decide how good
that standard needs to be based on your requirements (or maybe you
just want to install cesium or rubidium so your marketing department
can say you have atomic clocks).

> The US  FAA  is transmitting WAAS correction signals.  Depending on
> the algorithms in the GPS receiver, this may result a reduction in PPS
> jitter.   (although any such jitter is probably swamped by the jitter 
> at the IP layer)

http://216.239.51.104/search?q=cache:AZ97VsY3w10J:www.cmcelectronics.ca/products-services/custom-elect/Enhancing_GPS_Timing_Engines_using_WAAS_signals.pdf+waas+timing&hl=en&ie=UTF-8
suggests that WAAS can reduce your PPS jitter from about 50 ns to
about 20 ns, which sounds plausible to me.  This is beyond the
level of accuracy that is needed or useful for NTP.

Might I suggest that comp.protocols.time.ntp would have better advice
on this than NANOG.  Even 10 ms accuracy is usually enough for network
operations.  Beyond that we're talking about operating a service, not
a network.
-- 
Shields.

Re: NTP, possible solutions, and best implementation

[Michael . Dillon]

>So what you are suggesting basically is to add an application layer 
sanity
>checker and DoS preventer, am I right ?

More or less, yes. The main thing is to have something in front of the 
clocks that can be used to block or mitigate network abuse activities like 
DoS. And if this front-end is a UNIX box then it is easy to take a simple 
proxy such as udprelay and extend it to do some application layer 
checking.

--Michael Dillon

RE: NTP, possible solutions, and best implementation

[David Schwartz]

> > It depends upon how low a probability failure you're willing to consider
> > and how paranoid you are. For one thing, the U.S. National
> > Command Authority
> > could decide that GPS represents a threat to national security
> > and disable
> > or derate GPS temporarily or indefinitely over a limited or
> > unlimited area.

> Derating GPS wouldn't affect the time reference functionality. Turning off
> GPS entirely would seriously affect military aviation operations.

Not so:

"Selective Availability (SA) is the deliberate introduction of error by
either altering the precise timekeeping of GPS satellites or the position of
the satellites in space, through the on-board software, thereby reducing
both positioning and timing accuracy for civilian users."

GPS accuracy is generally reduced by adding noise to the timing. Now you
would have to derate GPS pretty significantly before timing accuracy would
be significantly affected. But it's possible that some time references would
refuse to lock on at all with sufficient derating. The affects of more
extreme derating than SA are, at least to some extent, unknown.

> > Aviators try very, very hard not to trust their lives to GPS.

> As opposed to LORAN ?

Generally, aviators don't like SPOFs. So they try very hard not to trust
their life to any one thing. GPS is used in conjunction with VORs, pilotage
(navigation by reference to fixed objects), and dead reckoning.

GPS is used for instrument approaches, but only under extremely controlled
conditions by very experienced pilots. A significant fraction of instrument
training is how to cross-check instruments and detect failures. GPS
approaches are individually approved by the FAA and factors such as runway
lighting are critical. FAA approved GPS units must be used and one of the
things these GPS units must do is monitor signal integrity (RAIM).  From time
to time, you will read FAA accident reports of people who attempted to
perform GPS approaches with just a handheld GPS.

DS

Re: NTP, possible solutions, and best implementation

[Robert M. Enger]

 
As Mr. Dillon observed, regional service seems prudent, if onlyto 
minimize timing problems at the IP layer, much less for reliability 
purposes.An alternate time source could be the GLONASS 
system.Receivers do exist, but I have never used one.Sanity checking 
sources could include WWVB in the US, and many others:http://www.cl.cam.ac.uk/~mgk25/lf-clocks.htmlThe 
US  FAA  is transmitting WAAS correction signals.  Depending 
onthe algorithms in the GPS receiver, this may result a reduction in 
PPSjitter.   (although any such jitter is probably swamped by 
the jitter 
at the IP layer)There is at least one GPS receiver that will 
deliver  20PPS  output, ifneeded.It is often possible to 
directly interrogate the GPS receiver to find outhow many satellites it can 
see, and what the signal strengh conditions are.This will allow you to 
verify the adequacy of the outside antenna installation.
If this is serious business, then it might be prudent to make a 
permanentconnection that allows this interrogation (terminal server 
interface),and to check the constellation visibility and signal conditions 
on aperiodic basis, not just at installation time.  (Someone might put 

something else up on the roof that blocks your antenna's view of a 
portion of the sky...)Best wishes,Bob Enger- 
Original Message - From: "Ariel Biener" <[EMAIL PROTECTED]>To: 
<[EMAIL PROTECTED]>Sent: Thursday, 
October 02, 2003 10:54 AMSubject: NTP, possible solutions, and best 
implementation>>>>   
Hi,>>>    Assuming one wanted to provide a 
high profile (say, at the TLD level)NTP> service, how would you go 
about it ?>>    The possibilities I encountered are 
diverse, the problem is not the> back-end device (be it a GPS based NTP 
source + atomic clock backup, basedon> cesium or similar), but the 
front end to the network. Such a time serviceis> something that is 
considered a trusted stratum 1 server, and assuring thatno> tampering 
with the time is possible is of very high priority, if not top> 
priority.>> There are a few NTP servers 
solutions, I like the following comparison> between one company's 
products (Datum, merged into Symmetricom):>> http://www.ntp-systems.com/product_comparison.asp>> 
However, when you put such a device on a network, you want to 
havesome> kind of clue about the investment made in that product when 
security comesto> mind, and also the turnaround time for bug fixes 
should such security bug> become public. Here is the problem, or 
actually, my problem with these> devices. I know that if I use a Unix 
machine or a Cisco router as frontend> to the network for this 
back-end device, then if a bug in NTP occurs,Cisco> or the Unix 
vendor will fix it quickly. BUT!, if I want to put the device> itself on 
the network, as this is what a NTP device was built for, I feel> that I 
have no real sense of how secure the device really is, and how 
longit> would take for the vendor to actually fix the bug, should 
such bediscovered.> It's a black box, and I am supposed to provide a 
secure time source basedon> ... "what 
?">>    This is my dillema. While I don't want to 
put a NTP front end, which> becomes a stratum 2 in this case, but to 
provide direct stratum 1 serviceto> stratum 2 servers in the TLD in 
question, I do not know how can I safely> trust a device that I have no 
experience with how the vendor deals withbugs,> and also, I have no 
idea what is the underlying software (although it'ssafe> to assume 
that it is an implementation of xntpd, in one form or 
theother).>>    Did any of you have to 
create/run/maintain such a service, and does anyof> you have 
experience with vendors/products that can be trusted whensecurity> is 
concerned (including the vendor and the products I specified 
above).>> thanks for your time,>> 
--Ariel>>> --> Ariel Biener> e-mail: [EMAIL PROTECTED]> PGP(6.5.8) 
public key http://www.tau.ac.il/~ariel/pgp.html>

Re: NTP, possible solutions, and best implementation

[Randy Bush]

>> Beware the single point of failure. If all your clocks come from GPS, then 
>> GPS is the SPOF.
> Can you describe what would be involved to cause this sort of single 
> point of failure to fail?

please don't!

i smell my kill-subkject key coming

Re: NTP, possible solutions, and best implementation

[David Raistrick]

On Thu, 2 Oct 2003, Eliot Lear wrote:

> [EMAIL PROTECTED] wrote:
> > Beware the single point of failure. If all your clocks come from GPS, then
> > GPS is the SPOF.
>
> Can you describe what would be involved to cause this sort of single
> point of failure to fail?


A military repositioning of the GPS sats for their own purposes, perhaps?
Or adjustment of the time being broadcast?

I know that a coworker of mine experienced this with a GPS-based tracking
system.  The boat he was tracking moved from the middle of the atlantic,
to the middle of europe, then eventually back the middle of the atlantic.
(this was around the time of Desert Storm)


Or, of course, a more general failure of the GPS time system, for whatever
reason.

...david
---
david raistrick
[EMAIL PROTECTED]   http://www.expita.com/nomime.html

Re: NTP, possible solutions, and best implementation

[joe mcguckin]

> It depends upon how low a probability failure you're willing to consider
> and how paranoid you are. For one thing, the U.S. National Command Authority
> could decide that GPS represents a threat to national security and disable
> or derate GPS temporarily or indefinitely over a limited or unlimited area.
> 

Derating GPS wouldn't affect the time reference functionality. Turning off
GPS entirely would seriously affect military aviation operations.

> It is well known that GPS is vulnerable to deliberate attacks in limited
> areas, perhaps even over large areas (see Presidential Decision Directive
> 63). Backup systems are officially recommended for "safety-critical
> applications" and the US government is actively intersted in developing
> low-cost backup systems (presumably because they're concerned about GPS as a
> SPOF too).
> 
> The US government, and other entities, do perform "GPS interference
> testing". This basically means they interfere with GPS. The government is
> also actively investigating "phase-over to private operation", which could
> mean changes to operation, fee system, or reliability of the GPS system.
> 
> One could also imagine conditions that would result in concurrent failures
> of large numbers of satellites. Remember what happened to Anik E-1 and E-2
> (space weather caused them to spin out of control).
> 
> If you do develop a system with GPS as a SPOF, you should certainly be
> aware of these risks and monitor any changes to the political and technical
> climate surrounding GPS. I do believe that it is currently reasonable to
> have GPS as a SPOF for a timing application that is not life critical (that
> is, where people won't die if it fails).
> 
> Aviators try very, very hard not to trust their lives to GPS.
>

As opposed to LORAN ?

Re: NTP, possible solutions, and best implementation

[Eliot Lear]

okay.  two valid cases to be concerned about:

The most valid case is when we all go and buy GPS receivers from the 
same vendor who turns out to have a bug or a vulnerability of some form.

The other valid case is if the defense department brought down the 
sattelite system for some odd reason.  And they seem to not have a 
shortage of odd reasons.

Some sort of a backup, such as PPS, or WWV* is nice, but so long as 
there are a few of these in the network somewhere, life should go on. 
Many enterprise networks run with 0 stratum 1s.

Eliot

Re: NTP, possible solutions, and best implementation

[bmanning]

> Does anyone on the NANOG list actually deploy standalone equipment ??? 

who doesn't, oh snake with wavy hair?  (its the sig...)
(mantra'o'the day - multi-taskers bad, single-taskers good")

> ~S~

--bill

RE: NTP, possible solutions, and best implementation

[David Schwartz]

Eliot Lear writes:

> [EMAIL PROTECTED] wrote:

> > Beware the single point of failure. If all your clocks come
> > from GPS, then
> > GPS is the SPOF.

> Can you describe what would be involved to cause this sort of single
> point of failure to fail?

It depends upon how low a probability failure you're willing to consider
and how paranoid you are. For one thing, the U.S. National Command Authority
could decide that GPS represents a threat to national security and disable
or derate GPS temporarily or indefinitely over a limited or unlimited area.

It is well known that GPS is vulnerable to deliberate attacks in limited
areas, perhaps even over large areas (see Presidential Decision Directive
63). Backup systems are officially recommended for "safety-critical
applications" and the US government is actively intersted in developing
low-cost backup systems (presumably because they're concerned about GPS as a
SPOF too).

The US government, and other entities, do perform "GPS interference
testing". This basically means they interfere with GPS. The government is
also actively investigating "phase-over to private operation", which could
mean changes to operation, fee system, or reliability of the GPS system.

One could also imagine conditions that would result in concurrent failures
of large numbers of satellites. Remember what happened to Anik E-1 and E-2
(space weather caused them to spin out of control).

If you do develop a system with GPS as a SPOF, you should certainly be
aware of these risks and monitor any changes to the political and technical
climate surrounding GPS. I do believe that it is currently reasonable to
have GPS as a SPOF for a timing application that is not life critical (that
is, where people won't die if it fails).

Aviators try very, very hard not to trust their lives to GPS.

DS

RE: NTP, possible solutions, and best implementation

[Vachon, Scott]

>   [EMAIL PROTECTED] wrote:
>   > Beware the single point of failure. If all your clocks 
> come from GPS, then
>   > GPS is the SPOF.
> 
>   Can you describe what would be involved to cause this sort of single
>   point of failure to fail?
> 
>   Eliot
> 
just me wrote:

> - Antenna failure
> - Radio failure
> - Unforseen GPS protocol issues


Except that as I read it, "all your clocks" meant more than one NTP server at more 
than one location. I'd guess the probability of complete failure is much lower in that 
case. Further, Cisco at least, recommends using at least 3 NTP sources to help 
maintain sanity on the equipment using the NTP. The bug you reference by the way, is 
on a page dated from 1999. I'm not sure of the relevancy now. 
Does anyone on the NANOG list actually deploy standalone equipment ??? 

My two cents.

~S~
  
Learn more about Paymentech's payment processing services at www.paymentech.com
THIS MESSAGE IS CONFIDENTIAL.  This e-mail message and any attachments are proprietary 
and confidential information intended only for the use of the recipient(s) named 
above.  If you are not the intended recipient, you may not print, distribute, or copy 
this message or any attachments.  If you have received this communication in error, 
please notify the sender by return e-mail and delete this message and any attachments 
from your computer.

Re: NTP, possible solutions, and best implementation

[Gary E. Miller]

Yo Elliot!

The Defense Department sometimes runs jamming tests on GPS just to see
what would happen.  They did this in Phoenix last year.  They also
have been known to do this in LA and San Diego for up to 15 minutes
at a time.

AOPA (Airplane Owners and Pilots Association) has written on this topis
a few times.  Needless to say this really gets pilots agitated

Lot's of GPSes also failed on Y2K and the GPS epoch rollover.

RGDS
GARY
---
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
[EMAIL PROTECTED]  Tel:+1(541)382-8588 Fax: +1(541)382-8676

On Thu, 2 Oct 2003, Eliot Lear wrote:

> [EMAIL PROTECTED] wrote:
> > Beware the single point of failure. If all your clocks come from GPS, then
> > GPS is the SPOF.
>
> Can you describe what would be involved to cause this sort of single
> point of failure to fail?

Re: NTP, possible solutions, and best implementation

[just me]

On Thu, 2 Oct 2003, Eliot Lear wrote:

  [EMAIL PROTECTED] wrote:
  > Beware the single point of failure. If all your clocks come from GPS, then
  > GPS is the SPOF.

  Can you describe what would be involved to cause this sort of single
  point of failure to fail?

  Eliot

- Antenna failure
- Radio failure
- Unforseen GPS protocol issues
see:
http://www.colorado.edu/geography/gcraft/notes/gps/gpseow.htm
http://www.sustainableworld.com/y2kgps/gpseng/


The basic idea is that putting all your eggs in one basket is rarely
a good plan.


[EMAIL PROTECTED]<
   Flowers on the razor wire/I know you're here/We are few/And far
   between/I was thinking about her skin/Love is a many splintered
   thing/Don't be afraid now/Just walk on in. #include 

Re: NTP, possible solutions, and best implementation

[Eliot Lear]

[EMAIL PROTECTED] wrote:
Beware the single point of failure. If all your clocks come from GPS, then 
GPS is the SPOF.
Can you describe what would be involved to cause this sort of single 
point of failure to fail?

Eliot

Re: NTP, possible solutions, and best implementation

[David G. Andersen]

Really good back-end clocks, particularly when you're
implementing a redundant system with a cesium clock or
two, are a lot more expensive than the front-end servers
that clients need to see.

Do you have particular technical reasons you want to put the
"actual device" on the net?  Most of the time, the "actual 
device" in these cases is merely a linux box or something
similar wrapped around a stratum-zero time source.

A much easier way to do this, which gives you control over
what faces the network, is to run your own front-ends of
stratum 1 servers that all talk to the same network of
back-end time sources:

 FE-1  FE-2   FE-3
  | |  |
   \--Time Distribution/
\   | /
GPSCesium   Clock3

Put cards in the front ends that let them receive PPS or
IRIG, and then let them all get a time signal from the
back end clocks.  The clocks on the FEs will be good to
a handfull of microseconds.  since the FEs will be
synched directly to a stratum zero time source (the PPS
signal from the GPS and cesium clocks, for instance),
they'll be running at stratum 1.

As a nice example of how you can structure this, see the
udel NTP page.  The added expense here will be
purchasing an IRIG board for the front-ends, or you can
decode it via the sound input, but if you go with a real
irig board, you'll get a high-quality onboard oscillator
that'll do a much better job of running free if it loses
the backends.

This way, you can have as many front ends as you need for
(redundancy, scalability, ...) and they'll run a real OS
that you control.  No need to put an application level
forwarder in the middle, since they _are_ your application
level gateways to the PPS/IRIG signal.

btw, comp.protocols.time.ntp is a good source of information
about this kind of thing.. probably better than nanog.

  -Dave

-- 
work: [EMAIL PROTECTED]  me:  [EMAIL PROTECTED]
  MIT Laboratory for Computer Science   http://www.angio.net/
  I do not accept unsolicited commercial email.  Do not spam me.

Re: NTP, possible solutions, and best implementation

[Ariel Biener]

On Thu, 2 Oct 2003 [EMAIL PROTECTED] wrote:


> Beware the single point of failure. If all your clocks come from GPS, then
> GPS is the SPOF. If they all come fram brand X manufacturer then that is
> the SPOF. A commercial service should be robust and use a combination of
> atomic clocks, GPS, radio time services, CDMA/GSM clocks combined with a
> sanity checker to watch all the clocks and detect bad timekeepers.

Yes, this is definetly an issue, and thus the clocks are at least one
cesium, and the other two are different vendors.

> Indeed.
> Hide this clock behind a packet filtering firewall or else use udprelay
> and an application layer gateway on UNIX to block everythingexcept NTP.
> In fact, if this is a commercial service you should hack udprelay so that
> it knows about the NTP protocol and can block non-customer traffic or
> malformed traffic or high volumes of traffic. That way, the UNIX

So what you are suggesting basically is to add an application layer sanity
checker and DoS preventer, am I right ?


--Ariel

--
Ariel Biener
e-mail: [EMAIL PROTECTED]
PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html

Re: NTP, possible solutions, and best implementation

[Michael . Dillon]

>   Assuming one wanted to provide a high profile (say, at the TLD level) 
NTP 
>service, how would you go about it ?

First of all, NTP should be done at the geographical level, not the TLD 
level. Generally, unless political reasons prevent it, you should try to 
implement an NTP service that covers a region roughly as large as Europe 
to avoid too much fate sharing caused by proximity.

>   The possibilities I encountered are diverse, the problem is not the 
>back-end device (be it a GPS based NTP source + atomic clock backup, 
based on 
>cesium or similar),

Beware the single point of failure. If all your clocks come from GPS, then 
GPS is the SPOF. If they all come fram brand X manufacturer then that is 
the SPOF. A commercial service should be robust and use a combination of 
atomic clocks, GPS, radio time services, CDMA/GSM clocks combined with a 
sanity checker to watch all the clocks and detect bad timekeepers.

>However, when you put such a device on a network, you want to have 
some 
>kind of clue about the investment made in that product when security 
comes to 
>mind,

Indeed.
Hide this clock behind a packet filtering firewall or else use udprelay 
and an application layer gateway on UNIX to block everything except NTP. 
In fact, if this is a commercial service you should hack udprelay so that 
it knows about the NTP protocol and can block non-customer traffic or 
malformed traffic or high volumes of traffic. That way, the UNIX 
server/firewall in between the NTP device and the net protects it from 
abuse, but since this UNIX server is a pass-through device from the point 
of view of NTP, it does not change the stratum level of the service any 
more than an IP router does.

--Michael Dillon

NTP, possible solutions, and best implementation

[Ariel Biener]

  Hi,


   Assuming one wanted to provide a high profile (say, at the TLD level) NTP 
service, how would you go about it ?

   The possibilities I encountered are diverse, the problem is not the 
back-end device (be it a GPS based NTP source + atomic clock backup, based on 
cesium or similar), but the front end to the network. Such a time service is 
something that is considered a trusted stratum 1 server, and assuring that no 
tampering with the time is possible is of very high priority, if not top 
priority.

There are a few NTP servers solutions, I like the following comparison 
between one company's products (Datum, merged into Symmetricom):

http://www.ntp-systems.com/product_comparison.asp

However, when you put such a device on a network, you want to have some 
kind of clue about the investment made in that product when security comes to 
mind, and also the turnaround time for bug fixes should such security bug 
become public. Here is the problem, or actually, my problem with these 
devices. I know that if I use a Unix machine or a Cisco router as front end 
to the network for this back-end device, then if a bug in NTP occurs, Cisco 
or the Unix vendor will fix it quickly. BUT!, if I want to put the device 
itself on the network, as this is what a NTP device was built for, I feel 
that I have no real sense of how secure the device really is, and how long it 
would take for the vendor to actually fix the bug, should such be discovered. 
It's a black box, and I am supposed to provide a secure time source based on 
... "what ?"

   This is my dillema. While I don't want to put a NTP front end, which 
becomes a stratum 2 in this case, but to provide direct stratum 1 service to 
stratum 2 servers in the TLD in question, I do not know how can I safely 
trust a device that I have no experience with how the vendor deals with bugs, 
and also, I have no idea what is the underlying software (although it's safe 
to assume that it is an implementation of xntpd, in one form or the other).

   Did any of you have to create/run/maintain such a service, and does any of 
you have experience with vendors/products that can be trusted when security 
is concerned (including the vendor and the products I specified above).

thanks for your time,

--Ariel 


--
Ariel Biener
e-mail: [EMAIL PROTECTED]
PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html