Hi,

We are planning to operate public stratum 1 servers.
Because we don't want to deal with the server overload,
we developed a high-throughput SNTP server using FPGA.

This server can respond up to the wire speed of GbE and
the timestamp jitter is within 8 nano-seconds.
Though the performance seems sufficient, we afraid there
can be potential problems because complex functions
are omitted in this server.
It responds only to NTP request pakets in unicast UDP,
it can't handle authentication options, KoD, etc...

Can anyone point out whether such server is suitable
for a public stratum 1 server?

Any comments would be appreciated.

Experimental servers can be accessed at;
sntp1.nict.go.jp
    IPv4: 133.243.230.51
    IPv6: 2001:e38:2020::123
sntp2.nict.go.jp
    IPv4: 133.243.230.52
    IPv6: 2001:e38:2020::124
Clock source: 1PPS and 10MHz from UTC(NICT)

Hiroshi Toriyama
Time Applications Group
NICT, Japan

Hiroshi Toriyama wrote:

> Hi,
> 
> We are planning to operate public stratum 1 servers.
> Because we don't want to deal with the server overload,

That (overloading the server, not the network) is actually quite hard to
do! :-)

> we developed a high-throughput SNTP server using FPGA.

Hmmm.
> 
> This server can respond up to the wire speed of GbE and
> the timestamp jitter is within 8 nano-seconds.

Wow!

> Though the performance seems sufficient, we afraid there
> can be potential problems because complex functions
> are omitted in this server.
> It responds only to NTP request pakets in unicast UDP,
> it can't handle authentication options, KoD, etc...

This is still fine for a public S1 server:

- You don't need KoD because you'll never be processing-limited.
- You don't need to support authentication unless you have to serve
clients (i.e. paying customers) who absolutely require crypto-traceable
timestamps.
- Broadcast/manycast isn't needed or really possible for a public S1 server.

> 
> Can anyone point out whether such server is suitable
> for a public stratum 1 server?

I do wonder what your reference clock is? The entire ensemble of
japanese UTC atomic references? How do you transfer that time into the
server timebase?

I assume you have built these clocks with some kind of hw counter that's
directly coupled to the output osc of an atomic clock, with external
inputs to initialize it, define the correspondence between counter value
and UTC/TAI time etc?
> 
> Any comments would be appreciated.
> 
> Experimental servers can be accessed at;
> sntp1.nict.go.jp
>     IPv4: 133.243.230.51
>     IPv6: 2001:e38:2020::123
> sntp2.nict.go.jp
>     IPv4: 133.243.230.52
>     IPv6: 2001:e38:2020::124
> Clock source: 1PPS and 10MHz from UTC(NICT)

I just added these two to my deskside Oncore-based S1 server, besides
the 264 ms RTT, everything seems very nice.

For sntp1 with a PPS input you must have a stabilized local frequency
source to allow interpolation between pulses at the required ns level,
sntp2 could get away with simply counting the 10 Mhz reference ticks,
but I assume it still has a similarly stable local timebase?

I'm impressed! :-)

Terje
> 
> Hiroshi Toriyama
> Time Applications Group
> NICT, Japan


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

At 11:14 AM +0900 2005-09-08, Hiroshi Toriyama wrote:

>  Can anyone point out whether such server is suitable
>  for a public stratum 1 server?

	If you're the only ones using it, I guess you can do pretty much 
whatever you want.


	However, speaking only for myself, if you wanted to get it 
included in pool.ntp.org, or on the public lists of NTP time servers 
underneath the page at <http://ntp.isc.org/bin/view/Servers/WebHome>, 
then I'd want to see you running a full NTP implementation, 
preferably NTPv4.  I would not want to see any SNTP server listed in 
any of those places.

	Indeed, I wouldn't want to see any public Stratum-1 server 
running only SNTP, instead of at least NTPv3, if not NTPv4.

	I have no problem with people running SNTP clients, if their 
application is such that they can't support running a full internal 
NTP server as a "client".  But IMO it is not appropriate to run a 
public SNTP server that you encourage others to use.


	I'm sorry, I know that this sounds really down, and I'm not 
recognizing the amazing work you've done with putting a complete SNTP 
server into FPGAs.  FPGAs are hard to program, run amazingly fast 
(relative to general-purpose CPUs), and have a number of interesting 
uses.

	However, I've recently heard about at least two different large 
groups of people (all from Japan, strangely enough), that are 
implementing all sorts of stuff in FPGAs that they think will be a 
huge improvement for the world, but they turn out to only be solving 
the easy 1% of the problem, and not understanding that the part of 
the problem they're solving is not generally an issue.


	In the case of one group I've talked to recently, they're talking 
about building L3-L7 special-purpose anti-spam switches using FPGAs, 
but product-wise they're only offering two particular features which 
are not typically serious performance issues in existing software 
only solutions, and they don't appear to offer anything that isn't 
already available from a dozen (or more) existing companies in the 
field, many of which are already using even higher-speed ASICs in 
their devices.  Moreover, they don't seem to be likely to be able to 
offer their features at a world-beating price that would otherwise 
give them a competitive advantage.

	They seem to be coming to this party much more than a day late, 
and much more than a dollar short.  And yet, their engineers still 
seem to think that sprinkling some magic FPGA dust is going to solve 
all their problems.  I wish them luck, but unless they radically 
change their services model and attack problems which do currently 
pose serious CPU performance issues in this field and which are not 
addressed by any existing or known-to-be-coming ASICs, I don't see 
how they can possibly succeed.


	In your case, you're implementing an SNTP Stratum-1 server, but 
even if you put all the people in your country on VOIP or 4G mobile 
phones and needed highly accurate time services to all these devices, 
I think you'd still be hard-pressed to show a real client-impacting 
performance difference between your FPGA SNTP server and a real NTPv4 
server based on the Poul-Henning Kamp Soekris+FreeBSD+Oncore SBC 
solution.

	IMO, the latter would be much cheaper to buy, configure, and 
operate, and provide better overall quality time (as a result of 
improved internal algorithms).  Although the jitter for the PHK-style 
solution might be a bit higher than 8 nanoseconds, and they might not 
be able to handle as many clients per server, you could compensate 
for that by using more of them in a good-quality distributed 
hierarchy.  Moreover, by having more of them, you'd be able to locate 
them closer to the clients, and that improved geographical locality 
could easily overwhelm an eight nanosecond jitter.



	At the very least, I'd want to hear more about your proposed 
usage model, which you believe would prohibit the use of standard 
NTPv4 servers running well-configured hardware and OS, and would 
instead require the use of your custom FPGA SNTP servers.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Terje Mathisen wrote:
> Hiroshi Toriyama wrote:
>>Though the performance seems sufficient, we afraid there
>>can be potential problems because complex functions
>>are omitted in this server.
>>It responds only to NTP request pakets in unicast UDP,
>>it can't handle authentication options, KoD, etc...
> 
> 
> This is still fine for a public S1 server:
> 
> - You don't need KoD because you'll never be processing-limited.

I disagree. You always get abuse clients. KoD is one way of attempting
to alleviate the situation those most of the clients violates the NTP
specs anyway.

> - You don't need to support authentication unless you have to serve
> clients (i.e. paying customers) who absolutely require crypto-traceable
> timestamps.

You certainly DO need authentication if people are going to trust your
server to provide a service especially at the Stratum 1 level.
> 
>>Can anyone point out whether such server is suitable
>>for a public stratum 1 server?
> 
Not as an SNTP server. As a NTP server it would be great.
> 

Danny


_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

>> Can anyone point out whether such server is suitable
>> for a public stratum 1 server?
>
> Not as an SNTP server. As a NTP server it would be great.

If the software is only talking to that 1 source of time, why does it matter
if the software is SNTP v. NTP?

H

Harlan Stenn wrote:
>>>Can anyone point out whether such server is suitable
>>>for a public stratum 1 server?
>>
>>Not as an SNTP server. As a NTP server it would be great.
> 
> 
> If the software is only talking to that 1 source of time, why does it matter
> if the software is SNTP v. NTP?
> 

Because a stratum 1 server needs the full NTP protocol to be useful.

Danny

> H
> 
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 

_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny Mayer wrote:

> Harlan Stenn wrote:
> 
>>>> Can anyone point out whether such server is suitable
>>>> for a public stratum 1 server?
>>>
>>>
>>> Not as an SNTP server. As a NTP server it would be great.
>>
>>
>>
>> If the software is only talking to that 1 source of time, why does it
>> matter
>> if the software is SNTP v. NTP?
>>
> 
> Because a stratum 1 server needs the full NTP protocol to be useful.

Danny, I have an awful lot of respect for your opinion, but in this
particular case I believe you're wrong:

Case in point:

The first S1 reference clock I aquired was a TrueTime NTS-100, which
isn't even close to full NTP, but still capable of keeping my corporate
network synchronized.

The FPGA server is in the same cathegory: It is missing a _lot_ of very
useful stuff, but it is still (eminently!) capable of delivering
properly timestamped NTP replies.

Terje

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

Following article has been lost because of our
server trouble.
I'm sorry it became so slow reply.

Hiroshi Toriyama

--------------------------
Terje Mathisen wrote:

 >> This server can respond up to the wire speed of GbE and
 >> the timestamp jitter is within 8 nano-seconds.
 >
 > Wow!

Our hardware has two GbE port and can be used as a
"passing through mode."
Directly connecting our SNTP server and passing through
time stamper, packet delay graph shows a horizontal line,
or two horizontal lines different by 8 nano-second.

 > This is still fine for a public S1 server:
 >
 > - You don't need KoD because you'll never be processing-limited.
 > - You don't need to support authentication unless you have to serve
 > clients (i.e. paying customers) who absolutely require crypto-traceable
 > timestamps.
 > - Broadcast/manycast isn't needed or really possible for a public S1 
server.

Thank you for your comment.

 > I do wonder what your reference clock is? The entire ensemble of
 > japanese UTC atomic references? How do you transfer that time into the
 > server timebase?

Because UTC(NICT) is generated in the same building,
we can feed 1PPS and 10MHz signal only with a multi-port amplifier
and coaxial cables.

We also have a remote experiment site, where we use a cesium clock
and GPS common view equipments.

 > I assume you have built these clocks with some kind of hw counter that's
 > directly coupled to the output osc of an atomic clock, with external
 > inputs to initialize it, define the correspondence between counter value
 > and UTC/TAI time etc?

Yes,
internal PLL generates 250MHz from external 10MHz, and
the fraction of a timestamp is culculated from this 250MHz count.
The integer part is just a PPS count plus offset.
Incoming NTP packet is processed in a hardware pipeline, and
just 832ns after, the NTP response is sent from the same GbE port.
Most of these functions are implemented in a FPGA.
http://www2.nict.go.jp/dk/c272/index-e.html

 > I just added these two to my deskside Oncore-based S1 server, besides
 > the 264 ms RTT, everything seems very nice.

Thanks.
But please be careful with some values in response NTP message.
Precision, Root delay, and Root dispersion are constant values
set in FPGA registers beforehand.

 > For sntp1 with a PPS input you must have a stabilized local frequency
 > source to allow interpolation between pulses at the required ns level,
 > sntp2 could get away with simply counting the 10 Mhz reference ticks,
 > but I assume it still has a similarly stable local timebase?

sntp2 uses UTC(NICT) directly.
sntp1 uses a rubidium clock which is locked to UTC(NICT).
The firmware version of sntp1 is slightly older.

Hiroshi Toriyama
Time Applications Group
NICT, Japan

Brad Knowles wrote:

>     In your case, you're implementing an SNTP Stratum-1 server, but even 
> if you put all the people in your country on VOIP or 4G mobile phones 
> and needed highly accurate time services to all these devices, I think 
> you'd still be hard-pressed to show a real client-impacting performance 
> difference between your FPGA SNTP server and a real NTPv4 server based 
> on the Poul-Henning Kamp Soekris+FreeBSD+Oncore SBC solution.
> 
>     IMO, the latter would be much cheaper to buy, configure, and 
> operate, and provide better overall quality time (as a result of 
> improved internal algorithms).  Although the jitter for the PHK-style 
> solution might be a bit higher than 8 nanoseconds, and they might not be 
> able to handle as many clients per server, you could compensate for that 
> by using more of them in a good-quality distributed hierarchy.  
> Moreover, by having more of them, you'd be able to locate them closer to 
> the clients, and that improved geographical locality could easily 
> overwhelm an eight nanosecond jitter.

Yes, precision of 8ns will not be advantage for internet use,
I know even one L2 switch may add 20 to 500 ns jitter.

Thogh geographical locality is still important, I feel its
importance is decreasing by speeding up of the network.
For example, some DNS round-robin disregards the geographical
locality, but typical PC users don't mind it.

I think that the main advantage of our server is in the low degree
of operation cost, not the equipment cost itself.

 >     At the very least, I'd want to hear more about your proposed usage
 > model, which you believe would prohibit the use of standard NTPv4
 > servers running well-configured hardware and OS, and would instead
 > require the use of your custom FPGA SNTP servers.

I've designed the hardware SNTP server mainly for national time
standard organizations.
It will be, so to speak, the internet version of JJY or DCF-77.

I beliebe it also suits major internet providers or major time
service providers who have atomic clocks adjusted to national
standard.

I think that distributed ntp network is not always
cost-effective for such purposes.
Concentrated server can be built with many ntpd servers and
a L4-L7 load balancer, but but a hardware SNTP server must be
implemented simpler than the load balancer.
This is the basic idea of our SNTP server.

Hiroshi Toriyama
Time Applications Group
NICT, Japan

Brad Knowles wrote:

 > In your case, you're implementing an SNTP Stratum-1 server,
 > but even if you put all the people in your country on VOIP or
 > 4G mobile phones and needed highly accurate time services to
 > all these devices, I think you'd still be hard-pressed to show
 > a real client-impacting performance difference between your FPGA
 > SNTP server and a real NTPv4 server based on the Poul-Henning
 > Kamp Soekris+FreeBSD+Oncore SBC solution.
 >
 > IMO, the latter would be much cheaper to buy, configure, and
 > operate, and provide better overall quality time (as a result
 > of improved internal algorithms).  Although the jitter for
 > the PHK-style solution might be a bit higher than 8 nanoseconds,
 > and they might not be able to handle as many clients per server,
 > you could compensate for that by using more of them in a
 > good-quality distributed hierarchy. Moreover, by having more of
 > them, you'd be able to locate them closer to the clients, and
 > that improved geographical locality could easily overwhelm an
 > eight nanosecond jitter.

Yes, precision of 8ns will not be advantage for internet use,
I know even one L2 switch may add 20 to 500 ns jitter.

I think that the main advantage of our server is in the low degree
of operation cost, not the equipment cost itself.

 >     At the very least, I'd want to hear more about your proposed usage
 > model, which you believe would prohibit the use of standard NTPv4
 > servers running well-configured hardware and OS, and would instead
 > require the use of your custom FPGA SNTP servers.

I've designed the hardware SNTP server mainly for national time
standard organizations.
It will be, so to speak, the internet version of JJY or DCF-77.

I beliebe it also suits major internet providers or major time
service providers who have atomic clocks adjusted to national
standard.

I think that distributed ntp network is not always
cost-effective for such purposes.
Thogh geographical locality is still important, I feel its
importance is decreasing by speeding up of the network.
For example, some DNS round-robin disregards the geographical
locality, but typical PC users don't mind it.

Concentrated server can be built with many ntpd servers and
a L4-L7 load balancer, but but a hardware SNTP server must be
implemented simpler than the load balancer.
This is the basic idea of our SNTP server.

Hiroshi Toriyama
Time Applications Group
NICT, Japan

At 7:14 PM +0900 2005-09-13, Toriyama, Hiroshi wrote:

>  I think that the main advantage of our server is in the low degree
>  of operation cost, not the equipment cost itself.

	You've got that with the PHK design based on a Soekris net4501 -- 
burn a CompactFlash card for the OS and configuration, connect the 
cables, and you're done.  Moreover, with more of these machines 
distributed around the network, run them in broadcast, multicast, 
and/or manycast modes, and you will have much less network 
infrastructure between any of your timeservers and their clients, 
which will help make the overall service much more robust in the face 
of network failure.

	Maybe I'm missing something here, but I don't see the operational 
cost benefit you're talking about.  But I certainly see what appears 
to be a pretty big drawback in the implementation, in that you're 
throwing away most of what I consider to be the best parts of NTP, 
just so that you can burn these things into FPGAs.

>  Concentrated server can be built with many ntpd servers and
>  a L4-L7 load balancer, but but a hardware SNTP server must be
>  implemented simpler than the load balancer.

	But you don't need load balancers.  In fact, the design of the 
NTP protocol is such that it prohibits their use.  You cannot have a 
client contact one server (via a load-balancer) for one packet, and 
then have the client contact a different server (maybe via the same 
load-balancer) with the next packet.

	Because these servers would not be the same and would not have 
precisely the same concept of time, to do this would be to completely 
destroy the NTP protocol itself.  Even if they're all served by the 
same atomic clock reference, using serial cable splitters or 
whatever, those differences in cable lengths would be significant.


	What you want is broadcast, multicast, and manycast servers and 
clients, so that the load is automatically distributed across the set 
of servers, and the clients are automatically served by those 
machines which are close by.

>  This is the basic idea of our SNTP server.

	Which seems to be pretty much 180 degrees away from where I 
believe that NTP services should be going.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Brad Knowles wrote:

> At 7:14 PM +0900 2005-09-13, Toriyama, Hiroshi wrote:
>
>>  I think that the main advantage of our server is in the low degree
>>  of operation cost, not the equipment cost itself.
>
>
>     You've got that with the PHK design based on a Soekris net4501 -- 
> burn a CompactFlash card for the OS and configuration, connect the 
> cables, and you're done.  Moreover, with more of these machines 
> distributed around the network, run them in broadcast, multicast, 
> and/or manycast modes, and you will have much less network 
> infrastructure between any of your timeservers and their clients, 
> which will help make the overall service much more robust in the face 
> of network failure.
>
>     Maybe I'm missing something here, but I don't see the operational 
> cost benefit you're talking about.  But I certainly see what appears 
> to be a pretty big drawback in the implementation, in that you're 
> throwing away most of what I consider to be the best parts of NTP, 
> just so that you can burn these things into FPGAs.
>
>>  Concentrated server can be built with many ntpd servers and
>>  a L4-L7 load balancer, but but a hardware SNTP server must be
>>  implemented simpler than the load balancer.
>
>
>     But you don't need load balancers.  In fact, the design of the NTP 
> protocol is such that it prohibits their use.  You cannot have a 
> client contact one server (via a load-balancer) for one packet, and 
> then have the client contact a different server (maybe via the same 
> load-balancer) with the next packet.
>
>     Because these servers would not be the same and would not have 
> precisely the same concept of time, to do this would be to completely 
> destroy the NTP protocol itself.  Even if they're all served by the 
> same atomic clock reference, using serial cable splitters or whatever, 
> those differences in cable lengths would be significant.
>
>
>     What you want is broadcast, multicast, and manycast servers and 
> clients, so that the load is automatically distributed across the set 
> of servers, and the clients are automatically served by those machines 
> which are close by.
>
>>  This is the basic idea of our SNTP server.
>
>
>     Which seems to be pretty much 180 degrees away from where I 
> believe that NTP services should be going.
>
A great deal of NTP is devoted to making sense of time received over a 
network from several servers at several locations.  A server running a 
single hardware reference clock, whether it's an HF radio reciever, GPS, 
or Cesium Clock, does not need all of NTP.  It has no choice but to 
believe its reference clock so the filters and selection algorithms are 
pretty much useless.   FWIW, I believe that NIST here in the US uses 
something called "lock clock" rather than NTP to sync with the atomic 
clock.  The NIST servers answer NTP queries with NTP packets but I don't 
believe they use ntpd!

Public information: time.nist.gov version is 4.1.1@1.786 Mon Apr  8
06:30:56 EDT 2002 (1)

Richard B. Gilbert wrote:
> Brad Knowles wrote:
>> At 7:14 PM +0900 2005-09-13, Toriyama, Hiroshi wrote:


>>     Maybe I'm missing something here, but I don't see the operational 
>> cost benefit you're talking about.  But I certainly see what appears 
>> to be a pretty big drawback in the implementation, in that you're 
>> throwing away most of what I consider to be the best parts of NTP, 
>> just so that you can burn these things into FPGAs.

Most of the interesting NTP stuff is the processing of the server info
by the client. If you are building a server with a hardware reference
clock, then there is very little processing required on the server.
If you have no auth processing and no request and no control modes,
and no multicast/broadcast modes, you could do it pretty simply.
The whole point of the use of the mitigation/filtering routines
on hardware refclocks assumes that it is NTP that is between the
refclock and the system clock. If this is not the case, the whole
loop filter really serves no point. In fact, that was the real
purpose of the LOCAL refclock; it was designed for use when
something else (either hardware or software) was responsible for
keeping the system clock in sync with the real time.

>>
>>>  Concentrated server can be built with many ntpd servers and
>>>  a L4-L7 load balancer, but but a hardware SNTP server must be
>>>  implemented simpler than the load balancer.
>>
>>
>>
>>     But you don't need load balancers.  In fact, the design of the NTP 
>> protocol is such that it prohibits their use.  You cannot have a 
>> client contact one server (via a load-balancer) for one packet, and 
>> then have the client contact a different server (maybe via the same 
>> load-balancer) with the next packet.

I think that NIST uses a load balancer. I believe that at least one of
the NIST NTP servers is really several servers. If the servers behind
the load balancer are very closely in sync (i.e. the same hardware
clock signals govern the system clocks) then there shouldn't be a 
problem with different samples having different offsets. If the load
balancer introduces the same latency on the way back as on the way in,
then it shouldn't make a difference to NTP. If the latency is not
the same, but is systematic and reasonable constant and measurable,
the servers could be tweaked to compensate.


-- 
blu

Remember when SOX compliant meant they were both the same color?
----------------------------------------------------------------------
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

Richard,

Richard B. Gilbert wrote:
> FWIW, I believe that NIST here in the US uses 
> something called "lock clock" rather than NTP to sync with the atomic
> clock.  The NIST servers answer NTP queries with NTP packets but I don't
> believe they use ntpd!

LOCKCLOCK is a compiler option for ntpd, so I assume it's just a ntpd
compiled with that option.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Brad Knowles wrote:
> At 7:14 PM +0900 2005-09-13, Toriyama, Hiroshi wrote:
> 
>>  Concentrated server can be built with many ntpd servers and
>>  a L4-L7 load balancer, but but a hardware SNTP server must be
>>  implemented simpler than the load balancer.
> 
> 
>     But you don't need load balancers.  In fact, the design of the NTP 
> protocol is such that it prohibits their use.  You cannot have a client 
> contact one server (via a load-balancer) for one packet, and then have 
> the client contact a different server (maybe via the same load-balancer) 
> with the next packet.
> 
>     Because these servers would not be the same and would not have 
> precisely the same concept of time, to do this would be to completely 
> destroy the NTP protocol itself.  Even if they're all served by the same 
> atomic clock reference, using serial cable splitters or whatever, those 
> differences in cable lengths would be significant.
> 
Yes, though given that it's acting as a SNTP server and basically 
expecting the client to just accept the timestamp given to it, it 
probably doesn't matter. That's not much different from using ntpdate. 
However, in order to provide reliable time you need to know that the 
packet is coming from the place you think it is. In today's world it's 
necessary to secure the infrastructure. There too many people who now 
think it's a wonderful thing to attack various parts of the 
infrastructure. I have no idea what kind of thrill they get but it's a 
fact of life today. The only way to secure your NTP infrastructure is 
using autokey. If you don't have that you can't rely on the Stratum 1 
server.

While it's useful to have a server that has nanosecond accuracy, none of 
the system hardware today can handle that kind of accuracy since their 
clocks are only accurate to the millesecond and the software is also 
limited to milliseconds. NTP can do and does do interpolation so that 
over a period of time the resulting time stays accurate to a high degree 
of confidence.

For an local server on an internal LAN it would be useful but not for a 
public server, unfortunately.

I hope you find this helpful.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny Mayer wrote:

> However, in order to provide reliable time you need to know that the 
> packet is coming from the place you think it is. In today's world it's 
> necessary to secure the infrastructure. There too many people who now 
> think it's a wonderful thing to attack various parts of the 
> infrastructure. I have no idea what kind of thrill they get but it's a 
> fact of life today. The only way to secure your NTP infrastructure is 
> using autokey. If you don't have that you can't rely on the Stratum 1 
> server.

Thank you for your comment.
I agree you that the time infrastructure should be protected by
some security technology.

Beside the development of the high-throughput SNTP server, I'm
participating in the development of Secure-Time-Stamping server
based on the PKI or the link protocol.
Through this development, I learnt security is a severe matter.

Anyway,
NTP should be protected also, but I believe non-security-protected
server may be also worth existing for some restricted purposes
including some kind of public services.

Do you think any of non-security-protected servers are useless
or harmful?

tori

Hiroshi Toriyama wrote:
> Danny Mayer wrote:
> 
>> However, in order to provide reliable time you need to know that the 
>> packet is coming from the place you think it is. In today's world it's 
>> necessary to secure the infrastructure. There too many people who now 
>> think it's a wonderful thing to attack various parts of the 
>> infrastructure. I have no idea what kind of thrill they get but it's a 
>> fact of life today. The only way to secure your NTP infrastructure is 
>> using autokey. If you don't have that you can't rely on the Stratum 1 
>> server.
> 
> 
> Thank you for your comment.
> I agree you that the time infrastructure should be protected by
> some security technology.
> 
> Beside the development of the high-throughput SNTP server, I'm
> participating in the development of Secure-Time-Stamping server
> based on the PKI or the link protocol.
> Through this development, I learnt security is a severe matter.
> 

This would be interesting to us though I am not sure in what way this 
would be different from NTP in concept. Please elaborate or point us to 
some documentation on this. NTP currently does not support PKI though it 
could.

> Anyway,
> NTP should be protected also, but I believe non-security-protected
> server may be also worth existing for some restricted purposes
> including some kind of public services.
> 

Yes, many people don't bother to authenticate the servers and that's the 
default in NTP. I'm not sure how much longer that can last before 
someone gets burnt by an attack or interference on an NTP server.

> Do you think any of non-security-protected servers are useless
> or harmful?
> 

No, there are many uses for them, particularly for people who don't want 
to sign up and get a key for a server. The SNTP clients don't use it and 
  are quite happy with it. I suspect that > 99% of the users of NTP are 
not using authentication, though I admit I have conducted no surveys. It 
would be useful to have some actual facts about this instead of my 
speculation.

Hopefully the larger corporate networks are taking steps and using 
authentication, but I don't hold my breath on this one either. A great 
deal depends on reliable accurate time particularly when it comes to 
things like timestamping transactions, logging activities across a 
network, securing your DNS infrastructure, etc.

Danny

> tori
> 
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Hiroshi Toriyama wrote:
> Danny Mayer wrote:
> 
>> However, in order to provide reliable time you need to know that the 
>> packet is coming from the place you think it is. In today's world it's 
>> necessary to secure the infrastructure. There too many people who now 
>> think it's a wonderful thing to attack various parts of the 
>> infrastructure. I have no idea what kind of thrill they get but it's a 
>> fact of life today. The only way to secure your NTP infrastructure is 
>> using autokey. If you don't have that you can't rely on the Stratum 1 
>> server.
> 
> 
> Thank you for your comment.
> I agree you that the time infrastructure should be protected by
> some security technology.
> 
> Beside the development of the high-throughput SNTP server, I'm
> participating in the development of Secure-Time-Stamping server
> based on the PKI or the link protocol.
> Through this development, I learnt security is a severe matter.
> 

This would be interesting to us though I am not sure in what way this
would be different from NTP in concept. Please elaborate or point us to
some documentation on this. NTP currently does not support PKI though it
could.

> Anyway,
> NTP should be protected also, but I believe non-security-protected
> server may be also worth existing for some restricted purposes
> including some kind of public services.
> 

Yes, many people don't bother to authenticate the servers and that's the
default in NTP. I'm not sure how much longer that can last before
someone gets burnt by an attack or interference on an NTP server.

> Do you think any of non-security-protected servers are useless
> or harmful?
> 

No, there are many uses for them, particularly for people who don't want
to sign up and get a key for a server. The SNTP clients don't use it and
  are quite happy with it. I suspect that > 99% of the users of NTP are
not using authentication, though I admit I have conducted no surveys. It
would be useful to have some actual facts about this instead of my
speculation.

Hopefully the larger corporate networks are taking steps and using
authentication, but I don't hold my breath on this one either. A great
deal depends on reliable accurate time particularly when it comes to
things like timestamping transactions, logging activities across a
network, securing your DNS infrastructure, etc.

Danny

> tori
> 

_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny Mayer wrote:
> Hopefully the larger corporate networks are taking steps and using
> authentication, but I don't hold my breath on this one either. A great
> deal depends on reliable accurate time particularly when it comes to
> things like timestamping transactions, logging activities across a
> network, securing your DNS infrastructure, etc.

We have a pretty large corporate international network, and even though
most of my servers support authentication, nobody is using it so far.

The only way to 'take over' at least three of my servers would be by
taking control of routing at the Cisco and/or Nortel routers & switches,
and if you can do this, then I am a lot more worried about the Cisco
boxes than a potentially wrong timestamp on one of my regular servers.

With a properly configured ntp network it is _extremely_ hard to use
subverted ntp servers to attack regular machines via something like
kerberos replay:

As long as the maximum capture range of ntpd is 500 ppm, and you don't
use ntpdate ever, you have to take over a majority of all configred ntp
servers, then wait until the relevant server is restarted, something
which happens _very_ rarely on our unix systems.

Without a restart, you can't depend on more than about 300-400 ppm drift
rate, corresponding to about half a minute/day. I have not been able to
figure out any way in which this can be used for an attack?

Terje

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