[63297] in North American Network Operators' Group
Re: NTP, possible solutions, and best implementation
daemon@ATHENA.MIT.EDU (Robert M. Enger)
Thu Oct 2 19:52:50 2003
From: "Robert M. Enger" <enger@seka.erols.net>
To: <nanog@merit.edu>
Date: Thu, 2 Oct 2003 19:50:53 -0400
Errors-To: owner-nanog-outgoing@merit.edu
This is a multi-part message in MIME format.
------=_NextPart_000_0032_01C3891E.7CDF50A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
As Mr. Dillon observed, regional service seems prudent, if only
to 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.html
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=20
at the IP layer)
There is at least one GPS receiver that will deliver 20PPS output, if
needed.
It is often possible to directly interrogate the GPS receiver to find =
out
how 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 =
permanent
connection that allows this interrogation (terminal server interface),
and to check the constellation visibility and signal conditions on a
periodic basis, not just at installation time. (Someone might put=20
something else up on the roof that blocks your antenna's view of a=20
portion of the sky...)
Best wishes,
Bob Enger
----- Original Message -----=20
From: "Ariel Biener" <ariel@fireball.tau.ac.il>
To: <nanog@merit.edu>
Sent: Thursday, October 02, 2003 10:54 AM
Subject: 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, =
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: ariel@post.tau.ac.il
> PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html
>
------=_NextPart_000_0032_01C3891E.7CDF50A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV>As Mr. Dillon observed, regional service seems prudent, if =
only<BR>to=20
minimize timing problems at the IP layer, much less for =
reliability=20
purposes.<BR><BR>An alternate time source could be the GLONASS=20
system.<BR>Receivers do exist, but I have never used one.<BR><BR>Sanity =
checking=20
sources could include WWVB in the US, and many others:<BR><A=20
href=3D"http://www.cl.cam.ac.uk/~mgk25/lf-clocks.html">http://www.cl.cam.=
ac.uk/~mgk25/lf-clocks.html</A><BR><BR>The=20
US FAA is transmitting WAAS correction signals. =
Depending=20
on<BR>the algorithms in the GPS receiver, this may result a reduction in =
PPS<BR>jitter. (although any such jitter is probably swamped =
by=20
the jitter </DIV>
<DIV>at the IP layer)<BR><BR><BR>There is at least one GPS receiver that =
will=20
deliver 20PPS output, if<BR>needed.<BR><BR>It is often =
possible to=20
directly interrogate the GPS receiver to find out<BR>how many satellites =
it can=20
see, and what the signal strengh conditions are.<BR>This will allow you =
to=20
verify the adequacy of the outside antenna installation.</DIV>
<DIV><BR>If this is serious business, then it might be prudent to make a =
permanent<BR>connection that allows this interrogation (terminal server=20
interface),<BR>and to check the constellation visibility and signal =
conditions=20
on a<BR>periodic basis, not just at installation time. (Someone =
might put=20
</DIV>
<DIV>something else up on the roof that blocks your antenna's view of a =
</DIV>
<DIV>portion of the sky...)<BR><BR>Best wishes,<BR>Bob =
Enger<BR><BR><BR>-----=20
Original Message ----- <BR>From: "Ariel Biener" <<A=20
href=3D"mailto:ariel@fireball.tau.ac.il">ariel@fireball.tau.ac.il</A>>=
<BR>To:=20
<<A href=3D"mailto:nanog@merit.edu">nanog@merit.edu</A>><BR>Sent: =
Thursday,=20
October 02, 2003 10:54 AM<BR>Subject: NTP, possible solutions, and best=20
implementation<BR><BR><BR>><BR>><BR>><BR>> =20
Hi,<BR>><BR>><BR>> Assuming one wanted to =
provide a=20
high profile (say, at the TLD level)<BR>NTP<BR>> service, how would =
you go=20
about it ?<BR>><BR>> The possibilities I =
encountered are=20
diverse, the problem is not the<BR>> back-end device (be it a GPS =
based NTP=20
source + atomic clock backup, based<BR>on<BR>> cesium or similar), =
but the=20
front end to the network. Such a time service<BR>is<BR>> something =
that is=20
considered a trusted stratum 1 server, and assuring that<BR>no<BR>> =
tampering=20
with the time is possible is of very high priority, if not top<BR>>=20
priority.<BR>><BR>> There are a few NTP =
servers=20
solutions, I like the following comparison<BR>> between one company's =
products (Datum, merged into Symmetricom):<BR>><BR>> <A=20
href=3D"http://www.ntp-systems.com/product_comparison.asp">http://www.ntp=
-systems.com/product_comparison.asp</A><BR>><BR>> =
=20
However, when you put such a device on a network, you want to=20
have<BR>some<BR>> kind of clue about the investment made in that =
product when=20
security comes<BR>to<BR>> mind, and also the turnaround time for bug =
fixes=20
should such security bug<BR>> become public. Here is the problem, or=20
actually, my problem with these<BR>> devices. I know that if I use a =
Unix=20
machine or a Cisco router as front<BR>end<BR>> to the network for =
this=20
back-end device, then if a bug in NTP occurs,<BR>Cisco<BR>> or the =
Unix=20
vendor will fix it quickly. BUT!, if I want to put the device<BR>> =
itself on=20
the network, as this is what a NTP device was built for, I feel<BR>> =
that I=20
have no real sense of how secure the device really is, and how=20
long<BR>it<BR>> would take for the vendor to actually fix the bug, =
should=20
such be<BR>discovered.<BR>> It's a black box, and I am supposed to =
provide a=20
secure time source based<BR>on<BR>> ... "what=20
?"<BR>><BR>> This is my dillema. While I don't =
want to=20
put a NTP front end, which<BR>> becomes a stratum 2 in this case, but =
to=20
provide direct stratum 1 service<BR>to<BR>> stratum 2 servers in the =
TLD in=20
question, I do not know how can I safely<BR>> trust a device that I =
have no=20
experience with how the vendor deals with<BR>bugs,<BR>> and also, I =
have no=20
idea what is the underlying software (although it's<BR>safe<BR>> to =
assume=20
that it is an implementation of xntpd, in one form or=20
the<BR>other).<BR>><BR>> Did any of you have to=20
create/run/maintain such a service, and does any<BR>of<BR>> you have=20
experience with vendors/products that can be trusted =
when<BR>security<BR>> is=20
concerned (including the vendor and the products I specified=20
above).<BR>><BR>> thanks for your time,<BR>><BR>>=20
--Ariel<BR>><BR>><BR>> --<BR>> Ariel Biener<BR>> e-mail: =
<A=20
href=3D"mailto:ariel@post.tau.ac.il">ariel@post.tau.ac.il</A><BR>> =
PGP(6.5.8)=20
public key <A=20
href=3D"http://www.tau.ac.il/~ariel/pgp.html">http://www.tau.ac.il/~ariel=
/pgp.html</A><BR>><BR></DIV></BODY></HTML>
------=_NextPart_000_0032_01C3891E.7CDF50A0--
