RE: B5-Lite

[Eric C. Miller]

B5c is the only product that I've had much success with from Mimosa.

The B5Lite is a cheap plastic shell and, and it performs like it too.

If you have UBNT gear now, Mimosa is a good next step, but I'd strongly 
recommend that you stear away from the lite and go with the B5c. We use them 
with rocket dishes. You just need the RP-SMA to N cables.


Eric Miller, CCNP
Network Engineering Consultant



-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jared Mauch
Sent: Friday, May 13, 2016 7:06 PM
To: North American Network Operators' Group 
Subject: B5-Lite

Anyone deployed this radio in production in the US?  I’m curious to hear from 
people who are using it, looking at replacing some UBNT hardware with it on 
some PTP links, going from the M-series class devices to something more modern.

Thanks,

- Jared

Re: B5-Lite

[Faisal Imtiaz]

Best place to ask this question would be the WISPA list (public one or Member's 
list).
Plus you can ask ask this question on Facebook, WISPA Pictures or Mimosa Group 
! Lots of good info there.

Like all fixed wireless, in unlicensed freq...there are if's and's or but's 
Depending on your particular link, and what problem you are trying to solve, 
the Mimosa's would be a logical and good upgrade path from Ubiquiti M5 
radios

Weather you use B5-lite or B5's would depend on a few factors.


:)


Regards

Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net

- Original Message -
> From: "Jared Mauch" 
> To: "nanog list" 
> Sent: Friday, May 13, 2016 7:05:55 PM
> Subject: B5-Lite

> Anyone deployed this radio in production in the US?  I’m curious to hear from
> people who are using it, looking at replacing some UBNT hardware with it on
> some PTP links, going from the M-series class devices to something more 
> modern.
> 
> Thanks,
> 
> - Jared

B5-Lite

[Jared Mauch]

Anyone deployed this radio in production in the US?  I’m curious to hear from 
people who are using it, looking at replacing some UBNT hardware with it on 
some PTP links, going from the M-series class devices to something more modern.

Thanks,

- Jared

Re: NIST NTP servers

[Mel Beckman]

"Either method needs the specs" should read "Either method meets the specs."

 -mel beckman

> On May 13, 2016, at 1:39 PM, Mel Beckman  wrote:
> 
> Lamar,
> 
> Because you need microsecond-level time accuracy (which is beyond NTP's 
> capabilities) you'll requires an adjunct protocol, such as PPS, to get that.  
> For continued NTP delivery despite periodic GPS signal loss, then you need an 
> OCXO internal clock. 
> 
> But anyone satisfied with NTP's millisecond time accuracy at worst needs a $1 
> temperature-compensated internal clock. Either method needs the specs for a 
> Stratum 1 time source on a local network. 
> 
> As you point out, the hobbyist SBCs can't deliver even basic clock accuracy.  
> 
> But another key consideration beyond accuracy is the reliability of a 
> server's GPS constellation view. If you can lose GPS sync for an hour or more 
> (not uncommon in terrain-locked locations), the NTP time will go free-running 
> and could drift quite a bit. You need an OCXO to minimize that drift to 
> acceptable levels. 
> 
> But I see that the price premium for an OCXO clock is only $100 to $200 on 
> low-cost (I.e., ~$500) commercial NTP servers. So buyers need only make a 
> minor cost adjustment to have very good, and inexpensive, COTS NTP 
> performance and reliability. 
> 
> -mel beckman
> 
>>> On May 13, 2016, at 9:30 AM, Lamar Owen  wrote:
>>> 
>>> On 05/13/2016 10:38 AM, Mel Beckman wrote:
>>> You make it sound like TXCOs are rare, but they're actually quite common in 
>>> most single board computers. True, you're probably not gonna find them in 
>>> the $35 cellular-based SBCs, but since these temperature compensated 
>>> oscillators cost less than a dollar each in quantity, they're quite common 
>>> in most industrial species for well under $100.
>> 
>> Correct, they're not rare in the industrial line (for that matter you can 
>> get TCXO-equipped RTL-SDR dongles, but that's not NTP-related).  Something 
>> like a Transko TFC or TX-P or similar is enough for reasonable timing for 
>> basic purposes, and they're not expensive.  They're also not a stock item on 
>> the consumer-level SBC's either.  I looked at one of our half-dozen ODroid 
>> C2's, and the main processor clock, X3, is under the heatsink, so I can't 
>> see what part is being used.  X1 and X2 are outside, and it doesn't appear 
>> that they are TCXO modules, although I didn't use a magnifier to check the 
>> part number and might have made an error.
>> 
>> The Nicegear DS3231 RTC has a TCXO, and might be the best low-cost choice at 
>> $12 (need to have an RPi, ODroid, or similar on which to mount it).  It's 
>> not that TCXO's are rare or expensive, it's that they're not often 
>> considered to be important to accuracy in many circles.
>> 
>>> An Ovenized XCO is absolutely not required for IT-grade NTP servers.
>> 
>> No, but it is for my purposes here.  But, as I said in my post:
>> 
>> 
>>> You really have to have at least a temperature compensated quartz crystal 
>>> oscillator (TCXO) to even begin to think about an NTP server, for anything 
>>> but the most rudimentary of timing.  Ovenized quartz oscillators (OCXO) and 
>>> rubidium standards are the next step up, ...
>> 
>> I was just saying that OCXO and Rb are just the next step up if you would 
>> like more stability, that's all.  For 'within a second' on a GPS-disciplined 
>> clock (even without the 1PPS signal) you wouldn't necessarily need TXCO.  
>> But that's what I meant by 'anything but the most rudimentary of timing.'  
>> Rudimentary is down to the millisecond in my environment.  PTP takes you to 
>> the next level, and beyond that you don't use network timing but put a 
>> dedicated time distribution network running IRIG-B or similar.  But that is 
>> beyond the scope of a typical IT NTP server's needs.
>> 

Re: Cost-effectivenesss of highly-accurate clocks for NTP

[Baldur Norddahl]

Den 13. maj 2016 21.40 skrev "Eric S. Raymond" :

> Traditionally dedicated time-source hardware like rubidium-oscillator
> GPSDOs is sold on accuracy, but for WAN time service their real draw
> is long holdover time with lower frequency drift that you get from the
> cheap, non-temperature-compensated quartz crystals in your PC.
>
> There is room for debate about how much holdover you should pay for,
> but you'll at least be thinking more clearly about the problem if
> you recognize that you *should not* buy expensive hardware for
> accuracy.  For WAN time service, in that price range, you're wither
> buying holdover and knowing you're doing so or wasting your money.

Ok how many hours or days of holdover can you expect from quartz,
temperature compensated quartz or Rubidium? Should we calculate holdover as
time until drift is more than 1 millisecond, 10 ms or more for NTP
applications?

I am thinking that many available datacenter locations will have poor GPS
signal so we can expect signal loss to be common. Some weather patterns
might even cause extended GPS signal loss.

Regards

Baldur

Re: NIST NTP servers

[Mel Beckman]

Lamar,

Because you need microsecond-level time accuracy (which is beyond NTP's 
capabilities) you'll requires an adjunct protocol, such as PPS, to get that.  
For continued NTP delivery despite periodic GPS signal loss, then you need an 
OCXO internal clock. 

But anyone satisfied with NTP's millisecond time accuracy at worst needs a $1 
temperature-compensated internal clock. Either method needs the specs for a 
Stratum 1 time source on a local network. 

As you point out, the hobbyist SBCs can't deliver even basic clock accuracy.  

But another key consideration beyond accuracy is the reliability of a server's 
GPS constellation view. If you can lose GPS sync for an hour or more (not 
uncommon in terrain-locked locations), the NTP time will go free-running and 
could drift quite a bit. You need an OCXO to minimize that drift to acceptable 
levels. 

But I see that the price premium for an OCXO clock is only $100 to $200 on 
low-cost (I.e., ~$500) commercial NTP servers. So buyers need only make a minor 
cost adjustment to have very good, and inexpensive, COTS NTP performance and 
reliability. 

 -mel beckman

> On May 13, 2016, at 9:30 AM, Lamar Owen  wrote:
> 
>> On 05/13/2016 10:38 AM, Mel Beckman wrote:
>> You make it sound like TXCOs are rare, but they're actually quite common in 
>> most single board computers. True, you're probably not gonna find them in 
>> the $35 cellular-based SBCs, but since these temperature compensated 
>> oscillators cost less than a dollar each in quantity, they're quite common 
>> in most industrial species for well under $100.
> 
> Correct, they're not rare in the industrial line (for that matter you can get 
> TCXO-equipped RTL-SDR dongles, but that's not NTP-related).  Something like a 
> Transko TFC or TX-P or similar is enough for reasonable timing for basic 
> purposes, and they're not expensive.  They're also not a stock item on the 
> consumer-level SBC's either.  I looked at one of our half-dozen ODroid C2's, 
> and the main processor clock, X3, is under the heatsink, so I can't see what 
> part is being used.  X1 and X2 are outside, and it doesn't appear that they 
> are TCXO modules, although I didn't use a magnifier to check the part number 
> and might have made an error.
> 
> The Nicegear DS3231 RTC has a TCXO, and might be the best low-cost choice at 
> $12 (need to have an RPi, ODroid, or similar on which to mount it).  It's not 
> that TCXO's are rare or expensive, it's that they're not often considered to 
> be important to accuracy in many circles.
> 
>> An Ovenized XCO is absolutely not required for IT-grade NTP servers.
> 
> No, but it is for my purposes here.  But, as I said in my post:
> 
> 
>> You really have to have at least a temperature compensated quartz crystal 
>> oscillator (TCXO) to even begin to think about an NTP server, for anything 
>> but the most rudimentary of timing.  Ovenized quartz oscillators (OCXO) and 
>> rubidium standards are the next step up, ...
> 
> I was just saying that OCXO and Rb are just the next step up if you would 
> like more stability, that's all.  For 'within a second' on a GPS-disciplined 
> clock (even without the 1PPS signal) you wouldn't necessarily need TXCO.  But 
> that's what I meant by 'anything but the most rudimentary of timing.'  
> Rudimentary is down to the millisecond in my environment.  PTP takes you to 
> the next level, and beyond that you don't use network timing but put a 
> dedicated time distribution network running IRIG-B or similar.  But that is 
> beyond the scope of a typical IT NTP server's needs.
> 

Cost-effectivenesss of highly-accurate clocks for NTP

[Eric S. Raymond]

Mel Beckman :
>Finally, do you want to weigh in on the necessity for highly accurate local RT
>clocks in NTP servers? That seems to be the big bugaboo in cost limiting right
>now.

Yes, this is a topic on which I have some well-developed judgments
due to having collected (and, where practical, tested) a pretty
comprehensive set of figures on components of the NTP error budget.
I've even invented some hardware that simplifies the problem.

The background to my findings is laid out in my "Introduction to Time
Service" HOWTO:

http://www.catb.org/gpsd/time-service-intro.html

I find that an effective way to learn my way into a new application domain
is to first do knowledge capture on the assumptions its experts are
using and then document those. "Introduction to Time Service" was
written to do that and as a white paper for my project management.
Criticism and corrections are, of course, welcome.

In order to discuss the value of accurate clocks intelligently, we need
to split apart two issues: accuracy and availability. Of course we
want the most accurate time our networks can deliver; we also want to
hedge against sporadic or systemic failure of single time sources.

The most important simplification of either issue is that clock
accuracy worth paying for is bounded both by user expectations and
the noise floor defined by our network jitter.

According to RFC 5095 expected accuracy of NTP time is "several tens
of milliseconds." User expectations seem to evolved to on the close
order of 10ms.  I think it's not by coincidence this is pretty close
to the jitter in ping times I see when I bounce ICMP off a
well-provisioned site like (say) google.com through my Verizon FIOS
connection.

It's good rule-of-thumb engineering that if you want to be
metrologically accurate you should pay for precision an order of
magnitude below your feature size *and not more than that*.  Thus,
with a feature size of 10ms the economic sweet spot is a clock with
accuracy about 1ms.

One reason discussions of how to budget for WAN timeservice clocks has
tended to become heated in the past is that nothing inexpensive hit
this sweet spot.  The world was largely divided between cheap time
sources with too much jitter (e.g. GPS in-band data with a wander of
100ms or worse) and expensive high-precision clocks designed for PTP
over Ethernet that deliver three or more orders of magnitude than WAN
time service can actually use.

However...also use the 1PPS signal your GPS engine ships (top of UTC
second accurate to about 50ns) and the picture changes
completely. With that over RS232 your delivered accuracy rises to
single-digit numbers of microseconds, which is two orders of magnitude
below what you need for your 1ms goal.

Now we have a historical problem, though: RS232 and the handshake
lines you could use to signal 1PPS are dying, being replaced by USB.
which doesn't normally bring 1PPS out to where the timeserver OS
can see it.

In 2012, nearly three years before being recruited for NTPsec, I
solved this problem as part of my work on GPSD.  The key to this
solution is an obscure feature of USB, and a one-wire
patch to the bog-standard design for generic USB that exploits
it.  Technical details on request, but what it comes down to is
that with this one weird trick(!) you can mass-produce primary time
sources with a jitter bounded by the USB polling interval for
about $20 a pop.

The USB 1 polling interval is 1ms. Bingo.  We're done.  If we're only
weighting accuracy and not availability, a USB GPS is as much clock as
you need for WAN timeservice *provided it exposes 1PPS*.  These
devices exist, because I designed them and found a shop in Shenzhen
to build them. They're called the Navisys GR-601W, GR-701W, and
GR-801W.

(A viable, only skightly more expensive alternative is to mate a GPS
daughterboard to a hackerboard like the Raspberry Pi and run NTP
service on that.  I'll have much, much more to say about that in a
future post.)

Of course, now we have to talk about availability.  GPS sometimes
loses lock.  There are sporadic and systemic availability risks due to
jamming and system failures like the 2012 hiccup, and extreme
scenarios like a giant meteorite hitting GPSS ground control in
Colorado.

What you should be willing to pay for a hedge against this is
proportional to your 95% confidence estimate of the maximum
outage interval. At the low end, this is simple; put your
antenna on a mast that guarantees unobstructed skyview.  At the high
end it's effectively impossible, in that anything that takes down GNSS
and Galileo permanently (giant meteor impact, war in space, collapse
of the U.S. and Europe) is likely to be in the you-have-much-bigger-
problems than-inaccurate-time department.

Traditionally dedicated time-source hardware like rubidium-oscillator
GPSDOs is sold on accuracy, but for WAN time service their real draw
is long holdover time with lower frequency drift that you get from the
cheap, 

[NANOG-announce] NOTR - Thank you Denver, CO and Announcing NYC

[Valerie Wittkop]

We extend a very big Thank You to Denver, CO for such a successful NOTR event 
on Tuesday.  Great presentations and a large crowd made the day great for 
everyone!
We are very excited to be holding the next NOTR event in New York City 
NOTR event in N 
ew York City on July 21, 2016, in 
partnership with NYNOG , and we invite you to join us!
Are you interested in Internet networking/peering? Do you work at a colocation, 
hosting or data center facility? Are you a provider of hardware/software 
solutions for the Internet industry?  If so, the NANOG On The Road NYC event is 
perfect for you!

Date:  July 21, 2016
Time:  Registration Desk opens at 8:30am and Program is from 9:00 AM - 5:00 PM
Location:  New York Marriott Marquis 
N 
ew York Marriott Marquis - 1535 
Broadway, New York, NY 10036

The FREE to attend event is open for registration.  Register Now! 

 

Agenda Topics  are posted, which 
include:
- Life After IPv4
- Traceroute Tutorial
- IPv6 Tutorial
- BGP Tutorial
If you are, or will be, in the New York City area, we invite you to attend.  
And don’t forget to attend NYNOG’s Meetup #1 on May 25, 2016.  Click here 
 for more information about their event.

Learn more about On The Road events here 
.  Feel free to contact us at 
nanog-supp...@nanog.org  if you have any 
questions.

Regards,
Valerie

Valerie Wittkop
NANOG Program Director
Tel: +1 866 902 1336, ext 103

___
NANOG-announce mailing list
nanog-annou...@mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG,
SAFNOG, PaNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 14 May, 2016

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  593720
Prefixes after maximum aggregation (per Origin AS):  217775
Deaggregation factor:  2.73
Unique aggregates announced (without unneeded subnets):  290742
Total ASes present in the Internet Routing Table: 53727
Prefixes per ASN: 11.05
Origin-only ASes present in the Internet Routing Table:   36600
Origin ASes announcing only one prefix:   15688
Transit ASes present in the Internet Routing Table:6437
Transit-only ASes present in the Internet Routing Table:171
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  39
Max AS path prepend of ASN ( 40285)  33
Prefixes from unregistered ASNs in the Routing Table:  1414
Unregistered ASNs in the Routing Table: 444
Number of 32-bit ASNs allocated by the RIRs:  13845
Number of 32-bit ASNs visible in the Routing Table:   10690
Prefixes from 32-bit ASNs in the Routing Table:   42050
Number of bogon 32-bit ASNs visible in the Routing Table: 3
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:386
Number of addresses announced to Internet:   2811463492
Equivalent to 167 /8s, 147 /16s and 135 /24s
Percentage of available address space announced:   75.9
Percentage of allocated address space announced:   75.9
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.1
Total number of prefixes smaller than registry allocations:  193775

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   151912
Total APNIC prefixes after maximum aggregation:   42356
APNIC Deaggregation factor:3.59
Prefixes being announced from the APNIC address blocks:  162829
Unique aggregates announced from the APNIC address blocks:66401
APNIC Region origin ASes present in the Internet Routing Table:5177
APNIC Prefixes per ASN:   31.45
APNIC Region origin ASes announcing only one prefix:   1181
APNIC Region transit ASes present in the Internet Routing Table:913
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 39
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2070
Number of APNIC addresses announced to Internet:  755234628
Equivalent to 45 /8s, 3 /16s and 247 /24s
Percentage of available APNIC address space announced: 88.3

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 131072-135580
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:181169
Total ARIN prefixes after maximum aggregation:89627
ARIN Deaggregation factor: 2.02
Prefixes being announced from the ARIN address blocks:   186526
Unique aggregates announced from the ARIN address blocks: 88714
ARIN Region origin ASes present in the Internet Routing Table:16363

Re: A briefing on NTPsec

[Eric S. Raymond]

Mel Beckman :
> Does your project have anything like a portable regression test
> suite that the rest of us could use for NTP product evaluations?

We do not, yet.  Testing NTP at above the level of unit tests for individual
functions is *quite* difficult - I say that as the person who successfully
implemented a very rigorous regression-test suite in GPSD.  The NTP version
of this problem is, unfortunately, much less tractable. 

We have some ideas and a partial implementation, but this is the
technical area in which we have had the least success so far.

We will persevere.  We're going to need good end-to-end testing to
maintain provable functional stability through some of the large
changes I have in mind.  I cannot, however, promise that our
test framework will be applicable to other implementations.

>And what I be correct in guessing that all of your work is foss?

Yes.  NTP and 2-clause BSD licenses.

> When you say that nothing has been done to add security mechanisms
> to NTP, are you saying that all the work so far has been code
> hardening exclusively?

Yes.  There remains a considerable amount of this to be done.  We have
our eyes on several risky and only marginally useful features that
should probably be excised.  The recently-acquired ability of Windows
to run many Linux binaries probably means all the Windows port shims
can be thrown out.  And so forth.

The official motto of our project, front and center on www.ntpsec.org,
is the Saint-Exupery quote: "Perfection is achieved, not when there is
nothing more to add, but when there is nothing left to take away."

I must say that the effectiveness of ruthlessly cutting away bloat as
a security-hardening strategy has actually exceeded our initial
expectations. We were hoping for "successful" and seem to have
achieved "wildly successful" - I think dodging 8 of 11 CVEs in the
last batch counts as that.

> Finally, do you want to weigh in on the necessity for highly
> accurate local RT clocks in NTP servers? That seems to be the big
> bugaboo in cost limiting right now.

I'll reply to this starting a separate thread.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: NIST NTP servers

[Lamar Owen]

On 05/13/2016 10:38 AM, Mel Beckman wrote:

You make it sound like TXCOs are rare, but they're actually quite common in 
most single board computers. True, you're probably not gonna find them in the 
$35 cellular-based SBCs, but since these temperature compensated oscillators 
cost less than a dollar each in quantity, they're quite common in most 
industrial species for well under $100.


Correct, they're not rare in the industrial line (for that matter you 
can get TCXO-equipped RTL-SDR dongles, but that's not NTP-related).  
Something like a Transko TFC or TX-P or similar is enough for reasonable 
timing for basic purposes, and they're not expensive.  They're also not 
a stock item on the consumer-level SBC's either.  I looked at one of our 
half-dozen ODroid C2's, and the main processor clock, X3, is under the 
heatsink, so I can't see what part is being used.  X1 and X2 are 
outside, and it doesn't appear that they are TCXO modules, although I 
didn't use a magnifier to check the part number and might have made an 
error.


The Nicegear DS3231 RTC has a TCXO, and might be the best low-cost 
choice at $12 (need to have an RPi, ODroid, or similar on which to mount 
it).  It's not that TCXO's are rare or expensive, it's that they're not 
often considered to be important to accuracy in many circles.



An Ovenized XCO is absolutely not required for IT-grade NTP servers.


No, but it is for my purposes here.  But, as I said in my post:



You really have to have at least a temperature compensated quartz crystal 
oscillator (TCXO) to even begin to think about an NTP server, for anything but 
the most rudimentary of timing.  Ovenized quartz oscillators (OCXO) and 
rubidium standards are the next step up, ...


I was just saying that OCXO and Rb are just the next step up if you 
would like more stability, that's all.  For 'within a second' on a 
GPS-disciplined clock (even without the 1PPS signal) you wouldn't 
necessarily need TXCO.  But that's what I meant by 'anything but the 
most rudimentary of timing.'  Rudimentary is down to the millisecond in 
my environment.  PTP takes you to the next level, and beyond that you 
don't use network timing but put a dedicated time distribution network 
running IRIG-B or similar.  But that is beyond the scope of a typical IT 
NTP server's needs.

Re: A briefing on NTPsec

[Mel Beckman]

Eric,

Thanks for this really helpful insider look into NTPsec. Does your project have 
anything like a portable regression test suite that the rest of us could use 
for NTP product evaluations? And what I be correct in guessing that all of your 
work is foss?

When you say that nothing has been done to add security mechanisms to NTP, are 
you saying that all the work so far has been code hardening exclusively?

Finally, do you want to weigh in on the necessity for highly accurate local RT 
clocks in NTP servers? That seems to be the big bugaboo in cost limiting right 
now.

 -mel beckman

> On May 13, 2016, at 6:40 AM, Eric S. Raymond  wrote:
> 
> 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 

Re: NIST NTP servers

[Sharon Goldberg]

Since we are on the subject, I would strongly recommend that you don't run
NTP on Linux 2.2.13, since its especially vulnerable to our IPv4
fragmentation attack.  "SunOS" also seems vulnerable, but I am not 100%
sure what systems that say they are "SunOS" actually are.  These OS will
fragment packets to 64 bytes, and are vulnerable to frag attacks using
"tiny" fragments.

See Section VI of our paper:
https://eprint.iacr.org/2015/1020.pdf

You can also test your OS here (scroll to the bottom).
http://www.cs.bu.edu/~goldbe/NTPattack.html


On Fri, May 13, 2016 at 10:46 AM, Chuck Anderson  wrote:

> On Fri, May 13, 2016 at 10:12:49AM -0400, Lamar Owen wrote:
> > On 05/11/2016 09:46 PM, Josh Reynolds wrote:
> > >maybe try [setting up an NTP server] with an odroid?
> > >
> > ...
> >
> > I have several ODroid C2's, and the first thing to note about them
> > is that there is no RTC at all.  Also, the oscillator is just a
> > garden-variety non-temperature-compensated quartz crystal, and not
> > necessarily a very precise one, either (precise quartz oscillators
> > can cost more than the whole ODroid board costs).  The XU4 and other
> > ODroid devices make nice single-board ARM computers, but have pretty
> > ratty oscillator precision.
> >
> > You really have to have at least a temperature compensated quartz
> > crystal oscillator (TCXO) to even begin to think about an NTP
> > server, for anything but the most rudimentary of timing.  Ovenized
> > quartz oscillators (OCXO) and rubidium standards are the next step
> > up, and most reasonably good GPS-disciplined clocks have at least an
> > ovenized quartz oscillator module (the Agilent Z3816 and kin are of
> > this type).
>
> Does anyone know of any COTS NTP servers that are based on non-ancient
> Linux kernel versions?  In 2012 we bought new GPS/CDMA NTP servers
> with OCXO that are based on Linux 2.4, but they are fiddly as you can
> imagine with such an ancient software stack.
>
> What would people recommend for NTP server hardware/software?
>
>


-- 
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe

Re: NIST NTP servers

[Chuck Anderson]

On Fri, May 13, 2016 at 10:12:49AM -0400, Lamar Owen wrote:
> On 05/11/2016 09:46 PM, Josh Reynolds wrote:
> >maybe try [setting up an NTP server] with an odroid?
> >
> ...
> 
> I have several ODroid C2's, and the first thing to note about them
> is that there is no RTC at all.  Also, the oscillator is just a
> garden-variety non-temperature-compensated quartz crystal, and not
> necessarily a very precise one, either (precise quartz oscillators
> can cost more than the whole ODroid board costs).  The XU4 and other
> ODroid devices make nice single-board ARM computers, but have pretty
> ratty oscillator precision.
> 
> You really have to have at least a temperature compensated quartz
> crystal oscillator (TCXO) to even begin to think about an NTP
> server, for anything but the most rudimentary of timing.  Ovenized
> quartz oscillators (OCXO) and rubidium standards are the next step
> up, and most reasonably good GPS-disciplined clocks have at least an
> ovenized quartz oscillator module (the Agilent Z3816 and kin are of
> this type).

Does anyone know of any COTS NTP servers that are based on non-ancient
Linux kernel versions?  In 2012 we bought new GPS/CDMA NTP servers
with OCXO that are based on Linux 2.4, but they are fiddly as you can
imagine with such an ancient software stack.

What would people recommend for NTP server hardware/software?

Re: NIST NTP servers

[Laszlo Hanyecz]

On 2016-05-13 14:12, Lamar Owen wrote:

On 05/11/2016 09:46 PM, Josh Reynolds wrote:

maybe try [setting up an NTP server] with an odroid?


...


You really have to have at least a temperature compensated quartz 
crystal oscillator (TCXO) to even begin to think about an NTP server, 
for anything but the most rudimentary of timing.




There are WWVB clocks that try to sync nightly.  Many of them don't even 
have a second indicator, but they give reliable time to the minute.  NTP 
is a lot better than this as it continuously disciplines the clock 
instead of just lining it up once a day, but we're talking about doing 
this over the internet where we measure latency in milliseconds.  If 
you're working down at the picosecond level you will probably not be 
using NTP to distribute your clock signal.  Running an NTP client 
against pool servers is a lot better than not running it at all, but 
running it against a fancy local server with a GPSDO hooked up to it is 
only marginally better than the pool servers.


It all depends on what you want to do but a cheap ARM or Intel Atom 
computer works well for an NTP server (remember millisecond level 
accuracy).  If you can afford to build a secure bunker with armed guards 
and redundant everything for your time server that's good, but a few RPi 
style computers with GPS hats are almost as good, and you can buy a lot 
of them for very little money..


-Laszlo

Re: NIST NTP servers

[Mel Beckman]

Lamar,

You make it sound like TXCOs are rare, but they're actually quite common in 
most single board computers. True, you're probably not gonna find them in the 
$35 cellular-based SBCs, but since these temperature compensated oscillators 
cost less than a dollar each in quantity, they're quite common in most 
industrial species for well under $100.

An Ovenized XCO is absolutely not required for IT-grade NTP servers. If you 
need sub-microsecond  low-jitter leading-edge clocks, for BITS timing of SONET 
or radio networks for example, then an OXCO is helpful. But NTP itself is not 
that accurate. NTP can usually maintain time to only within tens of 
milliseconds over the public Internet, and can only achieve better than one 
millisecond accuracy in local area networks under ideal conditions. 

 -mel 

> On May 13, 2016, at 7:13 AM, Lamar Owen  wrote:
> 
>> On 05/11/2016 09:46 PM, Josh Reynolds wrote:
>> maybe try [setting up an NTP server] with an odroid?
>> 
> ...
> 
> I have several ODroid C2's, and the first thing to note about them is that 
> there is no RTC at all.  Also, the oscillator is just a garden-variety 
> non-temperature-compensated quartz crystal, and not necessarily a very 
> precise one, either (precise quartz oscillators can cost more than the whole 
> ODroid board costs).  The XU4 and other ODroid devices make nice single-board 
> ARM computers, but have pretty ratty oscillator precision.
> 
> You really have to have at least a temperature compensated quartz crystal 
> oscillator (TCXO) to even begin to think about an NTP server, for anything 
> but the most rudimentary of timing.  Ovenized quartz oscillators (OCXO) and 
> rubidium standards are the next step up, and most reasonably good 
> GPS-disciplined clocks have at least an ovenized quartz oscillator module 
> (the Agilent Z3816 and kin are of this type).
> 

Re: NIST NTP servers

[Lamar Owen]

On 05/11/2016 09:46 PM, Josh Reynolds wrote:

maybe try [setting up an NTP server] with an odroid?


...

I have several ODroid C2's, and the first thing to note about them is 
that there is no RTC at all.  Also, the oscillator is just a 
garden-variety non-temperature-compensated quartz crystal, and not 
necessarily a very precise one, either (precise quartz oscillators can 
cost more than the whole ODroid board costs).  The XU4 and other ODroid 
devices make nice single-board ARM computers, but have pretty ratty 
oscillator precision.


You really have to have at least a temperature compensated quartz 
crystal oscillator (TCXO) to even begin to think about an NTP server, 
for anything but the most rudimentary of timing.  Ovenized quartz 
oscillators (OCXO) and rubidium standards are the next step up, and most 
reasonably good GPS-disciplined clocks have at least an ovenized quartz 
oscillator module (the Agilent Z3816 and kin are of this type).

Re: Internet DATA Center IP base utilization/Bandwidth Billing

[Hari Haran]

Hi

Software name ntop

On Thursday 12 May 2016, sathish kumar Ippani <
sathish.kumar.ipp...@gmail.com> wrote:

> 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
>


-- 
*Thanks & Regards*




*Hari Haran *
*IT Manager*
*Seven Star Dot Com Pvt Ltd*Mhada Bldg No.8, Flat No.001, Blue Bell Co-Op
Hsg Soc,
Near Tarapore Towers, New Link Road,Oshiwara,
Andheri (W), Mumbai - 400 053

Tel: +91-22 2632 1214/15 , 2636 4003/7

Cell No.+91-9819046500

E-Mail : ha...@7starnetwork.com / ha...@balajiinternet.com
Website : www.7starnetwork.com / www.balajiinternet.com

A briefing on NTPsec

[Eric S. Raymond]

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.
--
http://www.catb.org/~esr/;>Eric S. Raymond

A briefing on NTPsec

[Eric S. Raymond]

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.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

This would be the best of all possible worlds, if there were
no religion in it.  -- John Adams, in a letter to Thomas Jefferson.

Re: Internet DATA Center IP base utilization/Bandwidth Billing

[Dan White]

We use Calix Flow Analyze.

On 05/12/16 18:51 +0530, sathish kumar Ippani wrote:

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


--
Dan White
BTC Broadband
Network Admin Lead
Ph  918.366.0248 (direct)   main: (918)366-8000
Fax 918.366.6610email: dwh...@olp.net
http://www.btcbroadband.com

Re: NIST NTP servers

[Tony Finch]

Jean-Francois Mezei  wrote:
>
> Today, if someone were to jam the GPS signal in an areas in USA, you'd
> likely hear about large number of car accidents in the news before
> noticing your systems canMt get time from the GPS-NTP and went to a
> backup ip address (nist etc).

The USA and the UK governments regularly perform GPS jamming tests, but
they do so in remote areas. See
http://www.navcen.uscg.gov/?pageName=gpsServiceInterruptions
http://stakeholders.ofcom.org.uk/spectrum/gps-jamming-exercises/
(Dunno if other governments have similar exercises.)

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Lundy, Fastnet, Irish Sea, South Shannon: Northerly or northeasterly 4 or 5,
occasionally 6 except in south Shannon. Slight or moderate. Mainly fair. Good,
occasionally poor at first in south Lundy.