Re: NIST NTP servers

2016-05-10 Thread Eric Kuhnke
For quite some time, in debian the default configuration for the ntpd.conf that ships with the package for the ntpd is to poll from four different, semi-randomly assigned DNS pool based sources. I believe the same is true for redhat/centos. In the event that one out of four sources is wildly

Re: NIST NTP servers

2016-05-10 Thread Joe Klein
Is this group aware of the incident with tock.usno.navy.mil & tick.usno.navy.mil on November 19. 2012 2107 UTC, when the systems lost 12 years for the period of one hour, then return? The reasons were not fully explained, but the impact was global. Routers, switches, power grids, phone systems,

Re: NIST NTP servers

2016-05-10 Thread Roland Dobbins
On 11 May 2016, at 8:59, Mel Beckman wrote: My point is, when the fix is so cheap, why put up with this risk at all? Time and Position Spoofing With Open Source Projects. [.pdf link]

Re: NIST NTP servers

2016-05-10 Thread Chris Adams
Once upon a time, Mel Beckman said: > Boss: So how did a hacker get in and crash our accounting server, break our > VPNs, and kill our network performance? > > IT guy: He changed our clocks. So, this has been repeated several times (with how bad things will go if your clocks

Re: NIST NTP servers

2016-05-10 Thread Mel Beckman
Boss: So how did a hacker get in and crash our accounting server, break our VPNs, and kill our network performance? IT guy: He changed our clocks. Boss: How did he do that? IT guy: We have an opening in our firewall that permits time clock packets to come from anywhere in the world, under

Re: NIST NTP servers

2016-05-10 Thread Jared Mauch
> On May 10, 2016, at 4:40 PM, Gary E. Miller wrote: > > Yo Jared! > Yo, Gary! > On Tue, 10 May 2016 16:29:26 -0400 > Jared Mauch wrote: > >> If you’re using Redhat based systems consider using chrony >> instead, even the new beta fedora 24 uses

Re: NIST NTP servers

2016-05-10 Thread Gary E. Miller
Yo Jared! On Tue, 10 May 2016 16:29:26 -0400 Jared Mauch wrote: > If you’re using Redhat based systems consider using chrony > instead, even the new beta fedora 24 uses 4.2.6 derived code > vs 4.2.8 Or, new but under heavy development: NTPsec : https://www.ntpsec.org/

Re: NIST NTP servers

2016-05-10 Thread Jared Mauch
> On May 10, 2016, at 4:21 PM, Harlan Stenn wrote: > >> Configure all of your devices to get NTP from the servers you run >> using authentication. > > Yes, and properly monitor your ntpd instances. And upgrade them. Some software distributors don’t ship modern software. if

Re: NIST NTP servers

2016-05-10 Thread Gary E. Miller
Yo Chuck! On Tue, 10 May 2016 16:18:41 -0400 "Chuck Church" wrote: > Ok, annoyance might have been a little light on the severity wording. Yup. > Still, modifying all your incoming NTP packets from all your sources > to actually get your NTP servers to agree on a bad

Re: NIST NTP servers

2016-05-10 Thread Mel Beckman
Accurate time to the millisecond is pretty much essential for any network troubleshooting. Say you want to diagnose a SIP problem. You collect transaction logs from both phones, the VoIP gateway, and the PBX. Now you try to merge them to derive the sequence of events. You NEED millisecond

Re: NIST NTP servers

2016-05-10 Thread Harlan Stenn
Leo Bicknell writes: > ... > > The correct answer here is to run multiple NTP servers in your > network. And by servers I mean real servers, with good quality > oscellators on the motherboard. Then configure them to talk to > _many_ sources. You need 4 sources of time minimum to redundantly >

RE: NIST NTP servers

2016-05-10 Thread Chuck Church
-Original Message- From: Gary E. Miller [mailto:g...@rellim.com] Sent: Tuesday, May 10, 2016 3:58 PM To: Chuck Church Cc: 'Majdi S. Abbas' ; nanog@nanog.org Subject: Re: NIST NTP servers Yo Chuck! On Tue, 10 May 2016 10:29:35 -0400 "Chuck Church"

Re: NIST NTP servers

2016-05-10 Thread Jared Mauch
> On May 10, 2016, at 3:58 PM, Gary E. Miller wrote: > > I'm sure there are many more examples, but likely you can no longer log > in, via SSH or HTTPS, and your iPhone is dead. I think any of those > would qualify as more than an annoyance. An unnamed vendor has code where

Re: CALEA

2016-05-10 Thread Josh Reynolds
The first rule of prism is... *silence* :) On Tue, May 10, 2016 at 3:04 PM, Christopher Morrow wrote: > > > On Tue, May 10, 2016 at 4:00 PM, Josh Reynolds wrote: >> >> This is a large list that includes many Tier 1 network operators, >>

Re: CALEA

2016-05-10 Thread Christopher Morrow
On Tue, May 10, 2016 at 4:00 PM, Josh Reynolds wrote: > This is a large list that includes many Tier 1 network operators, > government agencies, and Fortune 500 network operators > ​no one gets calea requests because prism gets all requests?​

Re: CALEA

2016-05-10 Thread Josh Reynolds
This is a large list that includes many Tier 1 network operators, government agencies, and Fortune 500 network operators. The silence should be telling. On May 10, 2016 2:52 PM, "Matt Hoppes" wrote: > Perhaps the silence is an indication no one is doing CALEA

Re: NIST NTP servers

2016-05-10 Thread Gary E. Miller
Yo Chuck! On Tue, 10 May 2016 10:29:35 -0400 "Chuck Church" wrote: > Changing time on > devices is more an annoyance than anything, and doesn't necessarily > get you into a device. So, you are not worried about getting DoS'ed? How about you set the time on your server

Re: CALEA

2016-05-10 Thread Matt Hoppes
Perhaps the silence is an indication no one is doing CALEA or knows anything about it? Personally, I can't say I've heard anything about CALEA, seen people trying to sell CALEA appliances, or received a CALEA request in maybe 8 years? On 5/10/16 12:34 AM, Josh Reynolds wrote: Hrm? On May

TeamNANOG youtube video seeding

2016-05-10 Thread james machado
First I am thrilled to see older Nanog meetings making it to youtube. Having said that can the people putting up the files put the Nanog meeting number in the title of the videos to make it easier to search and determine relevance? Thanks, james

Re: NIST NTP servers

2016-05-10 Thread Laszlo Hanyecz
On 2016-05-10 15:36, Mike wrote: On 5/10/2016 11:22 AM, Leo Bicknell wrote: In a message written on Mon, May 09, 2016 at 11:01:23PM -0400, b f wrote: In search of stable, disparate stratum 1 NTP sources. http://wpollock.com/AUnix2/NTPstratum1PublicServers.htm We tried using “time.nist.gov”

Re: NIST NTP servers

2016-05-10 Thread Mike
On 5/10/2016 11:22 AM, Leo Bicknell wrote: > In a message written on Mon, May 09, 2016 at 11:01:23PM -0400, b f wrote: >> In search of stable, disparate stratum 1 NTP sources. > > http://wpollock.com/AUnix2/NTPstratum1PublicServers.htm > >> We tried using “time.nist.gov” which returns varying

Re: NIST NTP servers

2016-05-10 Thread Valdis . Kletnieks
On Tue, 10 May 2016 08:07:15 -0700, Brandon Vincent said: > On May 10, 2016 7:59 AM, "Stephane Bortzmeyer" wrote: > > Yes, but they may switch it off for civilian use (by going encrypted, > > for instance) at any time, if it is better for *their* operations. > > I think you are

Re: NIST NTP servers

2016-05-10 Thread Josh Reynolds
That would be a very poor idea, since a lot of the circuits the DoD still uses to communicate with are ATM lines :) On Tue, May 10, 2016 at 9:59 AM, Stephane Bortzmeyer wrote: > On Tue, May 10, 2016 at 10:52:28AM -0400, > valdis.kletni...@vt.edu

Re: NIST NTP servers

2016-05-10 Thread Leo Bicknell
In a message written on Mon, May 09, 2016 at 11:01:23PM -0400, b f wrote: > In search of stable, disparate stratum 1 NTP sources. http://wpollock.com/AUnix2/NTPstratum1PublicServers.htm > We tried using “time.nist.gov” which returns varying round-robin addresses > (as the link says), but Cisco

Re: NIST NTP servers

2016-05-10 Thread Stephane Bortzmeyer
On Tue, May 10, 2016 at 10:52:28AM -0400, valdis.kletni...@vt.edu wrote a message of 37 lines which said: > Note that they *do* have motivation to keep it working, simply > because so much of their *own* gear (from gear for individual > soldiers all the way to

RE: NIST NTP servers

2016-05-10 Thread Chuck Church
True, but I did mention verifying packet sources. That needs to happen everywhere, and it's not hard to do. Just getting everyone to do it is tough. Chuck -Original Message- From: Allan Liska [mailto:al...@allan.org] Sent: Tuesday, May 10, 2016 10:40 AM To: Chuck Church

Re: NIST NTP servers

2016-05-10 Thread David Hubbard
Ed, and anyone else reading this thread, I’m curious if you’ve looked at their authenticated NTP offering which uses different servers: http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm We’re considering that but haven’t tried yet. David On 5/9/16, 11:01 PM, "NANOG on behalf of b f"

Re: NIST NTP servers

2016-05-10 Thread Valdis . Kletnieks
On Tue, 10 May 2016 16:39:54 +0200, Stephane Bortzmeyer said: > You mean the GPS network is not managed by an external entity? With > budget issues? > > http://www.schriever.af.mil/GPS Note that they *do* have motivation to keep it working, simply because so much of their *own* gear (from gear

Re: NIST NTP servers

2016-05-10 Thread Stephane Bortzmeyer
On Tue, May 10, 2016 at 06:48:52AM -0400, Steven Miano wrote a message of 41 lines which said: > Going with an internal GPS/GLONASS/RADIO based S1 allows you to > restrict incoming traffic and not rely on volunteers or external > entities (which may undergo maintenance or

RE: NIST NTP servers

2016-05-10 Thread Chuck Church
-Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Majdi S. Abbas > So how does this stop from distributing time to their customers via NTP? > GPS doesn't save the protocol, in particular where the S1 clocks involved are embedded devices with rather

Re: NIST NTP servers

2016-05-10 Thread Steven Miano
NTP has vulnerabilities, so using an external source opens your networks and infrastructure to disruptions. Going with an internal GPS/GLONASS/RADIO based S1 allows you to restrict incoming traffic and not rely on volunteers or external entities (which may undergo maintenance or budget issues).