Re: [ntp:questions] new driver development
On Sat, 19 Mar 2011 22:06:16 -0500, Hal Murray wrote: In article 2wlgp.34776$d46.31...@newsfe07.iad, Bruce Lilly bruce.li...@gmail.com writes: o POSIX mutex for synchronized access to shared memory for updates -- obviates mode 0 / mode 1 / OLDWAY I'm far from a POSIX wizard. When I google for POSIX mutex I get a bunch of hits that all are part of pthreads. Does that stuff work across processes rather than threads? The mutex needs to be in shared memory so both processes can get at it. Right? Who initializes it? Mutexes can work across processes; look for pthread_mutexattr_setpshared. The first party who needs the mutex (if not already initialized) initializes it. Destruction is another issue. There are a lot of complications (e.g. the mutex (and its attributes) typically are mapped to different addresses in different processes). POSIX semaphores are a bit simpler to use, even though a semaphore is more generic than a mutex. And POSIX semaphores come in unnamed (which can reside in shared memory) and named varieties. Unfortunately, there are plenty of implementation issues. In either (mutex/semaphore) case, there is a related issue; viz. it is unclear whether or not either will work in cross-word-size situations (i.e. on a 64-bit machine with both 64-bit and 32-bit libraries where one process is built and linked for 32-bit and the other for 64-bit), or worse (bi-endian machines). About the best one can do is to identify word size and byte order of both processes and refuse to play if there's a mismatch. I can avoid the word size and byte order issues entirely (though not without some small performance cost), and avoid the need for a semaphore or mutex as well using another IPC technology (and with a few additional benefits). But that's a story for another day. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Secure NTP
j...@specsol.spam.sux.com wrote: Richard B. Gilbert rgilber...@comcast.net wrote: Didn't I just see an announcement that GPS was going to be jammed in order to test something or other? Yeah, it happens quite often on a scheduled basis in limited areas. Hmm, it should not be all that difficult to set up a limited reach GPS WAAS/EGNOS impostor. elsewher: Bruce Schneier ( security guy ): http://www.schneier.com/blog/archives/2008/09/gps_spoofing.html uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
Bruce Lilly wrote: On Fri, 18 Mar 2011 03:16:38 +, Dave Hart wrote: On Fri, Mar 18, 2011 at 01:44 UTC, Bruce Lilly bruce.li...@gmail.com wrote: 4. Assuming specific sizes for an integer is a really bad idea... (64 bits making up the) clockTimeStamp* and receiveTimeStamp* fields Actually nailing down the sizes of objects is a really good idea when sharing binary structures across separately-compiled programs. We cannot presume the same compiler and options build ntpd and anything that attempts to share memory with it. We need not (and should not) worry about endianness for a shared memory contract, though. Thanks for playing, Endianness (and more generally byte order) are of concern for precisely the same reasons. Perhaps you are unfamiliar with: http://en.wikipedia.org/wiki/Endianness#Bi-endian_hardware Hmm, For that use case I would stay with net byte order anyway. uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
Bruce Lilly bruce.li...@gmail.com wrote: On Fri, 18 Mar 2011 03:16:38 +, Dave Hart wrote: On Fri, Mar 18, 2011 at 01:44 UTC, Bruce Lilly bruce.li...@gmail.com wrote: 4. Assuming specific sizes for an integer is a really bad idea... (64 bits making up the) clockTimeStamp* and receiveTimeStamp* fields Actually nailing down the sizes of objects is a really good idea when sharing binary structures across separately-compiled programs. We cannot presume the same compiler and options build ntpd and anything that attempts to share memory with it. We need not (and should not) worry about endianness for a shared memory contract, though. Thanks for playing, Endianness (and more generally byte order) are of concern for precisely the same reasons. This is not relevant in the case of shared memory, as long as the memory is not shared between processors of different endianess. For the scope of this driver, we can safely assume it isn't. Those that have constructed a system where one processor is writing the shared memory, and a different endianess processor is running the ntpd, are probably able to write their own software to handle it. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
Rob wrote: Bruce Lilly bruce.li...@gmail.com wrote: Endianness (and more generally byte order) are of concern for precisely the same reasons. This is not relevant in the case of shared memory, as long as the memory is not shared between processors of different endianess. For the scope of this driver, we can safely assume it isn't. Those that have constructed a system where one processor is writing the shared memory, and a different endianess processor is running the ntpd, are probably able to write their own software to handle it. http://en.wikipedia.org/wiki/Endianness#Bi-endian_hardware The only even remotely relevant platform imho is ARM But you are right, it should not be a problem for properly written and source distributed software. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
Bruce Co., You may not be aware that all Spectracom devices are supported with one driver, all TrueTime devices are supported with one driver, all telephone modem services are supported with one driver, all Austron devices are supported with one driver, all Heath devices are supported with one driver and most GPS receivers are supported with one driver. This happened with many hours of dedicated effort on the part of refclock developers. You can appreciate the serious pushback in creating a new driver if a similar one is already available. An appropriate plan is [common interface code] #ifdef POSIX ... #else ... #endif Dave Bruce Lilly wrote: On Fri, 18 Mar 2011 04:51:40 +, Harlan Stenn wrote: I don't see this one. If flag1 0 (the current default) means SVID, and we decide that flag1 1 means POSIX, what is the issue? How is that significantly different from changing 127.127.28.x to 127.127.y.x ? Among others, 1. The following is workable: server 127.127.28.1 ... server 127.127.y.1 ... Your proposal in this respect, viz.: server 127.127.28.1 ... fudge 127.127.28.1 flag1 0 ... server 127.127.28.1 ... fudge 127.127.28.1 flag1 1 ... simply won't work. IOW, one can have 4 units ea. using different drivers, but one cannot have multiple devices sharing the same driver and unit numbers but differing flags (or ttl, etc.) 2. With separate drivers, each can perform appropriate initialization via the clock_init function pointer in its struct refclock structure. One cannot alter the way that works based on flag or ttl values as neither are accessible; the prototype is: void (*clock_init) (void); I.e. no pointer to a peer structure. They are separate issues. We support timespec where it exists. We want to support timespec under SHM regardless. If I thought that was feasible, I would have done it and submitted patches a year ago. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Secure NTP
Uwe Klein uwe_klein_habertw...@t-online.de wrote: j...@specsol.spam.sux.com wrote: Richard B. Gilbert rgilber...@comcast.net wrote: Didn't I just see an announcement that GPS was going to be jammed in order to test something or other? Yeah, it happens quite often on a scheduled basis in limited areas. Hmm, it should not be all that difficult to set up a limited reach GPS WAAS/EGNOS impostor. elsewher: Bruce Schneier ( security guy ): http://www.schneier.com/blog/archives/2008/09/gps_spoofing.html uwe OK, so the bad guy sets up the stuff for a GPS spoofer and parks it next to the targeted building where high dollar value stuff goes on in hopes of tweeking their system clocks and stealing a fortune. First issue; a big bucks operation is likely in a multi-story building with the GPS antenna on the roof and GPS antennas have low sensitivity looking down. Our bad guys just happen to know something about antenna patterns, so they obtained some high power RF amplifiers to make sure their signal dominates. So, after carefully syncing their spoofer to the real time, because if they don't, the time jump will just be rejected, the bad guys start cranking up the output power until their signal dominates. At that point they start slowly changing the time to something else. Meanwhile, inside the building where NTP was set up by someone with a clue that bothered to read the documentation, the target client computers notice that the GPS source is different than all the other sources and decide the GPS source has failed and ignore the GPS data. Drat that NTP voting alogorithm. -- Jim Pennino Remove .spam.sux to reply. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] peer command and clusters
On 03/26/2011 08:46 AM, Dave Hart wrote: You probably want iburst on each of those server lines, to sync the clock in under 15 seconds instead of a few minutes. I thought that was frowned upon, to use iburst with public servers? (I do use iburst, from all the other machines to the internal NTP servers.) -- Florin Andrei http://florin.myip.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] peer command and clusters
On 03/26/2011 03:36 AM, Rob wrote: Florin Andreiflo...@andrei.myip.org wrote: restrict 0.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery restrict 1.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery restrict 2.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery restrict 3.us.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery This does not work! The names like 0.us.pool.ntp.org return multiple IP adresses and the server and restrict lines will not match. The ntpd version we're using is pretty old and does not support the source keyword. Since the local NTP servers are behind a firewall and are not reachable from the outside, should this matter at all? -- Florin Andrei http://florin.myip.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] new driver development
David L. Mills mi...@udel.edu wrote: Bruce Co., You may not be aware that all Spectracom devices are supported with one driver, all TrueTime devices are supported with one driver, all telephone modem services are supported with one driver, all Austron devices are supported with one driver, all Heath devices are supported with one driver and most GPS receivers are supported with one driver. This happened with many hours of dedicated effort on the part of refclock developers. You can appreciate the serious pushback in creating a new driver if a similar one is already available. An appropriate plan is [common interface code] #ifdef POSIX ... #else ... #endif Dave Do you really believe that compile-time configuration will cut it in 2011? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Secure NTP
j...@specsol.spam.sux.com wrote: At that point they start slowly changing the time to something else. Meanwhile, inside the building where NTP was set up by someone with a clue if you go by the questions placed here on occasion that assumption is not a given ;-) that bothered to read the documentation, the target client computers notice that the GPS source is different than all the other sources and decide the GPS source has failed and ignore the GPS data. Drat that NTP voting alogorithm. engineering is a management of negatives ( positives is for weenies ) If I had that clocker job (not likely) I would disable all but one source and spoof the remaining in advance. my guess is that even most high profile setups won't complain about being reduced to a single source for time. Manipulating trading systems probably is high risk, high gain so some expenditure would be acceptable. The thing that saves us here is the same that saves us from hideously effective terrorist bombs. Criminal and ideological baddies tend to lack real engineering talent. But I wouldn't bet on that in all cases. uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] peer command and clusters
Let's assume I upgrade to a newer version that accepts the source keyword. Then how about this config? Is there are risk of too many internal servers picking other internal servers to sync their time - and not enough servers using external sources? Should I skew the selection using prefer with the external servers? Ideally, I'd like most of my NTP servers to use the public pool most of the time. The peers are there just in case. But if some of my servers sync up preferentially to some other internal servers, that's fine. server 0.us.pool.ntp.org server 1.us.pool.ntp.org server 2.us.pool.ntp.org server 3.us.pool.ntp.org restrict source nomodify notrap noquery # comment out your own name # peer ntp1 #peer ntp2 peer ntp3 peer ntp4 peer ntp5 peer ntp6 driftfile /var/lib/ntp/drift # allow NTP clients to query this server # restrict XXX.YYY.ZZZ.0 mask 255.255.255.0 nomodify notrap # allow local queries # restrict 127.0.0.0 mask 255.0.0.0 # disallow everybody else # restrict default ignore -- Florin Andrei http://florin.myip.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Secure NTP
Uwe Klein uwe_klein_habertw...@t-online.de wrote: j...@specsol.spam.sux.com wrote: At that point they start slowly changing the time to something else. Meanwhile, inside the building where NTP was set up by someone with a clue if you go by the questions placed here on occasion that assumption is not a given ;-) that bothered to read the documentation, the target client computers notice that the GPS source is different than all the other sources and decide the GPS source has failed and ignore the GPS data. Drat that NTP voting alogorithm. engineering is a management of negatives ( positives is for weenies ) If I had that clocker job (not likely) I would disable all but one source and spoof the remaining in advance. my guess is that even most high profile setups won't complain about being reduced to a single source for time. You are talking about an inside job and neither NPT authentication nor any other software based tool is able to do much about that. If you are already inside, there are easier and more direct ways to steal than messing with system clocks. I deal with an organization where the correct time is modestly (in terms of what NTP can do) important. It is important to them that all systems are within about 0.25 seconds of the real time. The local division I support has three systems set up as NTP servers and a stand alone GPS NTP box to provide time for all the division client systems. The three NTP servers get their time from the local GPS NTP box as well as other GPS NTP boxes and CDMA NTP boxes located at other corporate sites hundreds of miles away on the private corporate network and additionally from several public NTP servers on the Internet. Spoof that. -- Jim Pennino Remove .spam.sux to reply. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Secure NTP
On Mon, Mar 28, 2011 at 8:56 AM, j...@specsol.spam.sux.com wrote: OK, so the bad guy sets up the stuff for a GPS spoofer and parks it next to the targeted building where high dollar value stuff goes on in hopes of tweeking their system clocks and stealing a fortune. The best application of GPS signal spoofing would be at sea. You could ship your jammer/spoofer as cargo and have it steer the ship off course. After a day or two of being subtly off course the error could add up to hundreds of miles. then you meet it at some point and even if the ship transmits an SOS the location will be far from the real location and the authorities will respond to some place you are not. However a competent ships captain would periodically check GPS using some other method, maybe even celestial navigation. For truck hijacking a simple jammer is used to disable any GPS tracking. A spoofed gps could never fool a driver into thinking he is 100 miles away and driving off road. Even a totally confused and lost truck driver knows he is on a road. The obvious case where you'd like to spoof GPS is if you are being targeted by GPS guided smart bombs or cruise missiles. The trouble is that the designers of said weapons have already figured that you might be using a jammer and have planned for that. -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] peer command and clusters
On Mon, Mar 28, 2011 at 6:47 PM, Florin Andrei flo...@andrei.myip.org wrote: Let's assume I upgrade to a newer version that accepts the source keyword. Then how about this config? Is there are risk of too many internal servers picking other internal servers to sync their time - and not enough servers using external sources? Should I skew the selection using prefer with the external servers? Prefer only comes into play numbering seconds for the PPS refclock, I believe. I think the stratum self-organization will take care of your internal vs. external concern. server 0.us.pool.ntp.org server 1.us.pool.ntp.org server 2.us.pool.ntp.org server 3.us.pool.ntp.org restrict source nomodify notrap noquery # comment out your own name # peer ntp1 #peer ntp2 No need, ntpd will not configure an address that is local as a remote source. peer ntp3 peer ntp4 peer ntp5 peer ntp6 driftfile /var/lib/ntp/drift # allow NTP clients to query this server # restrict XXX.YYY.ZZZ.0 mask 255.255.255.0 nomodify notrap # allow local queries # restrict 127.0.0.0 mask 255.0.0.0 restrict ::1 # ntpq/ntpdc tend to use ::1 before 127.0.0.1 # disallow everybody else # restrict default ignore Seems reasonable to me. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] peer command and clusters
Florin Andrei wrote: On 03/26/2011 08:46 AM, Dave Hart wrote: You probably want iburst on each of those server lines, to sync the clock in under 15 seconds instead of a few minutes. I thought that was frowned upon, to use iburst with public servers? (I do use iburst, from all the other machines to the internal NTP servers.) Afaik ibrust was modified to stay underneath the abuse threshold some time ago, probably in the same timeframe as the Kiss of Death packets? Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] peer command and clusters
On 2011-03-28, Florin Andrei flo...@andrei.myip.org wrote: On 03/26/2011 08:46 AM, Dave Hart wrote: You probably want iburst on each of those server lines, to sync the clock in under 15 seconds instead of a few minutes. I thought that was frowned upon, to use iburst with public servers? (I do use iburst, from all the other machines to the internal NTP servers.) 'burst' is a permanent multiplier which causes a burst of packets to be sent at expiration of _every_ poll period. 'iburst' is a temporary multiplier which causes a burst of packets to be sent at expiration of each poll poll period _only_ when a remote time server is unreachable. The stable release uses bursts of 8 packets while ntp-dev uses bursts of 6 packets. Documentation references: Current Stable -- http://doc.ntp.org/4.2.6p3/confopt.html burst -- When the server is reachable, send a burst of eight packets instead of the usual one. The packet spacing is normally 2 s; however, the spacing between the first and second packets can be changed with the calldelay command to allow additional time for a modem or ISDN call to complete. This option is valid only with the server command and type s addressesa. It is a recommended option when the maxpoll option is greater than 10 (1024 s). iburst -- When the server is unreachable, send a burst of eight packets instead of the usual one. The packet spacing is normally 2 s; however, the spacing between the first and second packets can be changed with the calldelay command to allow additional time for a modem or ISDN call to complete. This option is valid only with the server command and type s addresses. IT IS A RECOMMENDED OPTION WITH THIS COMMAND. (emphasis added) NTP Dev -- http://www.eecis.udel.edu/~mills/ntp/html/confopt.html burst -- When the server is reachable, send a burst of packets instead of the usual one. This option is valid only with the server command and type s addresses. It is a recommended option when the maxpoll option is greater than 10 (1024 s). Additional information about this option is on the Poll Program page. iburst -- When the server is unreachable, send a burst of packets instead of the usual one. This option is valid only with the server command and type s addresses. IT IS A RECOMMENDED OPTION WITH THIS COMMAND. Additional information about this option is on the Poll Program page. (emphasis added) Poll Program page http://www.eecis.udel.edu/~mills/ntp/html/poll.html The burst options can result in increased load on the network if not carefully designed. Both options are affected by the provisions described on the Rate Management and the Kiss-o'-Death Packet page. In addition, when iburst or burst are enabled, the first packet of the burst is sent, but the remaining packets sent only when the reply to the fist packet is received. If no reply has been received after a timeout set by the minpoll option, the first packet is sent again. This means that, even if a server is unreachable, the network load is no more than at the minimum poll interval. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] peer command and clusters
On 2011-03-25, Florin Andrei flo...@andrei.myip.org wrote: Two groups of machines in two datacenters, VPN line in between. A VPN will introduce jitter into any associations between your two data centers. An unencrypted UDP connection would be better. Two NTP servers in each datacenter, sync'ing to public servers. Local networks are gig ethernet. GigE introduces some packet queueing issues ... but that's not relevant to this article. Sometimes there seem to be issues with the public servers, so I figured I may as well use the peer command to at least keep the local servers as close to each other as possible, since I've a few clusters where it's more important that all members agree on the same time base, even when that base might not be very accurate. So I came up with this configuration for the local NTP servers. Please criticize it. Assuming that your LAN time servers are behind a firewall (or NAT) and the NTP port is not forwarded I'd rewrite your configuration as: driftfile /var/lib/ntp/drift # Default restrictions restrict default nomodify notrap noquery restrict 127.0.0.0 # Authorized clients restrict XXX.YYY.ZZZ.0 mask 255.255.255.0 nomodify notrap # Internal peers. ntpd will ignore itsself peer ntp1 peer ntp2 peer ntp3 peer ntp4 # Remote time servers server 0.us.pool.ntp.org iburst server 1.us.pool.ntp.org iburst server 2.us.pool.ntp.org iburst server 3.us.pool.ntp.org iburst You may also wish to consider the use of Orphan Mode (or, depending on the version of NTP you're using, the Undisciplined Local Clock) to provision a local master in the event you lose your external network connections. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] peer command and clusters
On 3/28/2011 1:16 PM, Florin Andrei wrote: On 03/26/2011 08:46 AM, Dave Hart wrote: You probably want iburst on each of those server lines, to sync the clock in under 15 seconds instead of a few minutes. I thought that was frowned upon, to use iburst with public servers? (I do use iburst, from all the other machines to the internal NTP servers.) iburst is seldom a problem for a server. Iburst sends something like eight NTP request packets at two second intervals during startup. This is enough to fill the filter pipeline and get an initial value for the correct time. Few people would object to this. Burst mode is somewhat different. It sends several requests at each and every interval. Its use is seldom appropriate and is almost always unwelcome unless YOU own the server or have the owner's permission! ISTR that burst mode was intended for use by clients using dialup telephone lines to query the server. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] peer command and clusters
Florin Andrei wrote: On 03/26/2011 08:46 AM, Dave Hart wrote: You probably want iburst on each of those server lines, to sync the clock in under 15 seconds instead of a few minutes. I thought that was frowned upon, to use iburst with public servers? (I do use iburst, from all the other machines to the internal NTP servers.) It is usually acceptable to use iburst as long as you are not repeatedly restarting ntpd. There is also burst which IS frowned on and you should have had permission from the target server sysadmin before using it. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Secure NTP
Chris Albertson albertson.ch...@gmail.com wrote: On Mon, Mar 28, 2011 at 8:56 AM, j...@specsol.spam.sux.com wrote: OK, so the bad guy sets up the stuff for a GPS spoofer and parks it next to the targeted building where high dollar value stuff goes on in hopes of tweeking their system clocks and stealing a fortune. The best application of GPS signal spoofing would be at sea. You could ship your jammer/spoofer as cargo and have it steer the ship off course. After a day or two of being subtly off course the error could add up to hundreds of miles. then you meet it at some point and even if the ship transmits an SOS the location will be far from the real location and the authorities will respond to some place you are not. However a competent ships captain would periodically check GPS using some other method, maybe even celestial navigation. For this to work, your spoofer has to spoof 4 satellites as well as know its actual position independant of GPS so the ship is steered to somewhere that you can find it. Most civilian ships these days have neither the people or equipment to do celestial navigation. And all of this is pointless as once the ship is any significant distance at sea as all you have to do is attack the ship from a faster boat that is well armed. Google Somali pirates. For truck hijacking a simple jammer is used to disable any GPS tracking. A spoofed gps could never fool a driver into thinking he is 100 miles away and driving off road. Even a totally confused and lost truck driver knows he is on a road. So GPS tracking is AFU. All that means is the trucking compay is unable to say for sure the driver didn't spend a couple of hours at the boobie bar. It doesn't do much for you unless you intend to steal the entire truck and keep it for long that the cops become involved. -- Jim Pennino Remove .spam.sux to reply. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Venting steam: Autokey in 4.2.6/4.2.7
http://support.ntp.org/bin/view/Support/ConfiguringAutokey For ntpd 4.2.4 and earlier, Steve Kostecke patiently worked out step-by-step instructions, and refined them over time heping people to use them, as seen on the page referenced above. For 4.2.6 ntp-keygen and autokey got an overhaul which makes those instructions useless. To investigate http://bugs.ntp.org/1840 and http://bugs.ntp.org/1864 filed by Rich Schmidt about ntpd 4.2.7 crashing when attempting to use Autokey, and to test a change to remove a presumed unneeded line of code (ntp_crypto.c:2984) identified through static analysis, I once again have tried to get a basic Autokey setup working. So far I have spent hours and achieved nothing but failure and humiliation. This is with Rich holding my hand telling me what to do. I'm so pissed off I want a baseball bat and an effigy. Now, granted, I'm not scratching an itch to secure my NTP, I'm scratching an itch to reproduce a fault and fix it, so i'm not typical, but if i were trying to secure my NTP, I'd use symmetric key. Autokey is very clever in dealing with some unique challenges other PKI OpenSSL client code doesn't have to. Anyone attempting to configure it should be on payroll, if not time and a half. (insert series of profanities here) Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Venting steam: Autokey in 4.2.6/4.2.7
Dave, When all else fails, read the documentation. There were good reasons to change the configuration in minor ways. 1. There was a huge vulnerability if the identity file was specified by the server, but the correct file was not specified by the client. The scheme devolved to TC with no warring to the user. 2. Multiple secure groups (including anycast and pool) sharing the same broadcast network are supported. The primary intent is to provide an engineered selection of pool servers from the same DNS collection. 3. Configuration is much simpler and for the TC identity scheme requires no arguments on the ntp-keygen program or crypto configuration command. 4. Configuration for prior versions is possible; see the documentation. I sent you a message requesting to test this before deployment. Dave .Dave Hart wrote: http://support.ntp.org/bin/view/Support/ConfiguringAutokey For ntpd 4.2.4 and earlier, Steve Kostecke patiently worked out step-by-step instructions, and refined them over time heping people to use them, as seen on the page referenced above. For 4.2.6 ntp-keygen and autokey got an overhaul which makes those instructions useless. To investigate http://bugs.ntp.org/1840 and http://bugs.ntp.org/1864 filed by Rich Schmidt about ntpd 4.2.7 crashing when attempting to use Autokey, and to test a change to remove a presumed unneeded line of code (ntp_crypto.c:2984) identified through static analysis, I once again have tried to get a basic Autokey setup working. So far I have spent hours and achieved nothing but failure and humiliation. This is with Rich holding my hand telling me what to do. I'm so pissed off I want a baseball bat and an effigy. Now, granted, I'm not scratching an itch to secure my NTP, I'm scratching an itch to reproduce a fault and fix it, so i'm not typical, but if i were trying to secure my NTP, I'd use symmetric key. Autokey is very clever in dealing with some unique challenges other PKI OpenSSL client code doesn't have to. Anyone attempting to configure it should be on payroll, if not time and a half. (insert series of profanities here) Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Venting steam: Autokey in 4.2.6/4.2.7
On Tue, Mar 29, 2011 at 12:53 AM, David L. Mills mi...@udel.edu wrote: I sent you a message requesting to test this before deployment. I was referring to docs galore as I thrashed about earlier. I don't doubt each of your changes was an improvement, but each one also made Steve's 4.2.4 step-by-step guide less useful. I was looking at: http://www.eecis.udel.edu/~mills/ntp/html/autokey.html http://www.eecis.udel.edu/~mills/ntp/html/autokey.html http://www.eecis.udel.edu/~mills/ntp/html/keygen.html http://www.eecis.udel.edu/~mills/ntp/html/keygen.html http://support.ntp.org/bin/view/Support/ConfiguringAutokey http://support.ntp.org/bin/view/Support/ConfiguringAutokey http://bugs.ntp.org/1864 https://bugs.ntp.org/show_bug.cgi?id=1864 BTW keygen.html mentions a -l days option which ntp-keygen doesn't understand, do you want me to fix the options processing so it does? Or get rid of that item from the docs? I'm not the dimmest bulb on the block, but when I was interested in reproducing the crash reported in bug 1864 and 1840, I didn't manage to. And I spent several hours trying. The crash may be a bug I introduced in ntp_config generic FIFO code that replaced the degenerate use of priority queues as FIFOs in Sachim's original ntp.conf parser rewrite. I was focused on getting past the configuration issues to debug the configuration code, not on setting up a working Autokey. That said, Steve has kindly dove in head first and is extracting me from my confusion one step at a time. I never forgot that you wanted me to test pool + autokey operation, I just feared and loathed the idea of setting up autokey again from scratch and have had other things to keep me busy. I'm optimistic Steve will be able to help me get a working setup to test pool + autokey and also to see if ntp_crypto.c:2984 really is unneeded. Cheers, Dave Hart http://support.ntp.org/bin/view/Support/ConfiguringAutokey ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
