- Test - lists.nanog.org

A briefing on NTPsec
by esr＠thyrsus.com 13 May '16

13 May '16

Jay Ashworth informs me that NTP security and risks has recently been a hot topic on NANOG, and that NTPsec was mentioned. Therefore I've written a bit of a background briefing on the project, which follows. The NTPsec project was initially funded in late 2014 by NSF when authorities there became concerned about frequent incidents of DDoS amplification involving ntpd. I was hired in as tech lead early on (in part because of my work on GPSD, a technically similar project) and retained that position when the Linux Foundation picked up funding the project. It's now managed by Mark Atwood, who some of you may know from HPE and OpenStack. I'm going to pass over the politics around the fork from what our team now calls "NTP Classic" because it wasn't my decision or desire, merely observing that I reluctantly acknowledged the necessity and wish things could have been otherwise. The goal of NTPsec is to achieve high security and high assurance through systematic application of modern best practices. Though not yet at release 1.0, our progress can be judged by the fact that when the last batch of 11 CVEs against NTP was released, we were not vulnerable to 8 of them because we had previously removed or successfully hardened the code they exploited. This was no fluke. Over the last 11 months, we have compiled a significantly - I think it's fair to say "dramatically" - better security record than Classic. We've earned some trust in the infosec research community, working effectively with (among others) Sharon Goldberg's group at BU. We were the first to develop a verified fix for the now infamous off-path KOD bug (CVE-2015-7979). You can read more about our code-hardening practices here: http://esr.ibiblio.org/?p=6881 In brief, we've thrown out a lot of cruft and archaisms. The code has been lifted to C99/POSIX-2001 conformance; other than a few warts near Mac OS X and some unused Windows code probably destined for removal itself, the port shims that used to infest the codebase are nearly gone. Mode 7 has been removed, as has Autokey; these were nests of bugs too risky to leave in. We've also done a lot of code auditing using tools like Coverity and cppcheck, and worked hard on improving our test coverage (that part has been more difficult than any of the code changes, actually, and is still very much a work in progress). Here's a figure that should tell you a lot: we removed 57% of the original codebase in the process of cleaning it up. No, that's not a typo; the NTPsec codebase is *less than half* the size of NTP Classic. And much, much easier to read. That's even without counting the huge simplification win from ditching autotools. Nevertheless, sysdamins will find it very familiar. The largest speedbump you will encounter in normal operation is that we've changed the names of some auxiliary tools so everything has an "ntp" prefix. The only thing I expect to actually surprise you is the documentation, which has been greatly improved, specifically by removing duplications and inconsistencies and distracting references to equipment that has been dead since the Late Cretaceous. So far this is a deliberately conservative fork. We haven't yet tried to add protocol features for security because there is plenty of useful work to be done before tackling that very hard problem. We're actively cooperating with the IETF NTP WG (we've committed to supplying second interop for some upcoming draft RFCs) and we're watching the work on NTS closely. It is likely, though not yet certain, that we'll be second interop on that. Finally, I note some criticism that NTPsec is short on people who understand all the subtleties of time service in the field. This is partly justified. The tech lead admits to being something of a newbie; though I know a lot about some adjacent technical areas from ten years of leading GPSD, I was not a time-service expert before being engaged for this project and am still coming up to speed. The team does already include one time-service old hand and a really good crypto/infosec specialist. NANOG listmember Gary E. Miller was an early team member who remains a friend of the project. We would certainly welcome more engagement and advice fom time-service experts, and the sort of experienced sysadmins who frequent NANOG. In a future post I may have a bit to say about Stratum 1s based on the RPi and other hackerboards. I've been working in that area as well. I'll be happy to answer technical and procedural questions about NTPsec. Any questions about politics and policy should go to Mark Atwood. See www.ntpsec.org for more information. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

3 2

A briefing on NTPsec
by esr＠thyrsus.com 13 May '16

13 May '16

Jay Ashworth informs me that NTP security and risks has recently been a hot topic on NANOG, and that NTPsec was mentioned. Therefore I've written a bit of a background briefing on the project, which follows. The NTPsec project was initially funded in late 2014 by NSF when authorities there became concerned about frequent incidents of DDoS amplification involving ntpd. I was hired in as tech lead early on (in part because of my work on GPSD, a technically similar project) and retained that position when the Linux Foundation picked up funding the project. It's now managed by Mark Atwood, who some of you may know from HPE and OpenStack. I'm going to pass over the politics around the fork from what our team now calls "NTP Classic" because it wasn't my decision or desire, merely observing that I reluctantly acknowledged the necessity and wish things could have been otherwise. The goal of NTPsec is to achieve high security and high assurance through systematic application of modern best practices. Though not yet at release 1.0, our progress can be judged by the fact that when the last batch of 11 CVEs against NTP was released, we were not vulnerable to 8 of them because we had previously removed or successfully hardened the code they exploited. This was no fluke. Over the last 11 months, we have compiled a significantly - I think it's fair to say "dramatically" - better security record than Classic. We've earned some trust in the infosec research community, working effectively with (among others) Sharon Goldberg's group at BU. We were the first to develop a verified fix for the now infamous off-path KOD bug (CVE-2015-7979). You can read more about our code-hardening practices here: http://esr.ibiblio.org/?p=6881 In brief, we've thrown out a lot of cruft and archaisms. The code has been lifted to C99/POSIX-2001 conformance; other than a few warts near Mac OS X and some unused Windows code probably destined for removal itself, the port shims that used to infest the codebase are nearly gone. Mode 7 has been removed, as has Autokey; these were nests of bugs too risky to leave in. We've also done a lot of code auditing using tools like Coverity and cppcheck, and worked hard on improving our test coverage (that part has been more difficult than any of the code changes, actually, and is still very much a work in progress). Here's a figure that should tell you a lot: we removed 57% of the original codebase in the process of cleaning it up. No, that's not a typo; the NTPsec codebase is *less than half* the size of NTP Classic. And much, much easier to read. That's even without counting the huge simplification win from ditching autotools. Nevertheless, sysdamins will find it very familiar. The largest speedbump you will encounter in normal operation is that we've changed the names of some auxiliary tools so everything has an "ntp" prefix. The only thing I expect to actually surprise you is the documentation, which has been greatly improved, specifically by removing duplications and inconsistencies and distracting references to equipment that has been dead since the Late Cretaceous. So far this is a deliberately conservative fork. We haven't yet tried to add protocol features for security because there is plenty of useful work to be done before tackling that very hard problem. We're actively cooperating with the IETF NTP WG (we've committed to supplying second interop for some upcoming draft RFCs) and we're watching the work on NTS closely. It is likely, though not yet certain, that we'll be second interop on that. Finally, I note some criticism that NTPsec is short on people who understand all the subtleties of time service in the field. This is partly justified. The tech lead admits to being something of a newbie; though I know a lot about some adjacent technical areas from ten years of leading GPSD, I was not a time-service expert before being engaged for this project and am still coming up to speed. The team does already include one time-service old hand and a really good crypto/infosec specialist. NANOG listmember Gary E. Miller was an early team member who remains a friend of the project. We would certainly welcome more engagement and advice fom time-service experts, and the sort of experienced sysadmins who frequent NANOG. In a future post I may have a bit to say about Stratum 1s based on the RPi and other hackerboards. I've been working in that area as well. I'll be happy to answer technical and procedural questions about NTPsec. Any questions about politics and policy should go to Mark Atwood. See www.ntpsec.org for more information. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> This would be the best of all possible worlds, if there were no religion in it. -- John Adams, in a letter to Thomas Jefferson.

1 0

Internet DATA Center IP base utilization/Bandwidth Billing
by sathish kumar Ippani 13 May '16

13 May '16

Hello All, We are looking for software/hardware which can monitor bandwidth usage of each IP address that enters Data center/Leave data center. Based on Bandwidth usage it will draw a graph or calculate Billing. We are running Datacenter and having 2000 and more clients. they are hosted their Network devices. -- With Regards, Sathish Ippani 9177166040

3 2

DDoS protection: Corero
by Ragnar Sigurðsson Joensen 12 May '16

12 May '16

Hello, Quick question. Is there anyone on this list using Corero for DDoS protection? If so I'd much appreciate an off-list review of it. Thanks in advance. Thanks, Ragnar Sigurðsson Joensen, rjoensen(a)synack.fo Operations, +40799694635 Sp/f Synack | synack(a)synack.fo | +298 201111

2 1

AT&T postmaster
by 🔓Dan Wing 12 May '16

12 May '16

I help run a community machine (not for my employer) and we've been trying unsuccessfully for a month to get off AT&T's email blacklist; their automated systems claim we're off, but mail is still being blocked. Can an AT&T postmaster drop me an email to help work through this? Thanks. -d

1 0

Re: NIST NTP servers
by Scott Weeks 12 May '16

12 May '16

--- mel(a)beckman.org wrote: From: Mel Beckman <mel(a)beckman.org> 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 accuracy. ---------------------------------------- If all logs are sent to a unix server that does syslogd the log entries would go into the file in order no matter what timestamp is on them. scott

3 2

Re: NIST NTP servers
by Scott Weeks 12 May '16

12 May '16

--- gem(a)rellim.com wrote: From: "Gary E. Miller" <gem(a)rellim.com> Yo Scott! On Wed, 11 May 2016 17:20:28 -0700 "Scott Weeks" <surfer(a)mauigateway.com> wrote: > If all logs are sent to a unix server that does > syslogd the log entries would go into the file > in order no matter what timestamp is on them. syslogd can have quite large buffers. --------------------------------------- Wouldn't the buffers empty in a FIFO manner? scott

3 2

TeamNANOG youtube video seeding
by james machado 11 May '16

11 May '16

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

2 1

third party single pole administrator regimes
by Fletcher Kittredge 10 May '16

10 May '16

This is outside plant related. Ignore if all you do is configure routers (not that there is anything wrong with that.) I would be interested in any network provider's experiences with third party single pole administrator regulatory regimes, such as Connecticut's. Please respond privately and I will summarize if there is any interest. thanks -- Fletcher Kittredge GWI www.gwi.net

1 0

Re: NIST NTP servers
by Valdis.Kletnieks＠vt.edu 10 May '16

10 May '16

On Tue, 10 May 2016 08:07:15 -0700, Brandon Vincent said: > On May 10, 2016 7:59 AM, "Stephane Bortzmeyer" <bortzmeyer(a)nic.fr> 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 referring to selective availability which degraded the > positional accuracy for civilians. I seem to recall that the positional accuracy is degraded to "on the order of 200 meters" when selective availability is enabled (and yes, they *can* do it by geographic area by careful turning on/off on each orbit of each satellite - devices are told the signal is degraded and can downvote that signal. So unless you're in the war zone, you'll just notice your device reporting a lock on 2-3 fewer signals). The upshot is that Grace Hopper told us about electricity moving a foot per nanosecond - which means that the time-domain jitter introduced is all of 600 nanoseconds or so. In other words, anybody using it to feed an NTP server will hardly notice on the millisecond level. If you're trying to use NTP to get microsecond stability, you'll notice - but you have enough *other* things to do correctly to do this that it shouldn't be an actual issue...

1 0