Looking for an Amazon Cloudfront contact

2022-04-06 Thread Eric Kuhnke
It looks like I may have a range of recently put into use residential
symmetric gigabit last mile IP space that's being filtered/blocked at the
application level.

Please contact me off-list.


Re: RFC 9225 - Software Defects Considered Harmful

2022-04-01 Thread Eric Kuhnke
If there's a bug in an ISP's implementation of RFC2549 carrier 'equipment',
is that considered a software bug, hardware, or subject of ornithological
research?



On Fri, 1 Apr 2022 at 10:40, Job Snijders via NANOG  wrote:

> Hi all,
>
> It's super official now: no more software bugs in networking gear.
> Sorry it took so long to document what the best current practise is!
>
> Kind regards,
>
> Job / Chris / Remco
>
> - Forwarded message from rfc-edi...@rfc-editor.org -
> Date: Fri,  1 Apr 2022 10:17:37 -0700 (PDT)
> From: rfc-edi...@rfc-editor.org
> To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
> Cc: drafts-update-...@iana.org, rfc-edi...@rfc-editor.org
> Subject: RFC 9225 on Software Defects Considered Harmful
>
> A new Request for Comments is now available in online RFC libraries.
>
> RFC 9225
>
> Title:  Software Defects Considered Harmful
> Author: J. Snijders,
> C. Morrow,
> R. van Mook
> Status: Informational
> Stream: Independent
> Date:   1 April 2022
> Mailbox:j...@fastly.com,
> morr...@ops-netman.net,
> re...@asteroidhq.com
> Pages:  6
> Updates/Obsoletes/SeeAlso:   None
>
> I-D Tag:draft-dont-write-bugs-00.txt
>
> URL:https://www.rfc-editor.org/info/rfc9225
> DOI:10.17487/RFC9225
>
> This document discourages the practice of introducing software
> defects in general and in network protocol implementations
> specifically.  Software defects are one of the largest cost drivers
> for the networking industry.  This document is intended to clarify
> the best current practice in this regard.
>
>
> INFORMATIONAL: This memo provides information for the Internet community.
> It does not specify an Internet standard of any kind. Distribution of
> this memo is unlimited.
>
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>   https://www.ietf.org/mailman/listinfo/ietf-announce
>   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
> The RFC Editor Team
> Association Management Solutions, LLC
>
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>
> - End forwarded message -
>


Re: Cogent ...

2022-04-01 Thread Eric Kuhnke
I have a morbid curiosity what their CRM system looks like, and how many
entries are in it and what their internal notes/work flow looks like.

This opinion is formed from the external perspective of being a person who
is a very cold sales lead and yet continues to be occasionally called by a
new sales person every 4 to 6 months.


On Thu, 31 Mar 2022 at 08:39, Laura Smith via NANOG  wrote:

> Hmmm
>
> Spring has sprung and the waft of drivel from a new season Cogent
> salesdroid filled my telephone earpiece today.
>
> I've never liked the Cogent way of business and my understanding of their
> IP transit is that it falls into the "cheap for a reason" category.
>
> However, perhaps someone would care to elaborate (either on or off-list)
> what the deal is with the requirement to sign NDAs with Cogent before
> they'll discuss things like why they still charge for BGP, or indeed any
> other technical or pricing matters. Seems weird ?!?
>
> Laura
>


Re: ISP data collection from home routers

2022-03-25 Thread Eric Kuhnke
yes, because otherwise the contention (it's a shared access media, after
all) and RF channel bonding/allocation wouldn't work. Configuration depends
on what the exact CMTS configuration is on your last mile coax segment.

however it's also possible to have the cable MSO push an update to
cablemodems which locks out a read-only diagnostics/info page that would
otherwise be available.



On Fri, 25 Mar 2022 at 13:47, Michael Thomas  wrote:

>
> On 3/24/22 12:53 PM, Tom Beecher wrote:
> > You don't even have to use their equipment. My provider at home is
> > Charter / Spectrum. I own my own cable modem  / router ,they have no
> > equipment in my home. Their privacy policy is pretty standard.
> > Essentially :
> > - Anything they can see that I transmit they will collect.
> > - Anything they can see when I use their apps , even if I'm not on
> > their network, they will collect.
> > - They will use that information for their technical and business
> > reasons, whatever they want.
> > - I am very limited in what I can request that they don't collect or use.
> >
> > None of this is new in the US. I think more people care about
> > this than we think, but people don't really have an option to vote
> > with their wallets.
>
> Even if you own your modem, the DOCSIS specs require that it be
> completely controlled by the MSO, right?
>
> Mike
>
>
>


Re: WP: Russian military behind hack of satellite communication devices

2022-03-25 Thread Eric Kuhnke
Point to multipoint / TDMA contended access VSAT hub and CPE networks are
well known for not having much security. In many setups the remote CPE
modems, which are built from a fairly cheap BOM of hardware, implicitly
trust the hub linecard. Have seen this with 3 different vendors' platforms.

I'd be willing to bet that this was either a malicious firmware push that
was applied to the CPEs without proper authentication methods being in
place, such as CPEs being able to verify a crypto key signed firmware
signature, or a configuration file pushed to the CPEs that knocked them off
the network with incorrect RF/channel/modulation/timing parameters.

Note that the Viasat KA-SAT terminals are at the very lower end of the
market for contended access (64:1 or more) consumer/small business grade
geostationary VSAT. Which is why it sort of makes sense that a lot of them
were used for low data rate SCADA for wind farms and such.




On Thu, 24 Mar 2022 at 20:48, Sean Donelan  wrote:

>
> Not yet official, but the U.S. intelligence community seems to continue
> its rapid release of intelligence.  I think everyone was expecting it,
> especially since Viasat executives declined to say it earlier this week at
> the SATCOM 2022 conference.
>
>
>
>
> https://www.washingtonpost.com/national-security/2022/03/24/russian-military-behind-hack-satellite-communication-devices-ukraine-wars-outset-us-officials-say/
> By Ellen Nakashima
> Today at 10:25 p.m. EDT
>
> U.S. intelligence analysts have concluded that Russian military spy
> hackers were behind a cyberattack on a satellite broadband service that
> disrupted Ukraine’s military communications at the start of the war last
> month, according to U.S. officials familiar with the matter.
>
> The U.S. government, however, has not announced its conclusion publicly.
>
> [...]
>
> The modems were part of Viasat’s European satellite network, KA-SAT. The
> company uses distributors in Europe to sell Internet service, which relies
> on modems, to customers. The company is shipping new modems to the
> distributors so they can get them to affected customers, the official
> said.
>


Re: "Permanent" DST

2022-03-15 Thread Eric Kuhnke
That is true but at present everything business related in BC has a clear
expectation of being in the same time zone as WA/OR/CA, and AB matches US
Mountain time.

On Tue, 15 Mar 2022 at 13:35, Paul Ebersman  wrote:

> eric> If Canada doesn't do the same thing at the same time, it'll be a
> eric> real hassle, dealing with a change from -8 to -7 crossing the
> eric> border between BC and WA, for instance. It has to be done
> eric> consistently throughout North America.
>
> You must not have ever dealt with Indiana, where it was DST or not by
> choice per county. It wasn't quite the cluster***k you'd think.
>
>


Re: "Permanent" DST

2022-03-15 Thread Eric Kuhnke
If Canada doesn't do the same thing at the same time, it'll be a real
hassle, dealing with a change from -8 to -7 crossing the border between BC
and WA, for instance. It has to be done consistently throughout North
America.

On Tue, 15 Mar 2022 at 12:35, Jay R. Ashworth  wrote:

> The bill is "permanently move all US time zones one hour earlier (-8 thru
> -5 is
> replaced permanently with -7 thru -4).
>
> They are *calling it* "permanent DST", but that's not really what's
> happening,
> in my engineering appraisal.  Or my geopolitical one, but I don't lay
> claim
> to professional opinions there.
> -- jra
>
> - Original Message -
> > From: "Mel Beckman" 
> > To: "jra" 
> > Cc: "nanog@nanog.org list" 
> > Sent: Tuesday, March 15, 2022 3:19:11 PM
> > Subject: Re: "Permanent" DST
>
> > I don’t follow why cancelling DST has the effect of moving the US fifteen
> > degrees to the east. Also, your subject line reads “permanent DST”, but
> from
> > your language the bill will be permanent standard time.
> >
> > I haven’t read the bill, but I’m hoping you can explain your position
> more
> > clearly.
> >
> > -mel via cell
> >
> >> On Mar 15, 2022, at 3:13 PM, Jay R. Ashworth  wrote:
> >>
> >> In a unanimous vote today, the US Senate approved a bill which would
> >>
> >> 1) Cancel DST permanently, and
> >> 2) Move every square inch of US territory 15 degrees to the east.
> >>
> >> My opinion of this ought to be obvious from my rhetoric.  Hopefully, it
> will
> >> fail, because it's likely to be the end of rational time worldwide, and
> even
> >> if you do log in UTC, it will still make your life difficult.
> >>
> >> I'm poleaxed; I can't even decide which grounds to scream about this
> on...
> >>
> >> Hopefully, the House or the White House will be more coherent in their
> >> decision on this engineering construct.
> >>
> >> Cheers,
> >> -- jra
> >>
> >> --
> >> Jay R. Ashworth  Baylink
> j...@baylink.com
> >> Designer The Things I Think
>  RFC 2100
> >> Ashworth & Associates   http://www.bcp38.info  2000 Land
> Rover DII
> > > St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727
> 647 1274
>
> --
> Jay R. Ashworth  Baylink
> j...@baylink.com
> Designer The Things I Think   RFC
> 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land
> Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647
> 1274
>


Re: Russia attempts mandating installation of root CA on clients for TLS MITM

2022-03-11 Thread Eric Kuhnke
Clarification, Google Chrome has its own root CA revocation/CRL program. It
does still rely on the operating system root CA trust store.

Using a typical intranet/RFC1918 IP space environment as an example, as you
might see in any $BIGCORP, if you install your own choice of root CA in the
Windows 10 root CA trust store, Chrome's TLS1.2/TLS1.3 access to internal
resources that are https only will work flawlessly without any security
warnings. Very normal configuration these days. Used for things like DLP in
banking/corporate environments or places where the gateway between internal
IP space and the public world has a firewall in place with MITM ability for
all TLS traffic.

On any windows 10 system with local admin privileges you can manually find
this by opening MMC, go to add/remove snap-ins, select the certificates
(local computer) snap-in, left side menu browse to trusted root
certificates.



On Fri, 11 Mar 2022 at 10:48, Mu  wrote:

> >Mozilla is the only browser vendor these days that maintains its own
> independent root CA storage for the browser. Chrome, Chromium, Safari,
> Edge, IE etc all use whatever root CAs are trusted by the operating system.
> If they can get Windows 10 client PCs pushed to retail with an image that
> includes their CA...
>
> Google Chrome has it's own root program, and all vendors have been reliant
> on Mozilla's setup for some time. They don't just blindly trust the OS.
>
>
> --- Original Message ---
> On Friday, March 11th, 2022 at 1:34 PM, Eric Kuhnke 
> wrote:
>
> Considering that 99% of non-technical end users of windows, macos,
> android, ios client devices *have no idea what a root CA is,* if an
> authoritarian regime can mandate the installation of a government-run root
> CA in the operating system CA trust store of all new devices sold at
> retail, as equipment is discarded/upgraded/replaced incrementally over a
> period of years, they could eventually have the capability of MITM of a
> significant portion of traffic.
>
> Presumably with Apple ending shipment of new MacOS devices to Russia and
> retail sales of new devices, this wouldn't be so much of an issue with
> MacOS. The process of re-imaging a modified MacOS install .DMG onto a
> "blank" macbook air or similar with a new root CA included would be non
> trivial, and hopefully might be impossible due to crypto signature required
> for a legit MacOS bootable install image.
>
> Mozilla is the only browser vendor these days that maintains its own
> independen root CA storage for the browser. Chrome, Chromium, Safari, Edge,
> IE etc all use whatever root CAs are trusted by the operating system. If
> they can get Windows 10 client PCs pushed to retail with an image that
> includes their CA...
>
>
>
>
>
>
> On Thu, 10 Mar 2022 at 18:27, Dario Ciccarone (dciccaro) via NANOG <
> nanog@nanog.org> wrote:
>
>> I think the point Eric was trying to make is that while, indeed, the
>> initial, stated goal might be to be able to issue certificates to replace
>> those expired or expiring, there's just a jump/skip/hop to force
>> installation of this root CA certificate in all browsers, or for Russia to
>> block downloads of Firefox/Chrome from outside the Federation, and instead
>> distribute versions which would already include this CA's certificate. And
>> then MITM the whole population without their knowledge or approval.
>>
>> GIVEN: savvy users might know how to delete the certificate, or others
>> may teach them how, and how to download other CA's certificates (if the
>> government was to ship only this certificate with the browser). Cat and
>> mouse game. The North Korean and Chinese governments have been doing these
>> kind of shenanigans for a long time - I am sure Russia could copy their
>> model. And considering the tight media control they’re already exercising,
>> I don't think it is crazy or paranoid to think Internet will be next. They
>> seem to be already going down that path.
>>
>> PS: opinions and statements, like the above, are my very own personal
>> take or opinion. Nothing I say should be interpreted to be my employer's
>> position, nor be supported by my employer.
>>
>> On 3/10/22, 7:38 PM, "NANOG on behalf of Sean Donelan"
>> 
>> wrote:
>>
>> On Thu, 10 Mar 2022, Eric Kuhnke wrote:
>> > I think we'll see a lot more of this from authoritarian regimes in the
>> > future. For anyone unfamiliar with their existing distributed DPI
>> > architecture, google "Russia SORM".
>>
>> Many nation's have a government CA.
>>
>> The United States Government has its Federal Public Key Infrastructure,
>> and Federal Bridge CA.
&g

Re: Russia attempts mandating installation of root CA on clients for TLS MITM

2022-03-11 Thread Eric Kuhnke
Considering that 99% of non-technical end users of windows, macos, android,
ios client devices *have no idea what a root CA is,* if an authoritarian
regime can mandate the installation of a government-run root CA in the
operating system CA trust store of all new devices sold at retail, as
equipment is discarded/upgraded/replaced incrementally over a period of
years, they could eventually have the capability of MITM of a significant
portion of traffic.

Presumably with Apple ending shipment of new MacOS devices to Russia and
retail sales of new devices, this wouldn't be so much of an issue with
MacOS.  The process of re-imaging a modified MacOS install .DMG onto a
"blank" macbook air or similar with a new root CA included would be non
trivial, and hopefully might be impossible due to crypto signature required
for a legit MacOS bootable install image.

Mozilla is the only browser vendor these days that maintains its own
independen root CA storage for the browser. Chrome, Chromium, Safari, Edge,
IE etc all use whatever root CAs are trusted by the operating system. If
they can get Windows 10 client PCs pushed to retail with an image that
includes their CA...






On Thu, 10 Mar 2022 at 18:27, Dario Ciccarone (dciccaro) via NANOG <
nanog@nanog.org> wrote:

> I think the point Eric was trying to make is that while, indeed, the
> initial, stated goal might be to be able to issue certificates to replace
> those expired or expiring, there's just a jump/skip/hop to force
> installation of this root CA certificate in all browsers, or for Russia to
> block downloads of Firefox/Chrome from outside the Federation, and instead
> distribute versions which would already include this CA's certificate. And
> then MITM the whole population without their knowledge or approval.
>
> GIVEN: savvy users might know how to delete the certificate, or others may
> teach them how, and how to download other CA's certificates (if the
> government was to ship only this certificate with the browser). Cat and
> mouse game. The North Korean and Chinese governments have been doing these
> kind of shenanigans for a long time - I am sure Russia could copy their
> model. And considering the tight media control they’re already exercising,
> I don't think it is crazy or paranoid to think Internet will be next. They
> seem to be already going down that path.
>
> PS: opinions and statements, like the above, are my very own personal take
> or opinion. Nothing I say should be interpreted to be my employer's
> position, nor be supported by my employer.
>
> On 3/10/22, 7:38 PM, "NANOG on behalf of Sean Donelan"
> 
> wrote:
>
> On Thu, 10 Mar 2022, Eric Kuhnke wrote:
> > I think we'll see a lot more of this from authoritarian regimes in
> the
> > future. For anyone unfamiliar with their existing distributed DPI
> > architecture, google "Russia SORM".
>
> Many nation's have a government CA.
>
> The United States Government has its Federal Public Key
> Infrastructure,
> and Federal Bridge CA.
>
> https://playbooks.idmanagement.gov/fpki/ca/
>
> If you use DOD CAC ID's or FCEB PIV cards or other federal programs,
> your
> computer needs to have the FPKI CA's.  You don't need the FPKI CA's
> for
> other purposes.
>
> Some countries CA's issue for citizen and business certificates.
>
>
> While X509 allows you to specify different CA's for different
> purposes,
> since the days of Netscape, browsers trust hundreds of root or bridged
> CA
> in its trust repository for anything.
>
> Neither commercial or government CA's are inherently more (or less)
> trustworthy.  There have been trouble with CA's of all types.
>
> A X509 certificate is a big integer number, in a fancy wrapper.  Its
> not a
> magical object.
>
>


Russia attempts mandating installation of root CA on clients for TLS MITM

2022-03-10 Thread Eric Kuhnke
https://bugzilla.mozilla.org/show_bug.cgi?id=1758773

I think we'll see a lot more of this from authoritarian regimes in the
future. For anyone unfamiliar with their existing distributed DPI
architecture, google "Russia SORM".


Re: Starlink terminals deployed in Ukraine

2022-03-02 Thread Eric Kuhnke
I'm aware of the qualifications and level of knowledge in network
security/cryptography that they hire for positions in Redmond at Starlink
R They are quite picky about who they hire.

Highly doubt that anything that a 3rd party can do from outside of SpaceX's
network is going to gain admin control over Starlink satellites. Attempt to
jam them at the RF level, maybe.



On Wed, 2 Mar 2022 at 15:40, Mike  wrote:

> You guys are missing the obvious. Russia isn't going to attack starlink in
> space, they are going to take over it's command and control functions and
> deorbit the entire constellation without firing a shot. Same for China and
> N. Korea, which both already have ample motivation already to go after
> starlink because of the existential threat to the iron fisted control they
> exert over their populace and the free flow of information. So while musk
> may be able to fly 50 at a time and has his own launch capability, if the
> command and control facilities are hijacked, musk will run out of money
> putting it all back together.
>
>
>
> On 3/2/22 1:28 PM, Scott McGrath wrote:
>
> The Russians have several ASAT systems not all of them are ground based.
> Remember they also have that grappler which locks onto satellites and
> destroys them. I think this conflict will be the first one where some
> of the battles will be fought in orbit ie the ultimate ‘high ground’ the
> NATO countries have kept to the UN treaties on not militarizing space.
>  Other countries well not so much
>
> On Wed, Mar 2, 2022 at 12:35 PM Valdis Klētnieks 
> wrote:
>
>> On Wed, 02 Mar 2022 08:51:05 -0500, Dorn Hetzel said:
>>
>> > Yeah, if Russia needs one 1st stage booster for every bird they kill,
>> and
>> > SpaceX needs one 1st stage booster for every 50 they put up  Yes,
>> > Russia is bigger than SpaceX, but that's a tremendous ratio.
>>
>> Plus  the asymmetry is even worse than that
>>
>> Elon can use that *same* first stage booster to launch *another* 50
>> next week, while the Russians need to get a *new* booster for shooting
>> down the next bird.
>>
>> That's the *real* game changer in what SpaceX is doing
>>
>


Starlink terminal visual camouflage tests vs improvised fabric materials

2022-03-02 Thread Eric Kuhnke
I have just completed some very unscientific tests of DIY camouflage
materials vs a starlink terminal.

Obviously there is a lot of possible discussion that is possible about
spectrum analyzers, direction finding, jammers, etc within the context of
what's going on in Ukraine right now. All very valid concerns.

That said, there's also some DIY possibilities for making a starlink
terminal much less noticeable from the air or casual observation, such as
if installed on top of a mid rise apartment building in any Ukrainian city.
I would wager that the ratio of portable Ku/Ka-band spectrum analyzers with
horn antennas to invasion foot soldiers/armored vehicle soldiers is rather
low at present.

Terminal is the same as the following RIPE atlas probe location:
https://atlas.ripe.net/probes/1001821

Terminal is a v1 from Jan. 2021.

Fabrics have been draped flat over the Starlink terminal. What effect this
will have vs. suspended in the air a meter or so above it on some sort of
improvised framework is a question I can't really answer right now (if we
have any inflatable or fabric radome specialists here, please chime in).

Average of multiple speedtest.net CLI runs to server ID 11329 in Seattle.
In general any of the well-peered speedtest.net servers in Seattle have the
same results, the bottleneck is the starlink last-mile performance at any
given point in time, and not any terrestrial network factors.


*Baseline terminal with no material above it. I do have a slight tree
obstruction in 1/12th of its field of view to the northeast.*
152.48 Mbps down x 8.23 Mbps up, 3.17% loss
(note this averages more like 0.43% loss over 3 to 10 hour periods to its
gateway in Seattle, I believe the loss during the particular time period
this data was gathered to be an aberration).

*Tent rain fly, synthetic nylon material, dry*
162.02 Mbps down x 7.14 Mbps up, 1.43% loss

*Two layers cotton bed sheet, doubled over on itself, thoroughly soaked in
tap water*
55.79 Mbps down x 3.70 Mbps up, 0.77% loss

*One layer cotton bed sheet, dry*
158.78 Mbps down x 7.16 Mbps up, 0.9% loss

*Two layers thin polypropylene tarpaulin, doubled over on itself,
approximately simulating the thickness of a single layer heavy duty tarp.*
152.77 Mbps down x 9.70 Mbps up, 1.41% loss


Re: Starlink terminals deployed in Ukraine

2022-02-28 Thread Eric Kuhnke
As of right now >90% of the starlink satellites in orbit function in what
we would call a bent pipe topology, where a moving LEO satellite at any
given moment in time needs to be simultaneously in view of a starlink-run
earth station and the CPE.

They have been launching satellites with sat-to-sat laser links but such
architecture is by no means fully operational yet. It does appear to be the
intended architecture in the long term, to enable several hops of satellite
in between a CPE and a starlink-run earth station.

My best theory would be that this is using existing starlink earth stations
in Slovakia or Poland. They may have accelerated the commissioning of some
of the newest ones.





On Mon, 28 Feb 2022 at 16:36, Jay Hennigan  wrote:

> On 2/28/22 16:17, Michael Thomas wrote:
>
> > As a practical matter how does this help? You need to have base
> > stations/dishes, right? Can they be beefy ones that can pump out
> > gigabytes that would be capable of backfilling the load? Or would it
> > need to be multiple in parallel? Wouldn't that bandwidth be constrained
> > by the number of visible satellites in the constellation? I wonder if
> > they've ever even tested it with feeding into an internet facing router.
> > Could tables on the satellites explode?
>
> If there aren't fixed Internet-connected earth stations line-of-sight to
> the satellite that's serving the remote terminal, Starlink will relay
> satellite-to-satellite until a path to an Internet-connected earth
> station is in reach.
>
>  From the linked article:
>
> "Musk has previously stressed Starlink’s flexibility of Starlink in
> providing internet service. In September, Musk talked about how the
> company would use links between the satellites to create a network that
> could provide service even in countries that prohibit SpaceX from
> installing ground infrastructure for distribution.
>
> As for government regulators who want to block Starlink from using that
> capability, Musk had a simple answer.
>
> “They can shake their fist at the sky,” Musk said."
>
> --
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
>


Re: Russian aligned ASNs?

2022-02-25 Thread Eric Kuhnke
The four LTE (3GPP rev-whatever) based networks in Afghanistan are all
still operational. Roshan, AWCC, MTN, Etisalat.

In .AF the line between ISP and MNO is very blurry since 98% of internet
using customers do not have fixed line service at home or office and use a
mobile network instead.

These have developed a great deal of institutional knowledge operating in
very difficult conditions. The major change now is that the Taliban is no
longer burning tower site cabinets/shelters.



On Fri, 25 Feb 2022 at 12:20, scott  wrote:

>
> > My friend just got a phone call.  Electricity, cell phones and
> > internet are all functional at this time.
>
> --
>
>
> Just imagine what it must be like trying to keep those IP networks
> functional at a time like this.  Configuring routers while under fire...
> Those engineers should get some kind of award...
>
> scott
>
>


Re: 40G QSFP+ to 4 SFP+ on MX960

2022-02-24 Thread Eric Kuhnke
I would go as far to say that even if somebody gives you *free* 40G
equipment in the year 2022 you shouldn't use it, because it's a
technological dead-end and becomes a huge bother when you need to interface
with some newly purchased device on the other end of the 40G circuit.

There's a reason why 40G anything is so cheap on eBay and 40G ports are
incredibly rare at the world's major IX points.


On Thu, 24 Feb 2022 at 13:47, Paschal Masha 
wrote:

> Hello,
>
>
>
> Has anyone managed to get the 40G QSFP+ to 4 SFP+ breakout cable to work
> on the 2X40GE QSFPP Juniper MICs?
>
> Which commands did you use to channelize the port under the "chassis fpc"
> mode to get it to channelize to 4x10g at least for one 40G port on that MIC?
>
> My device : MX960.
>
> On a side note, 40G modules/ports are a waste from a design perspective.
>
> Thanks in advance
>
>
>
> Regards
> Paschal Masha | Engineering
> Skype ID: paschal.masha
>
>
>


Re: Amazon peering revisited

2022-02-05 Thread Eric Kuhnke
For those persons who have not received an answer from the Amazon peering
email addresses, or a BGP session with traffic actually flowing across
it...

Obviously Amazon does not share their own traffic volume criteria for
selecting a peer vs. sending traffic to them over a giant IP transit
provider.

I wonder what the actual threshold is as measured in traffic volume from
netflow data to/from the Amazon AS before they start taking a potential
peer seriously. Obviously if you're somebody big like a regional ILEC or a
cable operator that has half of a major city as your incumbent territory,
it's not even a question, but for smaller ISPs it's an interesting question
to discover where exactly that threshold is.



On Fri, 4 Feb 2022 at 13:26, Kevin Burke 
wrote:

> Have gotten into the habit of making annual peering requests to Amazon
> asking turn up a session on a shared IXP peering.  Once was able to get a
> peering session turned up, no traffic was ever shifted onto it before we
> moved out of that carrier hotel a year or so later.  The amazon peering
> email box does have humans surfing it.
>
>
>
> Over the years a number of network operators have mentioned getting little
> response from Amazon about peering requests.
>
>
>
> For a company like Amazon they have little reason to do peering with small
> scale operators.  They already peer with the tier 1’s and assume I will do
> what I need to balance my bits.  The fancy algorithms they use to balance
> traffic around does allow them to operate a decent network with fewer staff
> and less links to the small ISPs.  Just a network operator here, trying to
> get my bytes across the wire.
>
>
>
> Enjoy your weekend!
>
>
>
> Kevin Burke
>
> 802-540-0979
>
> Burlington Telecom
>
> 200 Church St, Burlington, VT
>
>
>
> *From:* NANOG  *On
> Behalf Of *Lincoln Dale
> *Sent:* Thursday, February 3, 2022 12:20 PM
> *To:* Kelly Littlepage 
> *Cc:* nanog@nanog.org
> *Subject:* Re: Amazon peering revisited
>
>
>
> WARNING!! This message originated from an *External Source*. Please use
> proper judgment and caution when opening attachments, clicking links, or
> responding to this email.
>
> On Thu, Jan 27, 2022 at 8:22 AM Kelly Littlepage via NANOG <
> nanog@nanog.org> wrote:
>
> Hi all, a nanog thread started on November 23, 2018 discussed the
> challenges of getting Amazon peering sessions turned up. Has anyone had
> luck since/does anyone have a contact they could refer me to — off-list or
> otherwise? The process of getting PNI in place with other CSPs was
> straightforward, but I haven't heard back from AWS after a month and
> several follow-ups. Our customers would really benefit from us getting this
> sorted.
>
>
>
> There are many folks that here that are in AWS. Assuming you have followed
> what is in https://aws.amazon.com/peering/ (and
> https://aws.amazon.com/peering/policy/) then send me details privately
> about what/when/who and I'll reach out internally to the relevant folks.
>
>
>


Re: [EXTERNAL] Re: Flow collection and analysis

2022-01-27 Thread Eric Kuhnke
Not at all, what I'm recommending is that people who develop something that
is specialized (like netflow analysis software) don't need to expend the
person-hours and extensive development time to implement something that has
already been better implemented by people who are httpd specialists.

The amount of possible design complexities and security risks that go into
shipping a 'stable' versio of apache2 or nginx are beyond the scope of any
small to medium sized non-httpd-related opens source software project. Let
the apache2 or nginx developers handle that.

It's like saying that because a piece of software communicates with
something externally by SMTP, either inbound or outbound email or both,
some software developer should take the time to re-implemnt and write from
scratch their own SMTP, rather than relaying mail via a postfix daemon
running on the same server.

Or because you have a piece of software that queries something over SNMP,
don't use the perfectly good ISC SNMP packages that exist for centos or
debian to issue snmpgets, but write from scratch your own snmp poller.








On Wed, 26 Jan 2022 at 07:34, Mel Beckman  wrote:

> People who advocate TLS lash-ups like nginx front ends remind me of Mr.
> Beans DIY automobile security, which started with a screwed-on metal hasp
> and padlock, and then continued to a range of additional “layers”. Not
> “defense-in-depth”, merely unwarranted “complexity-in-depth”:
>
> https://youtu.be/CCl_KxGLgOA
>
> TLS is a standardized, fully open-source package that can be integrated
> into even tiny IoT devices (witness this $10 WiFi module
>  https://www.adafruit.com/product/4201
> ). The argument that people who
> want intrinsically secure products can just bolt-on their own security are
> missing the point entirely. Every web-enabled product should be required to
> implement TLS and then let custiners decide when they want to enable it.
> Vendors who are so weak that they can’t should have their products go
> straight into /dev/null.
>
> -mel via cell
>
> On Jan 26, 2022, at 6:51 AM, heasley  wrote:
>
> Wed, Jan 26, 2022 at 07:21:19AM -0600, Mike Hammett:
>
> Why is it [TLS] even necessary for such a function?
>
>
> confidentiality and integrity, even if you do not care about
> authentication.
> I am surprised that question is asked.
>
> The fewer things that are left unprotected, the better for everyone.  those
> with concern about erosion of their privacy and human rights benefit from
> everything being protected, everywhere for everyone.
>
>


Re: [EXTERNAL] Re: Flow collection and analysis

2022-01-27 Thread Eric Kuhnke
If the purpose of the software is not to be a dedicated purpose http
daemon, use something that already exists with a deep feature set that can
be configured as needed for the purpose, such as apache2 with openssl or
nginx.

It's not reasonable to expect that the developers of elastiflow reinvent
the wheel and write their own httpd with TLS support, if it can be easily
put "behind" apache2 or nginx. The risks of having people who aren't full
time httpd specialists write their own http daemon and mitigate every
possible security risk in a TLS setup are greater than using what already
exists.

It's a one page size configuration file in nginx.




On Wed, 26 Jan 2022 at 05:17, Laura Smith via NANOG  wrote:

> ‐‐‐ Original Message ‐‐‐
>
> On Wednesday, January 26th, 2022 at 11:08, Eric Kuhnke <
> eric.kuh...@gmail.com> wrote:
>
> > elastiflow is extremely easy to run on an httpd listening only on
> localhost and proxy behind a simple nginx TLS1.2/1.3 only configuration
> listening on port 443.
> >
>
> I don't know about anyone else here, but frankly in 2022 TLS support
> should be a first class citizen.
>
> If I have to mess around with running something else as a proxy in front
> of it then that's the end of my software evaluation.
>
> Crypto is no longer "nice to have" option these days.
>


Re: [EXTERNAL] Re: Flow collection and analysis

2022-01-26 Thread Eric Kuhnke
elastiflow is extremely easy to run on an httpd listening only on localhost
and proxy behind a simple nginx TLS1.2/1.3 only configuration listening on
port 443.

as are a number of other tools.



On Tue, 25 Jan 2022 at 16:06, Laura Smith via NANOG  wrote:

> On Tuesday, January 25th, 2022 at 23:50, Compton, Rich A <
> rich.comp...@charter.com> wrote:
>
> > You can pretty much do the same thing with Elastic’s filebeat (
> https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-netflow.html).
>
> >
>
> Has Elastic decided to join the rest of the world in the 21st century yet ?
>
> Last time I looked at it (not too many years ago) they had no TLS
> support.  Bit of a show-stopper in today's security environment.
>


Re: Coverage of the .to internet outage

2022-01-20 Thread Eric Kuhnke
If you're a small pacific island nation state with a limited budget, and a
working submarine cable, maintaining a SCPC geostationary satellite service
that might be $20,000 a month (on 36-60 month term) in transponder kHz may
seem like a very large ongoing expense.

Ideally it would be possible to keep a backup circuit operating in a very
narrow section of kHz during normal times. Along with the contractual
ability to significantly expand it on demand, but more capacity on the same
satellite/same polarity without physical reconfiguration of the remote end
earth station may not always be possible.



On Wed, 19 Jan 2022 at 15:50, Scott Weeks  wrote:

>
> --- j...@baylink.com wrote:
> From: "Jay R. Ashworth" 
>
> This piece:
>
>
> https://www.npr.org/2022/01/18/1073863310/an-undersea-cable-fault-could-cut-tonga-from-the-rest-of-the-world-for-weeks
>
> drills down to this piece with slightly more detail:
>
>
> https://www.reuters.com/markets/funds/undersea-cable-fault-could-cut-off-tonga-rest-world-weeks-2022-01-18/
>
> I'm told their national carrier is trying to bring in a ground station as
> well, though not whom it will connect to.
> --
>
>
> It's hard to imagine they don't have a lot of Kacific Terminals or other
> satellite connectivity there.
>
> That's what most of the South Pacific uses and all used before the cables
> were laid.  Maybe the journalists
> missed that like they miss things when talking about our stuff?
>
> scott
>
>


Open source mapping of US high voltage electrical grid

2022-01-15 Thread Eric Kuhnke
Possibly of interest for network operators who have inter-city circuits,
where the underlying carrier is something on OPGW fiber in high voltage
lines.

These people seem to be making an effort at mapping out high voltage lines,
hydroelectric dams, substations, etc.

https://openinframap.org


Re: Carrier Options in Hong Kong

2021-12-18 Thread Eric Kuhnke
I think the biggest difference between what the IP transit providers have
described is that PCCW is also a major middle-mile and last-mile provider
in Hong Kong. You'll find their 100Mbps to gigabit class end user service
in apartments, condos and office buildings throughout the city.

The non-HK based transit providers that would be in a top-40 CAIDA ASRANK
size are generally *not* operators of last mile connectivity within the
city.



On Fri, Dec 17, 2021 at 2:54 PM nanoguser99 via NANOG 
wrote:

> Nanog,
>
> Currently my organization uses PCCW which we pay through the nose for and
> I'm looking to cut them.  This was put in place before me.  I was informed
> that PCCW is "the carrier" in Hong Kong but based on my analysis I'm not
> sure that's the case.  My analysis of carriers such as Lumen and Cogent put
> them on par with PCCW.  Pings to random IPs in HK are reasonable fast on
> all of them, same with pings to cloud providers.   Access to mainland is
> not a hard requirement but just to check they all had 300+ ms latency to
> known IPs in Shanghai and Tanjin.
>
> I know some regions such as Korea or Dubai are monopolized where the wrong
> carrier takes you on a far away path to get a few blocks down the street.
>
> I don't need anything special, just general DIA and good access to
> eyeballs and internet.  I just wanted to see people's opinions here as APAC
> connectivity can be tricky.
>
> - Nanoguser99
>
> Sent with ProtonMail  Secure Email.
>
>


Re: SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot

2021-11-24 Thread Eric Kuhnke
Anecdotally, anyone that's had reason to manually go through logs for port
5060 SIP for any public facing ipv4 /32 will see the vast amounts of random
"things" out there on the internet trying common extension password combos
to register.

It's been a large amount of background noise on the internet for a very log
time now.



On Wed, Nov 24, 2021 at 5:20 PM Gavin Henry  wrote:

> Hi all,
>
> I hope you don't mind the post, but thought this might be of use and
> in the spirit of release early, release often I've done an alpha
> release:
>
> https://github.com/SentryPeer/SentryPeer
>
> There's a presentation too if you'd like to watch/read where I hope to
> go with this:
>
> https://blog.tadsummit.com/2021/11/17/sentrypeer/
>
> Working on the API and web UI next, then the p2p part of it. Feel free
> to submit any feature requests or have a play :-)
>
> Thanks for reading and any feedback is welcome!
>
> --
> Kind Regards,
> Gavin Henry.
>


Quantifying the customer support and impact of cgnat for residential ipv4

2021-11-21 Thread Eric Kuhnke
Looking for anecdotal examples of the following:

If you put N number of individual DHCP client residential broadband
customers behind cgnat for ipv4, what percent of customers contact support
and become a support/troubleshooting case later.

And what percent of customers have a significant problem with it, to the
extent that they either need to be offered a $5-10/mo extra /32 dedicated
real address, or possibly cancel?

Hopefully on sample sizes of 5000 or more.

All else assuming that the customers are also dual stack v4/v6 and can
reach v6 things normally without any of that traffic going through the
cgnat.


Re: verizon fios, northeast, routing issues?

2021-10-09 Thread Eric Kuhnke
alter.net is just the legacy RDNS for things in AS701 (uunet). Nothing
weird there.

https://en.wikipedia.org/wiki/UUNET

On Sat, Oct 9, 2021 at 1:46 PM Miles Fidelman 
wrote:

> Any Verizon folks here?
>
> I've been having some rather weird network issues lately - just reading
> email via IMAP, from home.  Over a 1gig FIOS connection to a machine in
> a nearby Tierpoint data center that has LOTS of good connectivity.
>
> I just tried some traceroutes, and got some interesting results:
>
> These originate on a machine connected to a 1gig FIOS feed, and end at a
> machine, located in a Tierpoint datacenter, about 10 miles from here.
>
> traceroute to ntcorp.com (207.154.13.58), 64 hops max, 52 byte packets
>   1  * fios_quantum_gateway (192.168.1.1)  3.530 ms  2.822 ms
>   2  * * *
>   3  100.41.27.110 (100.41.27.110)  14.970 ms  5.323 ms  6.306 ms
>   4  0.csi1.bstnmafr-mse01-bb-su1.alter.net (140.222.10.32)  11.069 ms
> 8.477 ms  17.097 ms
>   5  * * *
>   6  0.ae1.br1.bos30.alter.net (140.222.236.253)  17.121 ms  19.027 ms
>  0.ae2.br1.bos30.alter.net (140.222.236.255)  19.795 ms
>   7  * * *
>   8  colo4-dalla.bear1.boston1.level3.net (4.53.61.86)  2205.648 ms
> 8.331 ms  13.161 ms
>   9  static-33-65-203-66.axsne.net (66.203.65.33)  16.951 ms  13.791 ms
>  static-145-65-203-66.axsne.net (66.203.65.145)  21.503 ms
> 10  server1.ntcorp.com (207.154.13.58)  17.872 ms  15.902 ms  14.415 ms
>
> Several things jump out:
>
> 1. alter.net is not a common path between here & there - usually a lower
> grade connection, when other backbones aren't working right
>
> 2. origin - alter.net - level.3 - endpoint is just bizarre, one would
> think that the regional FIOS network has a direct connection to level.3
> (it also seems kind of odd that the packets are flowing from Acton MA,
> to Boston, and back out to Marlboro MA - there's an awful lot of fiber
> running along Rt. 495, and the networks are fairly dense around here)
>
> 3. The intermittent, high delays (factor of 10) jump out  (also, when
> running ping tests, there seem to be intermittent periods of long
> sequences of timeouts)
>
> All in all it's really mucking with both streaming services, and simply
> posting emails (SMTP timeouts).
>
> All of which leads me to wonder if there's something mucked up with
> Verizon's routing tables (or a particular network interface).
>
> Any insights (or fixes) to be had?
>
> Thanks,
>
> Miles Fidelman
>
>
>
> --
> In theory, there is no difference between theory and practice.
> In practice, there is.   Yogi Berra
>
> Theory is when you know everything but nothing works.
> Practice is when everything works but no one knows why.
> In our lab, theory and practice are combined:
> nothing works and no one knows why.  ... unknown
>
>


Re: massive facebook outage presently

2021-10-04 Thread Eric Kuhnke
I am starting to see reports that in ISPs with very large numbers of
residential users, customers are starting to press the factory-reset
buttons on their home routers/modems/whatever, in an attempt to make
Facebook work. This is resulting in much heavier than normal first tier
support volumes. The longer it stays down the worse this is going to get.



On Mon, Oct 4, 2021 at 3:30 PM Jay Hennigan  wrote:

> On 10/4/21 12:11, b...@theworld.com wrote:
> >
> > Although I believe it's generally true that if a company appears
> > prominently in the news it's liable to be attacked I assume because
> > the miscreants sit around thinking "hmm, who shall we attack today oh
> > look at that shiny headline!" I'd hate to ascribe any altruistic
> > motivation w/o some evidence like even a credible twitter post (maybe
> > they posted that on FB? :-)
>
> I personally believe that the outage was caused by human error and not
> something malicious. Time will tell.
>
> However, if you missed the 60 Minutes piece, it was a former employee
> who spoke out with some rather powerful observations. I don't think that
> this type of worldwide outage was caused by an outside bad actor. It is
> certainly within the realm of possibility that it was an inside job.
>
> In other news:
>
> https://twitter.com/disclosetv/status/1445100931947892736?s=20
>
> --
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
>


Re: massive facebook outage presently

2021-10-04 Thread Eric Kuhnke
Considering the massive impact of this it would be interesting to see some
traffic graphs from ISPs that have PNIs with Facebook, or high volume
peering sessions across an IX, showing traffic to FB falling off a cliff.

On Mon, Oct 4, 2021 at 12:16 PM George Herbert 
wrote:

> And WhatsApp and Instagram.  Twitter users nationwide agree anecdotally.
>
> What I’m getting is DNS failure.
>
> -George
>
> Sent from my iPhone
>
> On Oct 4, 2021, at 9:07 AM, Eric Kuhnke  wrote:
>
> 
> https://downdetector.com/status/facebook/
>
> Normally not worth mentioning random $service having an outage here, but
> this will undoubtedly generate a large volume of customer service calls.
>
> Appears to be failure in DNS resolution.
>
>


massive facebook outage presently

2021-10-04 Thread Eric Kuhnke
https://downdetector.com/status/facebook/

Normally not worth mentioning random $service having an outage here, but
this will undoubtedly generate a large volume of customer service calls.

Appears to be failure in DNS resolution.


What happens when you don't validate/scrub data on input from whois

2021-09-28 Thread Eric Kuhnke
https://research.securitum.com/fail2ban-remote-code-execution/

What happens if you put the following in your whois entry:

drop table prefixes;

Or anything similar...

https://xkcd.com/327/


Re: EXTERNAL: Re: VoIP Provider DDoSes

2021-09-28 Thread Eric Kuhnke
For those persons with voip.ms accounts, the DDoS-protected servers are in
their control panel with a green checkmark next to them as recommended
servers.

Now it looks like part of the DDoS has shifted to bandwidth.com.

On Mon, Sep 27, 2021 at 4:40 PM Mike Hammett  wrote:

> It seems like Cloudflare can do something now too because VoIP.MS is now
> routed through Cloudflare for their new servers.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Ray Orsini" 
> *To: *"Mike Hammett" , "NANOG" 
> *Sent: *Wednesday, September 22, 2021 8:15:51 AM
> *Subject: *Re: EXTERNAL: Re: VoIP Provider DDoSes
>
> Yes there are. I was about to message Steve about the correction. Corero
> and path.net are options. There are others.
> [image: OIT Website] 
> Ray Orsini​
> Chief Executive Officer
> OIT, LLC
>  *305.967.6756 x1009* <305.967.6756%20x1009>  |   *305.571.6272*
>  *r...@oit.co*   |  [image: https://www.oit.co]
>  * www.oit.co* 
>  oit.co/ray
> [image: Facebook] 
> [image: LinkedIn] 
> [image: Twitter] 
> [image: YouTube] 
>
> *How are we doing? We'd love to hear your feedback. https://go.oit.co/review*
> 
> --
> *From:* NANOG  on behalf of Mike
> Hammett 
> *Sent:* Wednesday, September 22, 2021 9:08:22 AM
> *To:* NANOG 
> *Subject:* EXTERNAL: Re: VoIP Provider DDoSes
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe. If you are unsure, please forward this email to the
> CSE team for review.
>
> https://twit.tv/shows/security-now/episodes/837?autostart=false
>
>
> It looks like Security Now covered this yesterday. They claimed that,
> "There  is  currently  no  provider of  large  pipe  VoIP  protocol  DDoS
>  protection."
>
> Are any of the cloud DDoS mitigation services offering a service like this.
>
> --
> *From: *"Mike Hammett" 
> *To: *"NANOG" 
> *Sent: *Tuesday, September 21, 2021 4:19:42 PM
> *Subject: *VoIP Provider DDoSes
>
> As many may know, a particular VoIP supplier is suffering a DDoS.
> https://twitter.com/voipms
>
> Are your garden variety DDoS mitigation platforms or services equipped to
> handle DDoSes of VoIP services? What nuances does one have to be cognizant
> of? A WAF doesn't mean much to SIP, IAX2, RTP, etc.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>
>


Re: IPv6 woes - RFC

2021-09-23 Thread Eric Kuhnke
The DMCA notices for that single ipv4 /32 must be interesting.


On Thu, Sep 23, 2021 at 11:35 AM Colton Conor 
wrote:

> 300 apartments Mark. No, it's bulk internet and wifi so a single provider.
>
> On Wed, Sep 22, 2021 at 8:01 PM Mark Andrews  wrote:
> >
> > And how many apartments where covered by that single IP address? Was this
> > where there is a restriction on other providers so the occupants had no
> > choice of wireline ISP?
> >
> > > On 23 Sep 2021, at 09:38, Colton Conor  wrote:
> > >
> > > Where does this "You can only have about 200-300 subscribers per IPv4
> > > address on a CGN." limit come from? I have seen several apartment
> > > complexes run on a single static IPv4 address using a Mikrotik with
> > > NAT.
> > >
> > > On Wed, Sep 22, 2021 at 2:49 PM Baldur Norddahl
> > >  wrote:
> > >>
> > >>
> > >>
> > >> On Wed, 22 Sept 2021 at 16:48, Masataka Ohta <
> mo...@necom830.hpcl.titech.ac.jp> wrote:
> > >>>
> > >>> Today, as /24 can afford hundreds of thousands of subscribers
> > >>> by NAT, only very large retail ISPs need more than one
> > >>> announcement for IPv4.
> > >>
> > >>
> > >> You can only have about 200-300 subscribers per IPv4 address on a
> CGN. If you try to go further than that, for example by using symmetric
> NAT, you will increase the number of customers that want to get a public
> IPv4 of their own. That will actually decrease the combined efficiency and
> cause you to need more, not less, IPv4 addresses.
> > >>
> > >> Without checking our numbers, I believe we have at least 10% of the
> customers that are paying for a public IPv4 to escape our CGN. This means a
> /24 will only be enough for about 2500 customers maximum. The "nat
> escapers" drown out the efficiency of the NAT pool.
> > >>
> > >> The optimization you need to do is to make the CGN as customer
> friendly as possible instead of trying to squeeze the maximum customers per
> CGN IPv4 address.
> > >>
> > >> Perhaps IPv6 can lower the number of people that need to escape IPv4
> nat. If it helps just a little bit, that alone will make implementing IPv6
> worth it for smaller emerging operators. Buying IPv4 has become very
> expensive. Yes you can profit from selling a public IPv4 address to the
> customer, but there is also the risk that the customer just goes to the
> incumbent, which has old large pools of IPv4 and provides it for free.
> > >>
> > >> Regards,
> > >>
> > >> Baldur
> > >>
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> >
>


Re: VoIP Provider DDoSes

2021-09-21 Thread Eric Kuhnke
Unlike http based services which can be placed behind cloudflare or
similar, harder to protect sip trunking servers.

The provider in question makes use of third party hosting services for each
of their cities' POPs. It is my understanding that for the most part they
do not run their own infrastructure but either rent dedicated servers or a
few rack units of Colo in each city.

I question whether some or any of those hosting companies have sufficient
inbound (200-400Gbps) capacity to weather a moderately sized DDoS.



On Tue, Sep 21, 2021, 5:30 PM Mike Hammett  wrote:

> As many may know, a particular VoIP supplier is suffering a DDoS.
> https://twitter.com/voipms
>
> Are your garden variety DDoS mitigation platforms or services equipped to
> handle DDoSes of VoIP services? What nuances does one have to be cognizant
> of? A WAF doesn't mean much to SIP, IAX2, RTP, etc.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>


Re: Xfi Advances Security (comcast)

2021-09-10 Thread Eric Kuhnke
Ideally being your own customer owned cable modem that meets specs (Comcast
does allow this in some regions) that will function as a layer 2 bridge.

On Fri, Sep 10, 2021, 1:46 PM Owen DeLong  wrote:

> First thing I do with any cable modem is convert it to bridge mode.
>
> The fewer “smarts” in the cable modem doing odd things to my traffic, the
> better.
>
> Owen
>
>
> On Sep 10, 2021, at 10:40 , Eric Kuhnke  wrote:
>
> I know this is not a solution to your problem, but I have found myself
> more often running the public interface of openvpn systems on port 443. Any
> sufficiently advanced DPI setup will be able to tell that it's not quite
> normal https traffic.
>
> But 99% of the time it seems to serve the purpose of defeating
> heavily-restricted "free" wifi in airports, hotels, random guest/amenity
> wifi stuff, which obviously can't block https/443 to the world these days.
>
> On Fri, Sep 10, 2021 at 11:08 AM Jason Kuehl 
> wrote:
>
>> This is an SSL VPN that is being blocked. This is what failure looks
>> like. Curl is the same.
>>
>> Once we disable the Xfi  Advanced Security everyone can connect.
>>
>> [image: image.png]
>>
>> On Fri, Sep 10, 2021 at 11:01 AM Jim Popovitch via NANOG 
>> wrote:
>>
>>> On Fri, 2021-09-10 at 10:31 -0400, Jason Kuehl wrote:
>>> > For whatever reason Comcast Xfinity is blocking my VPN URL.
>>>
>>> Not certain that this applies, but Concast Advanced Security (setup in
>>> your Comcast gateway) only allows outbound VPN connections to UDP ports
>>> 500, 4500, and 62515 and TCP port 1723.
>>>
>>> -Jim P.
>>>
>>>
>>
>> --
>> Sincerely,
>>
>> Jason W Kuehl
>> Cell 920-419-8983
>> jason.w.ku...@gmail.com
>>
>
>


Re: Xfi Advances Security (comcast)

2021-09-10 Thread Eric Kuhnke
I know this is not a solution to your problem, but I have found myself more
often running the public interface of openvpn systems on port 443. Any
sufficiently advanced DPI setup will be able to tell that it's not quite
normal https traffic.

But 99% of the time it seems to serve the purpose of defeating
heavily-restricted "free" wifi in airports, hotels, random guest/amenity
wifi stuff, which obviously can't block https/443 to the world these days.

On Fri, Sep 10, 2021 at 11:08 AM Jason Kuehl 
wrote:

> This is an SSL VPN that is being blocked. This is what failure looks like.
> Curl is the same.
>
> Once we disable the Xfi  Advanced Security everyone can connect.
>
> [image: image.png]
>
> On Fri, Sep 10, 2021 at 11:01 AM Jim Popovitch via NANOG 
> wrote:
>
>> On Fri, 2021-09-10 at 10:31 -0400, Jason Kuehl wrote:
>> > For whatever reason Comcast Xfinity is blocking my VPN URL.
>>
>> Not certain that this applies, but Concast Advanced Security (setup in
>> your Comcast gateway) only allows outbound VPN connections to UDP ports
>> 500, 4500, and 62515 and TCP port 1723.
>>
>> -Jim P.
>>
>>
>
> --
> Sincerely,
>
> Jason W Kuehl
> Cell 920-419-8983
> jason.w.ku...@gmail.com
>


Re: if not v6, what?

2021-09-07 Thread Eric Kuhnke
The vast majority of LTE based last mile users in developing nation
environments (where maybe less than 5% of people have residential wireline
broadband to their residence) are already behind a cgnat.

In many places it's actually an anomaly and weird for a person to desire,
or be able to afford, both a broadband internet connection at home with
wired router/801.11 AP, and also the (per GB) data service for their
cellphone. They choose to go with only the latter.




On Sun, Sep 5, 2021 at 6:00 PM Grant Taylor via NANOG 
wrote:

> On 9/5/21 3:28 PM, Michael Thomas wrote:
> > I looked up CGN's this morning and the thing that struck me the most was
> > losing port forwarding. It's probably a small thing to most people but
> > losing it means to get an incoming session it always has to be mediated
>
> > by something on the outside. Yuck. So I hope that is not what the future
> > hold, though it probably does.
>
> I think we are heading into a world where Internet is going to be
> bifurcated with "/on/ the Internet" (with globally routed IP
> address(es)) or "/access/ /to/ the Internet" (with one or more layers of
> CGN).
>
> I think that the vast majority of consumers would be content with the
> latter while a small minority will demand the former.
>
> Content hosting will almost definitely require the former.  (Wiggle room
> is for other arrangements that can be made.)
>
>
>
> --
> Grant. . . .
> unix || die
>
>


Re: Hurricane Ida updates

2021-09-04 Thread Eric Kuhnke
During the peak of the rain storm in NJ+NY (see flooding deaths referenced
in previous email), the wireless emergency alert systems were sending,
simultaneously:

1) TORNADO WARNING SEEK SHELTER NOW GO TO BASEMENT [1]

2) FLOOD WARNING SEEK HIGH GROUND GET OUT OF BASEMENTS [2]


1: https://www.google.com/search?client=firefox-b-1-d=nyc+tornado+warning

2:
https://www.google.com/search?client=firefox-b-1-d=nyc+ida+flood+warning+wireless+emergency+alert




On Sat, Sep 4, 2021 at 12:03 AM Sean Donelan  wrote:

> Two 19-year-old linemen died in an electrocution accident in Jefferson
> County, Alabama assisting with storm recovery.  Cause under investigation.
>
> at least 66 deaths confirmed:
> 25 in New Jersey (at least 8 died in vehicle flooding),
> 17 in New York (at least 11 died in basement apartment flooding),
> 12 in Louisiana (4 died from CO poisoning),
> 5 in Pennsylvania,
> 2 in Mississippi,
> 2 in Alabama,
> 1 in Maryland,
> 1 in Virginia,
> 1 in Connecticut (state police officer vehicle flooding)
>
> Power outages (poweroutage.us)
>
> 756,173 Louisiana
> 9,615 Pennsylvania
> 7,256 Mississippi
>
> Entergy New Orleans no expects most power to be restored by September 8,
> 2021.  Reminder, Puerto Rico is still experiencing rolling blackouts
> after 2017 hurricanes destroyed its power grid.
>
>
> There were over 374 Wireless Emergency Alerts (WEA) issued nation-wide
> between August 26, 2021 (initial Hurricane warnings) and September 2,
> 2021.  I'm still digging into how many WEA messages are related to
> Hurricane Ida (HUW event codes) versus other severe weather events
> elsewhere (e.g. FRW event codes - wildfire warnings in California).
>
> Remember your Roku, Amazon Firestick, Google TV, etc. streaming devices
> don't alert you to emergency warnings.  Amazon Alexa does have an
> option to activate severe weather warnings on its Echo/Echo Show devices.
>
> Wireless Emergency Alert messages by EAS event code (codes don't appear in
> the message itself)
>
> Event   Count
> CAE 7   Child Abduction
> CDW 1   Civil Danger
> CEM 3   Civil Emergency
> DSW 3   Dust Storm
> EVI 11  Immediate Evacuation
> EWW 4   Extreme Winde
> FFW 102 Flash Flood
> FRW 10  Fire Warning
> HMW 1   Hazardous Material
> HUW 47  Hurricane
> LAE 3   Local Area Emergency
> LEW 5   Law Enforcement Warning
> SPW 1   Shelter-in-Place
> SSW 29  Storm Surge
> SVR 7   Severe Thunderstorm
> TOR 142 Tornado
>
> Grand Total 376
>
>
>
> The FCC disaster reporting is limited to only 3 states (AL, LA, MS)
>
> 2 public safety answering points (9-1-1) partially re-routed
>
> FCC is not reporting any other states.
>
>
> Wireless providers had open roaming and waiving overage charges through
> Friday. I don't know how much longer they will keep open roaming
> activated.
>
> 20% cell sites in Louisiana out of service (statewide average)
> Louisiana counties: 55% of Plaquemines, 52% of LaFourche
>
> 1.4% in Alabama, 0.8% in Mississippi.
> FCC not reporting any other states.
>
>
> Cable and wireless outages (subscribers) in AL, LA, MS.
>
> 1,119 Alabama,
> 427,587 Louisiana,
> 2,157 Mississippi
>
> FCC not reporting any other states.
>
>
> 2 TV, 9 FM and 4 AM stations reported out of service in AL, LA, MS.
>
> FCC not reporting any other states.
>


Re: Telecommunications network drafting software

2021-09-01 Thread Eric Kuhnke
For logical diagrams of networks, on MacOS, I recommend Omnigraffle.


On Wed, Sep 1, 2021 at 2:36 PM Etienne-Victor Depasquale via NANOG <
nanog@nanog.org> wrote:

> Hello folks,
>
> Would you care to share some pointers to drafting software which you use
> to draw up architectural drafts (for telecoms networks, including cable
> operators' networks) ?
>
> I've found Visio to be a bit weak in this respect, even after adding third
> party stencils.
>
> One product I'm exploring is ConceptDraw's "diagram" product, but I'd like
> to hear about anything you can share with me.
>
> Cheers,
>
> Etienne
>
> --
> Ing. Etienne-Victor Depasquale
> Assistant Lecturer
> Department of Communications & Computer Engineering
> Faculty of Information & Communication Technology
> University of Malta
> Web. https://www.um.edu.mt/profile/etiennedepasquale
>


Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

2021-08-22 Thread Eric Kuhnke
I don't think that's a valid example at all since clearly the entity to
peer with for access to the BellMTS ASes and their customers is AS577.
Which definitely does peer and is present at IX points.

I am familiar with another entity which has an entire regional ILEC's AS
behind it, but where the newly created AS (part of the people who bought
the big chunk of ILEC) is present at many IX points and peers quite widely.

Was referring more to a theoretical example if somebody were to attempt to
build a medium to large sized ISP exclusively as a transit customer of some
top-50 CAIDA ASrank size transit providers, and do no peering whatsoever.

On Thu, Aug 19, 2021 at 3:05 PM Adam Thompson 
wrote:

> I have an example locally: BellMTS (ASNs 684, 7122, 4398), the local ILEC.
> To the best of my knowledge, they only peer with downstream customers
> (including myself) and their sole upstream, Bell Canada (AS577).  Meanwhile
> that's a ~700k eyeball network (with some hosting, sure), roughly ~400Gbps
> upstream connectivity, and no public peering whatsoever.  In fact, one
> might describe their peering model as "feudal", where they're subjugate to
> their corporate overlord (Bell Canada).
> It's unfortunate, I know there are some smart people working there, but
> either they don't understand the value of sub-1ms access to root
> nameservers (*cough* MBIX *cough*), or they're prevented from doing
> anything about it.
>
> [Disclaimer: I'm on the MBIX board.  But I also used to work for MTS, and
> tried to setup the first peering relationship but got shot down for
> "marketing" reasons, something about "legitimizing the competition".  Very
> monopolistic thinking, IMO.]
>
> Meanwhile, MTS still has a PeeringDB  record, even though it documents
> quite nicely the fact that perhaps that record shouldn't exist, or at least
> doesn't need to.
>
> FWIW, their upstream, Bell Canada, is a very different story.  And also
> mostly ~8msec away.
>
> -Adam
>
> *Adam Thompson*
> Consultant, Infrastructure Services
> [image: 1593169877849]
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca
> www.merlin.mb.ca
>
> --
> *From:* NANOG  on behalf
> of Eric Kuhnke 
> *Sent:* August 19, 2021 10:32
> *To:* Ben Maddison ; nanog@nanog.org list <
> nanog@nanog.org>
> *Subject:* Re: PeerinDB refuses to register certain networks [was:
> Setting sensible max-prefix limits]
>
> I agree with you in the utility of that, but sort of as a side topic...
>
> I wonder how many ASes are out there that have any significant volume of
> traffic/multi-site presences, but are exclusively 100% transit customers,
> do not have any PNIs at major carrier hotels, and are not members of any
> IX.
>
> What would be a good example of such an AS and how big of a network would
> it be? Undoubtedly there are some enterprise end user type customers set up
> like that, but I can't imagine they receive a very large volume of
> unsolicited peering requests.
>
> On Thu, Aug 19, 2021 at 6:32 AM Ben Maddison via NANOG 
> wrote:
>
> Hi Patrick,
>
> On 08/18, Patrick W. Gilmore wrote:
> > > Of course! Including headers to show authenticity. I was very amused
> by the
> > > explanation of the "chicken and egg" problem. Who's creating that? The
> networks
> > > who refuse to peer with non-peeringdb registered ASNs, or peeringdb
> who won't
> > > recognize ASNs that are not peering with anyone because nobody wants
> to peer
> > > with them because they are not registered in peeringdb because nobody
> wants to
> > > peer with them? You get the idea.
> >
> > First, most networks do not require a PDB record to peer. (Silly of
> > them, I know, but still true.)
> >
> > Second, you do not need to have a PDB record to get a link to an IXP.
> > Even membership in a free IXP is sufficient for an account in PDB, as
> > Grizz points out below.
> >
> > Third, if you have an agreement, even just an email, saying a network
> > will peer with you once you have a record, that may well suffice. Have
> > you asked any network to peer? Private peering (because you are not on
> > an IXP) is usually reserved for networks with more than a modicum of
> > traffic. If your network is large enough to qualify for private
> > peering, I have trouble believing you cannot get another network to
> > agree to peer so you can get a record.
> >
> > I guess you are right, the _Peering_DB does not register “certain”
> > networks. Those networks would be ones that do not peer. Which seems
> > pretty obvious

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

2021-08-19 Thread Eric Kuhnke
I agree with you in the utility of that, but sort of as a side topic...

I wonder how many ASes are out there that have any significant volume of
traffic/multi-site presences, but are exclusively 100% transit customers,
do not have any PNIs at major carrier hotels, and are not members of any
IX.

What would be a good example of such an AS and how big of a network would
it be? Undoubtedly there are some enterprise end user type customers set up
like that, but I can't imagine they receive a very large volume of
unsolicited peering requests.

On Thu, Aug 19, 2021 at 6:32 AM Ben Maddison via NANOG 
wrote:

> Hi Patrick,
>
> On 08/18, Patrick W. Gilmore wrote:
> > > Of course! Including headers to show authenticity. I was very amused
> by the
> > > explanation of the "chicken and egg" problem. Who's creating that? The
> networks
> > > who refuse to peer with non-peeringdb registered ASNs, or peeringdb
> who won't
> > > recognize ASNs that are not peering with anyone because nobody wants
> to peer
> > > with them because they are not registered in peeringdb because nobody
> wants to
> > > peer with them? You get the idea.
> >
> > First, most networks do not require a PDB record to peer. (Silly of
> > them, I know, but still true.)
> >
> > Second, you do not need to have a PDB record to get a link to an IXP.
> > Even membership in a free IXP is sufficient for an account in PDB, as
> > Grizz points out below.
> >
> > Third, if you have an agreement, even just an email, saying a network
> > will peer with you once you have a record, that may well suffice. Have
> > you asked any network to peer? Private peering (because you are not on
> > an IXP) is usually reserved for networks with more than a modicum of
> > traffic. If your network is large enough to qualify for private
> > peering, I have trouble believing you cannot get another network to
> > agree to peer so you can get a record.
> >
> > I guess you are right, the _Peering_DB does not register “certain”
> > networks. Those networks would be ones that do not peer. Which seems
> > pretty obvious to me - it is literally in the name.
> >
> A PDB record for an Internet-connected ASN, listing no IXPs or
> facilities, but with a note saying approximately "We only use transit,
> and don't peer" has some utility: it saves prospective peers from
> finding contacts to ask and sending emails, etc.
>
> I'd argue this is in scope for PDB. But perhaps there was additional
> context to the original decision that I'm missing?
>
> Cheers,
>
> Ben
>


Re: russian prefixes

2021-07-30 Thread Eric Kuhnke
Is this done entirely in software? Looking at the PDF of the installation
guide for this product the system seems to be an x86-64 network appliance
motherboard in a 1U chassis from a vendor such as Lanner or similar.

Any of the companies in Taiwan or China that make systems with eight, ten
or twelve Intel chipset 10GbE SFP+ cage interfaces on a PCI-E 3.0 bus on a
motherboard, the rest of it is a fairly normal embedded x86-64 motherboard.


On Fri, Jul 30, 2021 at 3:21 PM Denys Fedoryshchenko <
nuclear...@nuclearcat.com> wrote:

> On 2021-07-30 18:45, Christopher Morrow wrote:
> > On Fri, Jul 30, 2021 at 10:57 AM Christopher Morrow
> >  wrote:
> >
> >> On Thu, Jul 29, 2021 at 9:07 PM Denys Fedoryshchenko
> >>  wrote:
> >>
> >>> On 2021-07-29 20:46, Randy Bush wrote:
> > Looks like it did shown on news only.
> 
>  :)
> 
>  i wondered
> >>> They have installed devices called "TSPU" on major operators.
> >>> Isolation of specific networks is done without changing BGP
> >>> announcements, obviously.
> >>
> >> Denys, can you say anything about how these TSPU operate?
> >
> > Denys is, I'm sure, 'lmgtfy'ing me right now but:
> >
> >
> https://therecord.media/academics-russia-deployed-new-technology-to-throttle-twitters-traffic/
> >
> >
> https://en.wikipedia.org/wiki/Internet_censorship_in_Russia#Deep_packet_inspection
> >
> > seems to be the system/device in question.
> There is nothing magical or special in these devices, usual inline DPI
> with IDS / IPS functionality, installed between BRAS and CGNAT.
> Here is specs/description for one of them:
> https://www.rdp.ru/en/products/service-gateway-engine/
> They also sell them abroad. Anybody want to install? (Here must be an
> emoticon that laughs and weeps same time)
>
> >
> >> I believe they at least swallow/stop TCP SYN packets toward some
> >> destinations
> >> (or across a link generally), but I'm curious as to what steps the
> >> devices take,
> >> to be able to judge impact seen as either: "broken gear" or "funky
> >> TPSU doing it's thing"
> They are fully inline, so they can do anything they want, without
> informing ISP.
> For example, make a network engineer lose the rest of his mind in search
> of a network fault,
> while it's "TSPU doing it's thing".
>
> >>
> >> thanks!
> >> -chris
> >>
> >>> And the drills do not mean at all "we will turn off the Internet
> >>> for all
> >>> the clients and see what happens", journalists trivialized it.
> >>> Most likely, they checked the autonomous functioning of specific
> >>> infrastructurally important networks connected to the Internet,
> >>> isolating only them.
> >>> It's not so bad idea in general, if someone find another
> >>> significant bug
> >>> in common software, to be able to isolate important networks from
> >>> the
> >>> internet at the click of a button and buy time for patching
> >>> systems.
>


Re: russian prefixes

2021-07-30 Thread Eric Kuhnke
Does this include the ability to do something like an OOB/serial console,
cabled into DWDM transport systems management interfaces, to 'admin down'
the line facing optical interfaces on routes that go across the Russian
border? How exactly is this "TSPU" implemented?




On Thu, Jul 29, 2021 at 9:08 PM Denys Fedoryshchenko <
nuclear...@nuclearcat.com> wrote:

> On 2021-07-29 20:46, Randy Bush wrote:
> >> Looks like it did shown on news only.
> >
> > :)
> >
> > i wondered
> They have installed devices called "TSPU" on major operators.
> Isolation of specific networks is done without changing BGP
> announcements, obviously.
> And the drills do not mean at all "we will turn off the Internet for all
> the clients and see what happens", journalists trivialized it.
> Most likely, they checked the autonomous functioning of specific
> infrastructurally important networks connected to the Internet,
> isolating only them.
> It's not so bad idea in general, if someone find another significant bug
> in common software, to be able to isolate important networks from the
> internet at the click of a button and buy time for patching systems.
>


Re: T-Mobile RF contact

2021-07-15 Thread Eric Kuhnke
Have you tried the contact information on some of their FCC Part 101 (PTP
microwave) licenses? All public data in the ULS, you can even download the
whole thing (12-14GB pipe delimited CSV file, last I checked).



On Wed, Jul 14, 2021 at 2:43 PM Sean Heskett  wrote:

> I realize this isn’t an RF list but was hoping someone on here could point
> me in the right direction.
>
> Does anyone know how to get in touch with a T-Mobile RF engineer?
>
> Our CBRS network has been receiving heavy interference from what we
> believe is a new T-Mobile site at an American tower facility.
>
> The equipment isn’t registered with the SAS and appears to be operating in
> the part 90 portion of the band 3650-3700mhz as a part 90 device and not a
> part 96 CBRS device.
>
> American tower has been no help other than opening a ticket.
>
> Federated is our SAS vendor and they haven’t been any help either other
> than telling us it’s not in the SAS.
>
> I’ve also done an application search in the FCC auction 105 (CRBS) site,
> but T-mobile must have been bidding under a different name.
>
> Any help is much appreciated,
>
> -Sean Heskett
> 970-846-8065
> --
> Sean Heskett
>
> ZIRKEL
> Internet • WiFi • Phone • TV
> 970-871-8500 x100 - Office
>


Re: Beta Starlink with a slight tree obstruction vs degraded DOCSIS3 last mile

2021-06-30 Thread Eric Kuhnke
Although I did not provide screenshots to the 40 other widely varied
destinations that smokeping system is set up to poll, all of them show
similar 2-3% loss results as to the voip.ms server in Seattle. Additionally
TCP is also dropping packets on the floor. And of course anything UDP is
affected to the point that it's noticeable in voice/video.

This is not a case of the cable ISP introducing some ICMP rate limiting
packet eater but a general degradation for everything.

On Wed, Jun 30, 2021 at 9:58 AM Josh Luthman 
wrote:

> Have you thought about doing a TCP test?  Maybe an HTTP check to a
> website?  That would be better than ICMP, I think, since it would be more
> user like.
>
> Josh Luthman
> 24/7 Help Desk: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
>
> On Tue, Jun 29, 2021 at 9:02 PM Eric Kuhnke  wrote:
>
>> The local cable last mile operator broke something locally, or something
>> degraded (water ingress, bad connectors, who knows) and can't get their act
>> together sufficiently to dispatch a field tech and fix it.
>>
>> On Mon, Jun 28, 2021, 11:03 AM Josh Luthman 
>> wrote:
>>
>>> What happened on June 20/21?  Looks like someone broke something on your
>>> cable link or perhaps an ICMP rate limiting was introduced.
>>>
>>> Josh Luthman
>>> 24/7 Help Desk: 937-552-2340
>>> Direct: 937-552-2343
>>> 1100 Wayne St
>>> Suite 1337
>>> Troy, OH 45373
>>>
>>>
>>> On Mon, Jun 28, 2021 at 10:45 AM Matt Hoppes <
>>> mattli...@rivervalleyinternet.net> wrote:
>>>
>>>> I don't know how you can be embarrassed when you have a pretty solid
>>>> 30ms ping constantly, and Starlink has jitter all over the place and
>>>> spikes as high as 280ms.
>>>>
>>>> I'll take the DOCSIS3 system
>>>>
>>>> On 6/25/21 8:49 PM, Eric Kuhnke wrote:
>>>> > I thought I would post an interesting comparison between a degraded
>>>> > DOCSIS3 link, of a carrier that shall remain nameless to avoid
>>>> > embarrassing anybody, and a starlink CPE with a slight 1/12th tree
>>>> > obstruction in a portion of its view.
>>>> >
>>>> > First two screenshots are the docsis3, to its gateway and to a very
>>>> > reliable hosted asterisk system in Seattle.
>>>> >
>>>> > Second two screenshots are starlink, also to its gateway and to the
>>>> same
>>>> > destination.
>>>> >
>>>> > https://imgur.com/a/OQ5wyDr
>>>> >
>>>>
>>>


Re: Beta Starlink with a slight tree obstruction vs degraded DOCSIS3 last mile

2021-06-29 Thread Eric Kuhnke
The local cable last mile operator broke something locally, or something
degraded (water ingress, bad connectors, who knows) and can't get their act
together sufficiently to dispatch a field tech and fix it.

On Mon, Jun 28, 2021, 11:03 AM Josh Luthman 
wrote:

> What happened on June 20/21?  Looks like someone broke something on your
> cable link or perhaps an ICMP rate limiting was introduced.
>
> Josh Luthman
> 24/7 Help Desk: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
>
> On Mon, Jun 28, 2021 at 10:45 AM Matt Hoppes <
> mattli...@rivervalleyinternet.net> wrote:
>
>> I don't know how you can be embarrassed when you have a pretty solid
>> 30ms ping constantly, and Starlink has jitter all over the place and
>> spikes as high as 280ms.
>>
>> I'll take the DOCSIS3 system
>>
>> On 6/25/21 8:49 PM, Eric Kuhnke wrote:
>> > I thought I would post an interesting comparison between a degraded
>> > DOCSIS3 link, of a carrier that shall remain nameless to avoid
>> > embarrassing anybody, and a starlink CPE with a slight 1/12th tree
>> > obstruction in a portion of its view.
>> >
>> > First two screenshots are the docsis3, to its gateway and to a very
>> > reliable hosted asterisk system in Seattle.
>> >
>> > Second two screenshots are starlink, also to its gateway and to the
>> same
>> > destination.
>> >
>> > https://imgur.com/a/OQ5wyDr
>> >
>>
>


Re: Beta Starlink with a slight tree obstruction vs degraded DOCSIS3 last mile

2021-06-29 Thread Eric Kuhnke
I'd much rather have 0.11 to 0.25% average packet loss over a 3 to 24 hour
period than 2-3%.

The starlink experience is overall superior at present from a subjective
user point of view.

On Mon, Jun 28, 2021, 10:45 AM Matt Hoppes <
mattli...@rivervalleyinternet.net> wrote:

> I don't know how you can be embarrassed when you have a pretty solid
> 30ms ping constantly, and Starlink has jitter all over the place and
> spikes as high as 280ms.
>
> I'll take the DOCSIS3 system
>
> On 6/25/21 8:49 PM, Eric Kuhnke wrote:
> > I thought I would post an interesting comparison between a degraded
> > DOCSIS3 link, of a carrier that shall remain nameless to avoid
> > embarrassing anybody, and a starlink CPE with a slight 1/12th tree
> > obstruction in a portion of its view.
> >
> > First two screenshots are the docsis3, to its gateway and to a very
> > reliable hosted asterisk system in Seattle.
> >
> > Second two screenshots are starlink, also to its gateway and to the same
> > destination.
> >
> > https://imgur.com/a/OQ5wyDr
> >
>


Beta Starlink with a slight tree obstruction vs degraded DOCSIS3 last mile

2021-06-25 Thread Eric Kuhnke
I thought I would post an interesting comparison between a degraded DOCSIS3
link, of a carrier that shall remain nameless to avoid embarrassing
anybody, and a starlink CPE with a slight 1/12th tree obstruction in a
portion of its view.

First two screenshots are the docsis3, to its gateway and to a very
reliable hosted asterisk system in Seattle.

Second two screenshots are starlink, also to its gateway and to the same
destination.

https://imgur.com/a/OQ5wyDr


Re: Google uploading your plain text passwords

2021-06-11 Thread Eric Kuhnke
I think you have only found the tip of the iceberg of things that Chrome
and Google does without your express consent.

On Fri, Jun 11, 2021 at 9:48 AM William Herrin  wrote:

> On Fri, Jun 11, 2021 at 9:38 AM Jan Schaumann via NANOG 
> wrote:
> > William Herrin  wrote:
> > > It turns out that every password I allowed Chrome on Android to
> > > remember, it uploaded to Google. In plain text!!
> >
> > Chrome does not store your passwords in plain text.
> > It encrypts them locally, on e.g. macOS using, I
> > think, a secret stored in the keychain under "Chrome
> > Safe Storage", on Windows using a similar API and
> > secret probably unlocked via your login credentials.
>
> Hi Jan,
>
> I'm fine with Chrome encrypting them locally. That's what I want it to
> do. I'm not at all fine with it uploading them to my Google account. I
> don't want any trace of my non-google passwords present in my google
> account. I'm very very not fine that it happened behind my back
> without my express consent.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>


OSI layer 1 and revisiting labelmakers in the year 2021

2021-06-05 Thread Eric Kuhnke
 I am still using a Dymo 4200 [1] which is generally okay. I am wondering
if anyone or their field tech team has recently changed to a better label
maker in terms of feature set, battery life/charging or label consumable
cost.

Surely there must be something better out there. Strong preference for
QWERTY keyboards, no ABCDE type.

[1]: https://www.dymo.com/en_CA/rhino-industrial-4200-qwy.html


Re: New minimum speed for US broadband connections

2021-05-31 Thread Eric Kuhnke
Perhaps there should be some sort of harsher penalty for ILECs and other
large near-monopoly last mile local carriers that outright lie on their
form 477 data or take significant subsidy funds and then fail to build what
they promised. Numerous states' attorney generals have gone after them on
this matter to varied degrees of success.



On Mon, May 31, 2021 at 5:27 PM Mike Hammett  wrote:

> No one's paying me anything except 15 years of practical experience
> building last mile networks for myself and my clients. I'd imagine that
> while a larger percentage than most venues, a minority of the people on
> this list build last mile networks. Even fewer do so with their own money.
>
> I have a fiber network where I offer gigabit bidirectional to the home.
>
>
> Few people have any sort of grasp of the cost and complexity of building
> what they want.
>
> Raising the the minimal definitions for everyone to what power users
> expect is a foolish venture.
>
>
>
>
> I'm just trying to connect some of you to reality.
>
>
> " Doesn’t matter." Yes, it matters very much so when you're proposing the
> expenditure of my money to meet your unrealistic goals. I'm not against
> raising the definition. I'm not against offering 1G or 10G to the home. I'm
> against you telling people that are perfectly happy with their service that
> it's not good enough for them and then using their and my tax dollars to
> "fix" it.
>
>
>
> I don't disagree that the big ISPs have screwed the pooch many times and
> will do so in perpetuity. These programs often just give those same
> entities that screwed us all for years the money to do it. That's partially
> why they don't spend their own money doing it. They'll wait for Uncle Sam
> to pay them to do it.
>
>
> Muni broadband does suck, but that's another thread for another day.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Andy Ringsmuth" 
> *To: *"NANOG" 
> *Sent: *Monday, May 31, 2021 9:17:17 AM
> *Subject: *Re: New minimum speed for US broadband connections
>
> As much as I enjoy the generally cordial nature of this list, I’m going to
> go out on a limb and say that Mr. Hammett’s mentality on this topic is
> precisely the problem. Arguing against every reasonable proposition we are
> making to increase home broadband speeds.
>
> I’m assuming he’ll disagree. And that’s OK. He’s still wrong.
>
> “People want X. Why?”  - Doesn’t matter. I don’t need a reason for what I
> want. I probably have one, but that reason is my business, not yours.
>
> The big ISPs are, historically and factually, greedy, stingy, and in many
> cases flat-out liars on all this. Taking USF money for DECADES and
> squandering it, for instance. Advertising speeds (I’m looking at you,
> Frontier) they knew full well they couldn’t provide. Charging $40 for
> service on one street and $80 for IDENTICAL service one block away.
> Promising to state governments they would upgrade and then not doing it
> (Charter in New York, anyone?).
>
> Blah blah blah shareholders blah blah blah. DGAF.
>
> Where there is a will, there is a way. The big boys don’t have the will to
> do it. Case after case after case after case after case demonstrates that
> fiber to the home can be done and can be done for a very reasonable cost.
> We read about smaller companies or municipalities every day doing it. And
> then the Big Boys come along and do EVERYTHING they can to stifle
> competition (getting all snarky about pole access, or pouring billions into
> lobbying against muni broadband that could be spent on, oh, I dunno,
> INSTALLING FIBER instead).
>
> “When making policy changes and spending hundreds of billions of dollars,
> you need to have a good reason.” Apply that same thinking to all the
> reasons the Big Boys give for NOT installing fiber or upgrading their
> networks. How many billions have they spent on lobbying and lawsuits to
> stop competition and not install fiber that could have been better spent?
>
> I will go so far as to directly ask:
>
> Mike - who is paying you to lobby so hard against better/faster/more
> reliable home internet?
>
> 
> Andy Ringsmuth
> 5609 Harding Drive
> Lincoln, NE 68521-5831
> (402) 304-0083
> a...@andyring.com
>
> “Better even die free, than to live slaves.” - Frederick Douglas, 1863
>
> > On May 31, 2021, at 8:01 AM, Mike Hammett  wrote:
> >
> > Why is any of that a reasonable position to have? What you're proposing
> is reckless without real, compelling evidence.
> >
> > People want X. Why?
> >
> > When making policy changes and spending hundreds of billions of dollars,
> you need to have a good reason.
> >
> >
> >
> > -
> > Mike Hammett
> > Intelligent Computing Solutions
> > http://www.ics-il.com
> >
> > Midwest-IX
> > http://www.midwest-ix.com
> >
> > From: "Baldur Norddahl" 
> > To: "NANOG" 
> > Sent: Sunday, May 30, 2021 12:53:25 PM
> > Subject: Re: New 

Re: New minimum speed for US broadband connections

2021-05-31 Thread Eric Kuhnke
I think it has been true for many years that:

a) a vast majority of residential gigabit/symmetric customers, or gigabit
asymmetric (docsis3 500-1000 down, 16-50 up) no longer have a device in
their home with a 1000BaseT port on it, or don't know if they do. in some
cases literally the only cat5e cable they have may be a 3' piece from their
cable modem to 'router', and everything else is wifi.

b) don't understand the difference between the service speed delivered via
the wireline connection and demarc/handoff device, whatever that may be,
and their perception of service over the wifi.

c) are unwilling to go through troubleshooting steps requiring them to
directly connect a device to the modem/demarc by 1000BaseT and run speed
tests, possibly necessitating a service call (this can be partially avoided
by the install technician doing a *wired* speed test in front of the
customer at the time of install, from their laptop, and taking a couple of
minutes to explain the difference)

d) may be using badly configured wifi things that stomp on each other,
sometimes provided by the ISP (I have seen set-top boxes from major MSOs
that broadcast a 2x2 MIMO 802.11ac 80 MHz wide channel, now imagine ten of
these all in wood framed houses/condos/townhouses all very close to each
other, in addition to the wifi from the demarc modem/router device). There
are lots of other things in the common consumer environment that render
some environments a CSMA mishmash, like smart TVs, printers and things that
all create their own AP for some reason.

e) may be using their own randomly purchased-from-best-buy wifi "range
extender" devices to create weird forms of mesh networks in their home,
further halving their bandwidth with each half duplex hop.





On Mon, May 31, 2021 at 4:54 PM Tim Burke  wrote:

> This is a good point as well… you can have the largest pipe in the world,
> but in many cases, in-home service issues are caused by crappy CPE.
>
>
>
> Example… my neighborhood has 1000/50 GPON (rather silly to offer such poor
> upload speed, but that’s irrelevant in this case) provided by a local
> outfit, Entouch (now Grande/RCN) as part of HOA dues… Many people in the
> neighborhood do not use it and blame the ISP for offering “mediocre
> service”, simply because there is no fancy CPE included as part of the
> service offering. Yet as soon as you swap that $25 Netgear router
> pre-installed by the home builder’s structured wiring contractor for
> something that’s worth a damn, the pipe is actually usable…
>
>
>
> With that said, if there needs to be regulation on minimum broadband
> speeds, should there be regulation to require home ISPs to provide high-end
> 802.11ax-capable network gear, so the average clueless home user with a
> 1gbps FTTP connection can actually use the service they’re paying for?
>
>
>
> V/r
>
> Tim
>
>
>
> *From:* NANOG  * On Behalf Of *Josh
> Luthman
> *Sent:* Monday, May 31, 2021 12:55 PM
> *To:* NANOG list 
> *Subject:* Re: New minimum speed for US broadband connections
>
>
>
> Was that the fault of the broadband provider or was that the fault of the
> indoor WiFi?  Is it possible the router has so much interference from all
> of the neighbors and everyones using 2.4 GHz?  What if that example had a
> cable connection with 960/40 mbps and they're limited to 5 mbps up because
> of the in house WiFi solution?
>
> Would upping the broadband plan to 1000/1000 fix that problem?
>
>
>
> Josh Luthman
> 24/7 Help Desk: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
>
>
>
>
> On Fri, May 28, 2021 at 2:56 PM Chris Adams  wrote:
>
> Once upon a time, Mike Hammett  said:
> > "Bad connection" measures way more than throughput.
> >
> > What about WFH or telehealth doesn't work on 25/3?
>
> More than one person in a residence, home security systems (camera,
> doorbell, etc.) uploading continuously, and more.
>
> I know multiple people that had issues with slow Internet during the
> last year as two adults were working from home and 1-3 children were
> also schooling from home.  Parents had to arrange work calls around
> their kids classroom time and around each other's work calls, because of
> limited bandwidth.
>
> The time of the Internet being a service largely for consumption of data
> is past.  While school-from-home may be a passing thing as the pandemic
> wanes, it looks like work-from-home (at least part time) is not going to
> go away for a whole lot of people/companies.
>
> --
> Chris Adams 
>
>


Re: New minimum speed for US broadband connections

2021-05-31 Thread Eric Kuhnke
Perhaps you may be unfamiliar with the business model of cities, counties
or local PUDs running the fiber last mile network (at OSI layer 1) and
providing ethernet transport/VLAN handoffs, installing the OLTs and ONTs,
and third party ISPs using that network to provide IP, support, billing and
over-the-top services riding on it. In some of these cases the PUD is also
the entity which operates the last mile electrical distribution network,
and can put fiber on their own poles, which greatly reduces costs and
speeds up deployment.

The customers of the half dozen PUDs in eastern WA which use this business
model are presently enjoying gigabit class residential access at around
$50-75/month and are very happy with it.





On Mon, May 31, 2021 at 10:58 AM Josh Luthman 
wrote:

> I think it's hilarious when a governmental entity funded by the taxpayers
> thinks they have an answer to broadband.  If you're collecting funds from
> customers, why do you need the City of Sherwood to support your network?
>
> Josh Luthman
> 24/7 Help Desk: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
>
> On Fri, May 28, 2021 at 6:22 PM Brandon Price 
> wrote:
>
>> 100/100 minimum for sure.
>>
>> In our small neck of the woods, we are currently doing 250/250 for $45
>> and 1000/1000 for $60 no data caps.
>>
>> We have lost some grants on rural builds because "someone" in the census
>> block claims they provide broadband.. Not hard to put an AP up on a tower
>> and hit the current definition's upload speed.
>>
>> I get a chuckle when the providers tell the customer what they "need"...
>>
>>
>> Brandon Price
>> Senior Network Engineer
>> City of Sherwood, Sherwood Broadband
>>
>>
>>
>> -Original Message-
>> From: NANOG  On
>> Behalf Of Sean Donelan
>> Sent: Thursday, May 27, 2021 5:33 PM
>> To: NANOG Operators' Group 
>> Subject: Re: New minimum speed for US broadband connections
>>
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you are expecting this email and/or
>> know the content is safe.
>>
>>
>> On Thu, 27 May 2021, Lady Benjamin Cannon of Glencoe, ASCE wrote:
>> > At least 100/100.
>> >
>> > We don’t like selling slower than 10g anymore, that’s what I’d start
>> everyone at if I could.
>>
>>
>> At $50/month or less?
>>
>> Maximize number of households of all demographic groups.
>>
>>


Re: Call for academic researchers (Re: New minimum speed for US broadband connections)

2021-05-31 Thread Eric Kuhnke
If one installs smokeping on a raspberry pi using a wired ethernet
interface to a home router, on a DOCSIS3 residential last mile segment, and
copies over a well chosen targets file for things to test, and sets it to a
60s interval, all other settings at default...  It's quite rare to find a
network segment that isn't anywhere from 0.05 to 0.30% packet loss (or
sometimes worse!) to its default gateway over a 24 hour period.

Also very informative is when you see spikes in latency and jitter during
evening peak usage hours. Lots of very basic test methodology can reveal
the nature of oversubscribed contended access mediums. Last-mile 5 GHz band
PtMP WISPs can see exactly the same issues on an overloaded AP.





On Mon, May 31, 2021 at 12:09 PM Denys Fedoryshchenko <
nuclear...@nuclearcat.com> wrote:

> It can't be zero.
> In 1000BaseT specs, BER, 1 in 1*10^10 bits error is considered
> acceptable on each link.
> So it should be defined same way, as acceptable BER.
> And until which point? How to measure?
> Same for bandwidth, port rate can be 1Gbit, ISP speedtest too, but most
> websites 100Kbit.
>
> On 2021-05-31 21:28, Fred Baker wrote:
> > I would add packet loss rate. Should be zero, and if it isn’t, it
> > points to an underlying problem.
> >
> > Sent from my iPad
> >
> >> On May 31, 2021, at 11:01 AM, Josh Luthman
> >>  wrote:
> >
> >> 
> >> I think the latency and bps is going to be the best way to measure
> >> broadband everyone can agree on.  Is there a better way, sure, but
> >> how can you quantify it?
> >>
> >> Josh Luthman
> >> 24/7 Help Desk: 937-552-2340
> >> Direct: 937-552-2343
> >> 1100 Wayne St
> >> Suite 1337
> >> Troy, OH 45373
> >>
> >> On Sun, May 30, 2021 at 7:16 AM Mike Hammett 
> >> wrote:
> >>
> >>> I think that just underscores that the bps of a connection isn't
> >>> the end-all, be-all of connection quality. Yes, I'm sure most of
> >>> us here knew that. However, many of us here still get distracted
> >>> by the bps.
> >>>
> >>> If we can't get it right, how can we expect policy wonks to get it
> >>> right?
> >>>
> >>> -
> >>> Mike Hammett
> >>> Intelligent Computing Solutions
> >>> http://www.ics-il.com
> >>>
> >>> Midwest-IX
> >>> http://www.midwest-ix.com
> >>>
> >>> -
> >>>
> >>> From: "Sean Donelan" 
> >>> To: "NANOG" 
> >>> Sent: Saturday, May 29, 2021 6:25:12 PM
> >>> Subject: Call for academic researchers (Re: New minimum speed for
> >>> US broadband connections)
> >>>
> >>> I thought in the 1990s, we had moved beyond using average bps
> >>> measurements
> >>> for IP congestion collapse.  During the peering battles, some ISPs
> >>> used to
> >>> claim average bps measurements showed no problems.  But in reality
> >>> there
> >>> were massive packet drops, re-transmits and congestive collapse
> >>> which
> >>> didn't show up in simple average bps graphs.
> >>>
> >>> Have any academic researchers done work on what are the real-world
> >>> minimum
> >>> connection requirements for home-schooling, video teams
> >>> applications, job
> >>> interview video calls, and network background application noise?
> >>>
> >>> During the last year, I've been providing volunteer pandemic home
> >>> schooling support for a few primary school teachers in a couple of
> >>>
> >>> different states.  Its been tough for pupils on lifeline service
> >>> (fixed
> >>> or mobile), and some pupils were never reached. I found lifeline
> >>> students
> >>> on mobile (i.e. 3G speeds) had trouble using even audio-only group
> >>> calls,
> >>> and the exam proctoring apps often didn't work at all forcing
> >>> those
> >>> students to fail exams unnecessarily.
> >>>
> >>> In my experience, anecdotal data need some academic researchers,
> >>> pupils
> >>> with at least 5 mbps (real-world measurement) upstream connections
> >>> at
> >>> home didn't seem to have those problems, even though the average
> >>> bps graph
> >>> was less than 1 mbps.
>


Re: Call for academic researchers (Re: New minimum speed for US broadband connections)

2021-05-30 Thread Eric Kuhnke
An interesting question would be to quantify and do statistical analysis on
the following:

Take a set of 1000 or more residential last mile broadband customers on an
effectively more-than-they-can-use connection (symmetric 1Gbps active
ethernet or similar).

On a 60s interval, retrieve SNMP traffic stats from the interfaces towards
the customers' demarcs, or directly from on premises CPEs.

Store that data in influxdb or another lossless time series database for a
multi month period.

Anonymize the data so that no possible information about the
identity/circuit ID/location of the customer can be identified. Perhaps
other than "gigE customer somewhere in North America", representing a semi
random choice of US/Canada domestic market residential broadband users.

Provide that data set to persons who wish to analyze it to see how much/how
bursty the traffic really is, night/day traffic patterns, remote work
traffic patterns during office hours in certain time zones, etc.
Additionally quantify what percentage of users move how much upstream data
or come anywhere near maxing it out in brief bursts (people doing full disk
offsite backups of 8TB HDDs to Backblaze, uploading 4K videos to youtube,
etc).

I at first thought of a concept of doing something similar but with netflow
data on a per CPE basis, but that has a great deal more worrisome privacy
and PII data implications than simply raw bps/s interface data. Presumably
netflow (or data from Kentik, etc) for various CDN traffic and other per-AS
downstream traffic headed to an aggregation router that serves exclusively
a block of a few thousand downstream residential symmetric gigabit
customers would not be a difficult task to sufficiently anonymize.




On Sat, May 29, 2021 at 4:25 PM Sean Donelan  wrote:

>
> I thought in the 1990s, we had moved beyond using average bps measurements
> for IP congestion collapse.  During the peering battles, some ISPs used to
> claim average bps measurements showed no problems.  But in reality there
> were massive packet drops, re-transmits and congestive collapse which
> didn't show up in simple average bps graphs.
>
>
> Have any academic researchers done work on what are the real-world minimum
> connection requirements for home-schooling, video teams applications, job
> interview video calls, and network background application noise?
>
>
> During the last year, I've been providing volunteer pandemic home
> schooling support for a few primary school teachers in a couple of
> different states.  Its been tough for pupils on lifeline service (fixed
> or mobile), and some pupils were never reached. I found lifeline students
> on mobile (i.e. 3G speeds) had trouble using even audio-only group calls,
> and the exam proctoring apps often didn't work at all forcing those
> students to fail exams unnecessarily.
>
> In my experience, anecdotal data need some academic researchers, pupils
> with at least 5 mbps (real-world measurement) upstream connections at
> home didn't seem to have those problems, even though the average bps graph
> was less than 1 mbps.
>
>


Re: link monitoring

2021-04-29 Thread Eric Kuhnke
If I may add one thing I forgot, this post reminded me. In the question I
think it was probably a 100G CWDM4 short distance link. When monitoring a
100G coherent (QPSK, 16QAM, whatever) longer distance link, be absolutely
sure to poll all of the SNMP OIDs for it the same as if it was a point to
point microwave link.

Depending on exactly what line card and optic it is, it may behave somewhat
similarly to a faded or misaligned radio link under conditions related to
degradation of the fiber or the lasers. In particular I'm thinking of
coherent 100G linecards that can switch on the fly between 'low FEC' and
'high FEC' payload vs FEC percentage (much as an ACM-capable 18 or 23 GHz
band radio would), which should absolutely trigger an alarm. And also the
data for FEC decode stress percentage level, etc.

On Thu, Apr 29, 2021 at 2:37 PM Lady Benjamin Cannon of Glencoe, ASCE <
l...@6by7.net> wrote:

> We monitor light levels and FEC values on all links and have thresholds
> for early-warning and PRe-failure analysis.
>
> Short answer is yes we see links lose packets before completely failing
> and for dozens of reasons that’s still a good thing, but you need to
> monitor every part of a resilient network.
>
> Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
> 6x7 Networks & 6x7 Telecom, LLC
> CEO
> l...@6by7.net
> "The only fully end-to-end encrypted global telecommunications company
> in the world.”
>
> FCC License KJ6FJJ
>
> Sent from my iPhone via RFC1149.
>
> On Apr 29, 2021, at 2:32 PM, Eric Kuhnke  wrote:
>
> 
> The Junipers on both sides should have discrete SNMP OIDs that respond
> with a FEC stress value, or FEC error value. See blue highlighted part here
> about FEC. Depending on what version of JunOS you're running the MIB for it
> may or may not exist.
>
>
> https://kb.juniper.net/InfoCenter/index?page=content=KB36074=MX2008=LIST
>
> In other equipment sometimes it's found in a sub-tree of SNMP adjacent to
> optical DOM values. Once you can acquire and poll that value, set it up as
> a custom thing to graph and alert upon certain threshold values in your
> choice of NMS.
>
> Additionally signs of a failing optic may show up in some of the optical
> DOM MIB items you can poll:
> https://mibs.observium.org/mib/JUNIPER-DOM-MIB/
>
> It helps if you have some non-misbehaving similar linecards and optics
> which can be polled during custom graph/OID configuration, to establish a
> baseline 'no problem' value, which if exceeded will trigger whatever
> threshold value you set in your monitoring system.
>
> On Thu, Apr 29, 2021 at 1:40 PM Baldur Norddahl 
> wrote:
>
>> Hello
>>
>> We had a 100G link that started to misbehave and caused the customers to
>> notice bad packet loss. The optical values are just fine but we had packet
>> loss and latency. Interface shows FEC errors on one end and carrier
>> transitions on the other end. But otherwise the link would stay up and our
>> monitor system completely failed to warn about the failure. Had to find the
>> bad link by traceroute (mtr) and observe where packet loss started.
>>
>> The link was between a Juniper MX204 and Juniper ACX5448. Link length 2
>> meters using 2 km single mode SFP modules.
>>
>> What is the best practice to monitor links to avoid this scenarium? What
>> options do we have to do link monitoring? I am investigating BFD but I am
>> unsure if that would have helped the situation.
>>
>> Thanks,
>>
>> Baldur
>>
>>
>>


Re: link monitoring

2021-04-29 Thread Eric Kuhnke
The Junipers on both sides should have discrete SNMP OIDs that respond with
a FEC stress value, or FEC error value. See blue highlighted part here
about FEC. Depending on what version of JunOS you're running the MIB for it
may or may not exist.

https://kb.juniper.net/InfoCenter/index?page=content=KB36074=MX2008=LIST

In other equipment sometimes it's found in a sub-tree of SNMP adjacent to
optical DOM values. Once you can acquire and poll that value, set it up as
a custom thing to graph and alert upon certain threshold values in your
choice of NMS.

Additionally signs of a failing optic may show up in some of the optical
DOM MIB items you can poll: https://mibs.observium.org/mib/JUNIPER-DOM-MIB/

It helps if you have some non-misbehaving similar linecards and optics
which can be polled during custom graph/OID configuration, to establish a
baseline 'no problem' value, which if exceeded will trigger whatever
threshold value you set in your monitoring system.

On Thu, Apr 29, 2021 at 1:40 PM Baldur Norddahl 
wrote:

> Hello
>
> We had a 100G link that started to misbehave and caused the customers to
> notice bad packet loss. The optical values are just fine but we had packet
> loss and latency. Interface shows FEC errors on one end and carrier
> transitions on the other end. But otherwise the link would stay up and our
> monitor system completely failed to warn about the failure. Had to find the
> bad link by traceroute (mtr) and observe where packet loss started.
>
> The link was between a Juniper MX204 and Juniper ACX5448. Link length 2
> meters using 2 km single mode SFP modules.
>
> What is the best practice to monitor links to avoid this scenarium? What
> options do we have to do link monitoring? I am investigating BFD but I am
> unsure if that would have helped the situation.
>
> Thanks,
>
> Baldur
>
>
>


Re: Myanmar internet - something to think about if you're having a bad day

2021-04-28 Thread Eric Kuhnke
None of them are a good option. In the specific case of Pakistan, the
periodic shutdowns and blockages have been 'moderate' enough, if that's an
appropriate word to use, that *most* of the time, Telenor's customers have
ordinary Internet service. Over the long run it is probably a benefit that
its customers have their LTE data services.

Within that specific example I should also note that there has been very
little effort put on a nation-wide scale to implement technology which can
do DPI and drop/blackholing of VPN traffic. Even though the Internet
traffic for the country runs through a few choke points, there does not
appear to be government-operated technical capability or the budget to
implement something on the scale of the great firewall.

There's plenty of non technical teenagers in Pakistan with VPN clients on
their phone or laptop who seem perfectly capable of using a VPN to watch
Youtube or access Twitter and other social media, during the periods of
time that the government orders things to be blocked.

Along with all feasible attempts at lobbying, I would propose a 4th
alternate to the scenarios outlined, which is to provide funding and
financial support (from a telecom's headquarters in Europe or the USA) for
civil society institutions and non-profits related to bypassing Internet
censorship, and lobbying against it. Such as the EFF, funding for the tor
project, supporting the work of various GPL/BSD licensed VPN technologies
(openvpn, wireguard, etc) and their continuing development, etc.




On Wed, Apr 28, 2021 at 11:03 AM Christopher Morrow 
wrote:

> (I'm sure i'll regret this, but...)
>
> On Wed, Apr 28, 2021 at 1:48 PM Eric Kuhnke  wrote:
>
>> It should be noted that Telenor has been one of the nationwide license
>> holders for 3GPP cellular bands in Pakistan for a long time, and has
>> encountered the same issues with regional network shutdowns, and government
>> orders to block certain netblocks or services.
>>
>> Not to the same extent as what's going on right now in Myanmar, but
>> absolutely it meets the definition of what a (western European, North
>> American) person would consider to be unconscionable and unwarranted
>> government Internet censorship and interference with telecoms.
>>
>>>
>>>
> So, what would be the correct set of actions here (for a company)?
>
> it sounds like some version of the proposal is:
>   "Pull up stakes, stop offering services in places that may/do impose
> 'draconian' methods of 'censorship'"
>  (note intentionally quoted draconian/censorship - I don't mean/want
> to put a value on those words)
>
> or perhaps:
>   "Lobby the gov't(s) in these situations to NOT do the things they keep
> doing"
>
> or finally:
>   "refuse to comply with requests/orders from govt(s) to do these things"
>
> I think the last is 'impractical', I expect the 1st is also a tough pill
> to swallow for a large multinational telcom... the middle may already be
> being done, but is unlikely to help.
>
> So, aside from: you ought not do that! from
> the sidelines... what should a responsible Corpo do?
>


Re: Myanmar internet - something to think about if you're having a bad day

2021-04-28 Thread Eric Kuhnke
It should be noted that Telenor has been one of the nationwide license
holders for 3GPP cellular bands in Pakistan for a long time, and has
encountered the same issues with regional network shutdowns, and government
orders to block certain netblocks or services.

Not to the same extent as what's going on right now in Myanmar, but
absolutely it meets the definition of what a (western European, North
American) person would consider to be unconscionable and unwarranted
government Internet censorship and interference with telecoms.

They've shown no signs of pulling out of Pakistan or making operational
changes as a result of this, over the past ten years. My personal opinion
is that Telenor (PK) has weighed the risks, and judged that they possess
neither the political capital, influence or leverage to ignore the
government's occasional Internet shutdown orders.

"Westerners" might be surprised to learn the extent that some of the major
international/developing-nation specialist 3GPP carriers seem to be quite
fine with operating in non-democratic regimes and bending their telecom's
operational policies to suit local laws. In particular I'm thinking of the
above Telenor example, but also MTN in many nations in Africa, Orange, and
Airtel, in their operations in many different nations.

Then on the other hand you have telecom entities which originate from
highly censored political systems, one of the other 3GPP band operators in
Pakistan (Zong) is owned by a Chinese domestic telecom company.







On Mon, Apr 26, 2021 at 11:51 PM Bjørn Mork  wrote:

> scott  writes:
>
> > Telenor and Ooredoo, it's time to do the right thing.
>
> Wrt Telenor, please see the info posted at
>
> https://www.telenor.com/sustainability/responsible-business/human-rights/mitigate/human-rights-in-myanmar/directives-from-authorities-in-myanmar-february-2021/
>
>
> Bjørn
>


Re: FCC fines for unauthorized carrier changes and consumer billing

2021-04-23 Thread Eric Kuhnke
Did the FCC ever collect its $50 million from "Sandwich Isles
Telecommunications" for blatant fraud?  At this scale I wonder how or why
certain people are not in federal prison.

https://www.google.com/search?channel=fs=fcc+sandwich+isles

https://docs.fcc.gov/public/attachments/FCC-20-131A1_Rcd.pdf

V. ORDERING CLAUSES69. Accordingly,IT IS ORDEREDthat Sandwich Isles
Communications, Inc., Waimana Enterprises, Inc., and Albert S.N. Hee,
pursuant to section 220(d) of the Communications Act of 1934, as amended,
and section 1.80 of the Commission’s rules,293ARE JOINTLY AND SEVERALLY LIABLE
FOR A MONETARY FORFEITUREin the amount of forty-nine million, five hundred
and ninety-eight thousand, and four hundred and forty-eight dollars
($49,598,448) for violating the Act and the Commission’s rules.70. Payment
of the forfeiture shall be made in the manner provided for in section 1.80
of the Commission’s rules within thirty (30) calendar days after the release
of this Forfeiture Order.29

On Fri, Apr 23, 2021 at 8:44 AM Sean Donelan  wrote:

>
> The FCC has a poor record of actually collecting money from Notices of
> Apparent Liability (i.e. fines).  There are flaws in the FCC notification
> rules, but it does have some rules requiring indpendent verification of
> carrier changes.
>
>
>
> FCC Fines Tele Circuit $4,145,000 for Cramming & Slamming Violations
>
>
> https://www.fcc.gov/document/fcc-fines-tele-circuit-4145000-cramming-slamming-violations-0
>
> FCC fines Tele Circuit Network Corporation $4,145,000 for switching
> consumers from their preferred carrier to Tele Circuit without permission
> and adding unauthorized charges to consumers' bill
>
> In this Order, the Federal Communications Commission (FCC or Commission)
> adopts the findings in the Notice of Apparent Liability (Tele Circuit
> Notice or Notice) that Tele Circuit Network Corporation (Tele Circuit or
> Company) engaged in slamming and cramming, made misrepresentations to
> consumers, and violated a Commission order by failing to produce certain
> information and documents relating to the Company’s business practices.
> The Company’s misconduct  harmed elderly and infirm consumers, in some
> cases leaving them without telephone service for extended periods of
> time—with Tele Circuit refusing to reinstate service until the crammed
> charges were paid in full. These practices violated sections 201(b) and
> 258 of the Communications Act of 1934, as amended (the Act), and section
> 64.1120 of the Commission’s rules. After reviewing Tele Circuit’s response
> to the Notice, we decline to find that the Company violated section
> 1.17(a)(2) of the Commission’s rules and reduce the proposed penalty by
> $1,178,322, and therefore impose a forfeiture of $4,145,000.
>
>
>
> [...]
> In particular, Tele Circuit did not provide proof that the complainants
> listed in the LOI authorized Tele Circuit to switch their long distance
> carrier. In response to the LOI, Tele Circuit did produce some
> third-party verification recordings,31 which are supposed to provide
> evidence that customers assented to changing their long distance service
> from their existing carriers to Tele Circuit. However, some
> complainants who listened to the recordings alleged that the third-party
> verifications were falsified. In all, the Bureau reviewed more than 100
> written consumer complaints, contacted numerous complainants, obtained
> substantial documentary evidence (including copies of consumer telephone
> bills), listened to third-partyverification recordings, and received data
> from consumers’ carriers.
>
> [...]
>   Tele Circuit switched the telephone service of 24 consumers without
> verified authorization to do so, in violation of section 258 of the Act
> and section 64.1120 of the Commission’s rules.
>
> [...]
>


Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

2021-04-22 Thread Eric Kuhnke
I sincerely doubt that any actual *law* could be enforced against an ISP
which is a legal entity in one location, yet has multiple discrete /23 or
/24 blocks and without any obfuscation choose to announce them from
multiple different geographic locations. Configurations where an AS has
multiple islands of service which are not linked together by an internal
transport network are not that rare these days (see prior discussion about
merits vs risks of filtering out your own netblock at your BGP edge). If
anyone is aware of any case law precedent for such a prosecution it would
be interesting to see citations.

The only scenario in which I could see a legal penalty being imposed on
some ISP, is if it fails to publish an accurate record of its corporate
name, address and contact info for its ARIN, RIPE, AFRINIC, APNIC, etc
entity listing as a corporation. Obviously you can't and shouldn't attempt
to obfuscate where you're headquartered, and you need to be able to prove
your legal entity bona fides to ARIN or RIPE anyways in order to maintain
registration.

As to whether third party content sources might refuse to serve content to
an ISP announcing blocks in weird places, an ISP tunneling a customer's
traffic from one location to another, or misunderstanding their geolocation
(Hulu in the US is a fine example of this, its regional content is broken
on Starlink right now because of a misunderstanding of how the cgnat
traffic meets the real Internet), that's not a law...

That's an arbitrary private choice of some OTT video content provider or
CDN to serve or not serve certain licenses of copyrighted content based on
what it thinks is geolocation data. Another example would be the content
you see on Canadian domestic netflix vs US domestic netflix.



On Wed, Apr 21, 2021 at 12:22 PM William Herrin  wrote:

> On Wed, Apr 21, 2021 at 11:58 AM nanoguser100 via NANOG 
> wrote:
> > I wanted to get the communities' opinion on this.
> >
> > Increasingly I have run into 'niche needs' where a client has a few
> users in a country we don't have a POP, say Estonia.  This is 'mainly' for
> localization but also in some cases for compliance (some sites REQUIRE an
> Estonian IP).  With that being said is it common practice to 'fake'
> Geolocations?  In this case the user legitimately lives in Estonia, they
> just happen to be using our cloud service in Germany.
>
> If the endpoint (e.g. web server) is physically located in Germany and
> you're helping a client misrepresent that it's located in Estonia in
> order to evade a legal requirement that it be located in Estonia then
> you've made yourself a party to criminal fraud. Do I really need to
> explain how bad an idea that is?
>
> If the service is a VPN relay for addresses which are actually being
> used in Estonia then what's the problem? You're just a transit for
> those IPs. Report the location where the endpoints are, not the
> transits.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>


Re: Malicious SS7 activity and why SMS should never by used for 2FA

2021-04-19 Thread Eric Kuhnke
I would start with cellular carriers and nations that intentionally take
steps to block anything VoIP as a threat to their revenue model. Or because
anything vpn/ipsec/whatever related is a threat to local Internet
censorship laws.

Plenty of places the sort of ipsec tunnel used for vowifi is not usable on
whatever consumer-grade cellular or local broadband ISP you might find.




On Sun, Apr 18, 2021 at 11:11 PM Mark Tinka  wrote:

>
>
> On 4/19/21 06:50, Julien Goodwin wrote:
>
> > This is already probably past the point of being on topic here, but you
> > tickled my personal favorite one of these.
> >
> > My airline of choice (Qantas) has mandatory SMS second factor, after
> > perhaps a mobile carrier requiring it for support one of the most
> > facepalm-worthy uses of SMS 2FA I've seen.
>
> It's interesting that VoWiFi is meant to support both voice and SMS,
> domestically and when one travels. So I'm curious why SMS's would not
> work with VoWiFi when traveling to a country that won't deliver your
> SMS's generically. After all, VoWiFi is, as far as I understand it,
> meant to be a direct IP tunnel back to your home network for both
> billing and service.
>
> If anyone has more clue about this on the list, I'd really like to know,
> as my mobile service providers hardly know what I'm talking about when I
> ring them up with questions.
>
> Mark.
>
>


Re: Malicious SS7 activity and why SMS should never by used for 2FA

2021-04-18 Thread Eric Kuhnke
One of my main problems with SMS 2FA from a usability standpoint, aside
from SS7 hijacks and security problems, is that it cannot be relied upon
when traveling in many international locations. I have been *so many places*
where there is just about zero chance of my T-Mobile SIM successfully
roaming onto the local network and receiving SMS at my US or Canadian
number successfully.

What am I supposed to do, take the SIM out of my phone, put it in a burner
and give it to a trusted family member in North America, just for the
purpose of receiving SMS 2FA codes (which I then have to call them and get
the code from manually each time), before going somewhere weird?

In the pre covid19 era when people were actually traveling places, imagine
you've had reason to go somewhere weird and need access to a thing (such as
your online banking, perhaps?) protected by SMS 2FA, but you have
absolutely no way of receiving the SMS where you're presently located...

Many of the people designing SMS 2FA systems used by people with
accounts/services in the US 50 states and Canada seem to assume that their
domestic customers will forever remain in a domestic location.




On Sun, Apr 18, 2021 at 5:44 AM Mark Tinka  wrote:

>
>
> On 4/18/21 05:18, Mel Beckman wrote:
>
> > No, every SMS 2FA should be prohibited by regulatory certifications.
> > The telcos had years to secure SMS. They did nothing. The plethora of
> > well-secured commercial 2FA authentication tokens, many of them free,
> > should be a mandatory replacement for 2FA in every security governance
> > regime, such as PCI, financial account access, government web portals,
> > etc.
>
> While I agree that SMS is insecure at the moment, I think there still
> needs to be a mechanism that does not rely on the presence of an
> Internet connection. One may not be able to have access to the Internet
> for a number of reasons (traveling, coverage, outage, device, money,
> e.t.c.), and a fallback needs to be available to authenticate.
>
> I know some companies have been pushing for voice authentication for
> their services through a phone call, in lieu of SMS or DTMF-based PIN's.
>
> We need something that works at the lowest common denominator as well,
> because as available as the Internet is worldwide, it's not yet at a
> level that one would consider "basic access".
>
> Mark.
>


Malicious SS7 activity and why SMS should never by used for 2FA

2021-04-17 Thread Eric Kuhnke
https://lucky225.medium.com/its-time-to-stop-using-sms-for-anything-203c41361c80

https://krebsonsecurity.com/2021/03/can-we-stop-pretending-sms-is-secure-now/


Anecdotal: With the prior consent of the DID holders, I have successfully
ported peoples' numbers using nothing more than a JPG scan of a signature
that looks like an illegible 150 dpi black and white blob, pasted in an
image editor on top of a generic looking 'phone bill'.


Re: OOB management options @ 60 Hudson & 1 Summer

2021-04-15 Thread Eric Kuhnke
Before getting rid of the cellular based OOB, look into some more detail
about exactly what LTE modems are in those. I've seen some remarkable
results from equipment using the 600/700 bands (tmobile, verizon) for
getting signal into deeply buried concrete structures. There's a lot of
different types and capabilities of cellular data modems on the market.




On Thu, Apr 15, 2021 at 3:15 PM Matthew Crocker 
wrote:

>
>
> I have routers in both 60 Hudson St & 1 Summer St and I’m looking for some
> low cost bandwidth options for out of band management.  Currently I have
> Opengear boxes at each site with cell modems but they don’t work too well.
> I either need to replace them with new cell based devices or find a
> wireless/ethernet bandwidth option.   I only need a couple serial ports and
> ethernet for when everything breaks.
>
>
>
> I’m in DR space @ 60 Hudson and the Markeley MMR @ 1 Summer
>
>
>
> I’m surprised OOB bandwidth isn’t a feature for colocation providers.
>
>
>
> Thanks
>
>
>


Re: My First BGP-Hijacking Explanation

2021-04-08 Thread Eric Kuhnke
If one follows the social media accounts of the Pakistan version of the
FCC, nowadays they're just banning anything they find insulting or illegal
in the local legal system, and ordering ISPs to null route big chunks of IP
space.

As an anecdotal data point, the only effect this has had is teaching random
14 year olds how to use ordinary consumer grade VPNs, which work just fine.

https://www.pta.gov.pk/en



On Thu, Apr 8, 2021 at 9:52 AM Jay R. Ashworth  wrote:

> Sam 'Half As Interesting' Denby actually did a surprisingly good job
> explaining
> this for the average only-vaguely-technical viewer...
>
>https://www.youtube.com/watch?v=K9gnRs33NOk
>
> [ For all the bad dad jokes he tells on HAI, he's got really good research
>   skills/staff, and his long-form stuff on Wendover Productions is
> excellent ]
>
>
> Cheers,
> -- jra
>
> --
> Jay R. Ashworth  Baylink
> j...@baylink.com
> Designer The Things I Think   RFC
> 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land
> Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647
> 1274
>


Re: 10 years from now... (was: internet futures)

2021-03-29 Thread Eric Kuhnke
I am doing this right now. A starlink CPE is a fairly ordinary DIA link
that exists in cgnat space from the perspective of whatever router you plug
into it. The starlink indoor 'router' is optional.

Whatever you plug into the high power PoE injector will be given a DHCP
lease and a default route out to the world. People who don't want to DIY a
dual-WAN solution with their own Linux box or pfsense or similar can use
things like peplink routers.

In difficult to reach places in the world I can see starlink with a
low-bandwidth traditional VSAT link as backup/failover as a fairly common
configuration. Or starlink as primary and local HSPA+/HSDPA/LTE (whatever
3GPP related) as a failover.



On Mon, Mar 29, 2021 at 12:37 PM Matt Erculiani 
wrote:

> I wouldn't be the least bit surprised if anyone out there was trying to
> mix their StarLink kit and existing broadband service to optimize
> performance and/or add redundancy though.
>
> The underlying technologies will change, but what people try to do with
> them will remain relatively unchanged.
>
> Back 20 years ago people were talking about their Frame Relay P2P
> services, now they talk about their Ethernet P2P services.
>
> -Matt
>
> On Mon, Mar 29, 2021 at 1:10 PM Aaron C. de Bruyn 
> wrote:
>
>> On Mon, Mar 29, 2021 at 11:39 AM Matt Erculiani 
>> wrote:
>>
>>> I think the best way to think about what 10 years from now will look
>>> like is to compare 10 years ago to the present:
>>> https://mailman.nanog.org/pipermail/nanog/2011-April/thread.html
>>>
>>
>> Multi-homing your DSL connection?
>> I can't wait to multi-home my 10x10 array of StarLink satellites in a few
>> years...
>>
>> -A
>>
>
>
> --
> Matt Erculiani
> ERCUL-ARIN
>


Re: 10 years from now...

2021-03-29 Thread Eric Kuhnke
The present architecture is logically a bent pipe, where a moving satellite
(preferably more than one, for make before break handoff function) needs to
be simultaneously in view of a starlink earth station and the CPE.

In the long term this may not be an absolute. Ten beta test satellites that
were launched into a near polar orbit a few months back have test equipment
on them for inter-satellite laser links.

Satellite to Satellite relay by Ka-band for low bandwidth stuff has been
demonstrated and in production for a long time. For quite a while the only
two Iridium earth stations existed in Arizona and Hawaii. A handheld phone
call or SMS from an Iridium terminal anywhere in the world would make its
way through the satellite network to those locations. Statements by Musk
indicate that they have a strong desire for a long term ability to do
something like that, but optically and with much higher throughput. I would
also be surprised if Kuiper does not have similar intentions.



On Sun, Mar 28, 2021 at 9:05 PM  wrote:

> This is a fascinating discussion.
>
> Also keep in mind that starlink satellites need many earth stations to
> downlink customer packets and provide internet transit. There are over
> 50 satellite earth stations in the US already.
>
> Here is a great google map of the current ground stations based on FCC
> license data:
>
> https://www.google.com/maps/@36.6554578,-111.9151229,4.5z/data=!4m2!6m1!1s1H1x8jZs8vfjy60TvKgpbYs_grargieVw
>
> -Keith
>
> Denys Fedoryshchenko wrote on 3/28/2021 6:58 PM:
>
> > No need for all that fancy RF tools.
> > Moreover, detecting >10Ghz transmission is not such an easy task.
> > The beam is most likely narrow enough to be difficult to detect.
> >
> > But, (for example) it's enough to visit from foreign IPs some local
> > website,
> > to have cookie set: SATELLITE_USER=xyz
> > Then when person use local connection and visit same website, this cookie
> > will send law enforcement hint.
> > And there are many more automated, software-based ways to detect that a
> > device has been connected via satellite in past.
> >
> > Not to mention the fact that any attempt to provide services illegally
> > is pandora box.
> > At least it may end up with the fact that the country will start
> > jamming uplink
> > frequencies, which will affect the service in whole region.
> > And in the worst case, it will give reason to use anti-satellite weapons.
> >
> >
> > On 2021-03-29 03:23, Eric Kuhnke wrote:
> >> I would also concur that the likelihood of Starlink (or a Oneweb, or
> >> Kuiper) terminal being used successfully to bypass the GFW or similar
> >> serious Internet censorship, in an authoritarian environment, is
> >> probably low. This is because:
> >>
> >> a) It has to transmit in known bands.
> >>
> >> b) It has to be located in a location with a very good, clear view of
> >> the sky in all directions (even a single tree obstruction in one
> >> section of the sky, relative to where the antenna is mounted will
> >> cause packet loss/periodic issues on a starlink beta terminal right
> >> now). Visually identifying the terminal would not be hard.
> >>
> >> c) Portable spectrum analyzers capable of up to 30 GHz are not nearly
> >> as expensive as they used to be. They also have much better GUIs and
> >> visualization tools than what was available 6-10 years ago.
> >>
> >> d) You could successfully train local law enforcement to use these
> >> sort of portable spectrum analyzers in a one-day, 8-hour training
> >> course.
> >>
> >> e) The equipment would have to be smuggled into the country
> >>
> >> f) Many people such as in a location like Iran may lack access to a
> >> standard payment system for the services (the percentage of Iranians
> >> with access to buy things online with visa/mastercard/american express
> >> or similar is quite low).
> >>
> >> There are already plenty of places in the world where if you set up a
> >> 1.2, 1.8 or 2.4 meter C, Ku or Ka band VSAT terminal using some sort
> >> of geostationary based services, without appropriate government
> >> "licenses", men with guns will come to dismantle it and arrest you.
> >>
> >> I am not saying it is an impossible problem to solve, but any system
> >> intended for that sort of purpose would have to be designed for
> >> circumvention, and not a consumer/COTS adaptation of an off the shelf
> >> starlink terminal.
> >>
> >> On Sat, Mar 27, 2021 at 8:31 PM na...@jima.us  wrote:
> &

Re: 10 years from now... (was: internet futures)

2021-03-28 Thread Eric Kuhnke
The US State Department is already a large customer for dedicated
transponder capacity, in C-band hemispheric and Ku beams in some weird
places in the world.

As a randomly chosen example if you take a look at the roof of the UK
embassy in Kabul, there's a nice 4 meter size Andrew/Commscope compact
cassegrain dish up there. Pretty typical thing already for embassies, the
big difference would be that that they'll have more market options for
high-throughput service.


On Sun, Mar 28, 2021 at 10:18 PM Mark Tinka  wrote:

>
>
> On 3/29/21 02:23, Eric Kuhnke wrote:
>
> >
> > I am not saying it is an impossible problem to solve, but any system
> > intended for that sort of purpose would have to be designed for
> > circumvention, and not a consumer/COTS adaptation of an off the shelf
> > starlink terminal.
>
> Behind the walls of an embassy, perhaps :-).
>
> Mark.
>


Re: 10 years from now... (was: internet futures)

2021-03-28 Thread Eric Kuhnke
By definition and orbital mechanics, low earth orbit things don't "park"
anywhere. There's an equal number of starlink satellites over Mongolia
right now as there are over the same latitude locations in the US and
Canada.

https://satellitemap.space/

This also becomes intuitive once one plays Kerbal Space Program for a few
hours...




On Sun, Mar 28, 2021 at 9:16 PM Keith Medcalf  wrote:

>
> Net to mention, of course, that the Low Orbit constellation would need to
> be "parked" over China (or where-ever you want to access it).  I am quite
> sure that "shooting down" such low orbit stationary vehicles would not be
> too difficult.  And if they are owned by an adversary who has no permission
> to fly those objects in your airspace, I doubt that anything could be done
> about it.
>
> If I owned a bunch of low orbit satellites costing millions of dollars
> each, I would not want to "park" them in low orbit over a hostile territory.
>
> Then you also have the requirement to maintain positive control over the
> satellites which, unlike those in geostationary orbits, need to be under
> continual thrust and control in order to stay "parked".  I doubt that any
> "private" (ie, non-Government organization) could afford to do so without
> the cooperation of the state over which they are parking.
>
> --
> Be decisive.  Make a decision, right or wrong.  The road of life is paved
> with flat squirrels who could not make a decision.
>
> >-Original Message-
> >From: NANOG  On Behalf Of
> >Eric Kuhnke
> >Sent: Sunday, 28 March, 2021 18:24
> >To: na...@jima.us
> >Cc: nanog@nanog.org
> >Subject: Re: 10 years from now... (was: internet futures)
> >
> >I would also concur that the likelihood of Starlink (or a Oneweb, or
> >Kuiper) terminal being used successfully to bypass the GFW or similar
> >serious Internet censorship, in an authoritarian environment, is probably
> >low. This is because:
> >
> >a) It has to transmit in known bands.
> >
> >
> >b) It has to be located in a location with a very good, clear view of the
> >sky in all directions (even a single tree obstruction in one section of
> >the sky, relative to where the antenna is mounted will cause packet
> >loss/periodic issues on a starlink beta terminal right now). Visually
> >identifying the terminal would not be hard.
> >
> >
> >c) Portable spectrum analyzers capable of up to 30 GHz are not nearly as
> >expensive as they used to be. They also have much better GUIs and
> >visualization tools than what was available 6-10 years ago.
> >
> >
> >d) You could successfully train local law enforcement to use these sort
> >of portable spectrum analyzers in a one-day, 8-hour training course.
> >
> >
> >e) The equipment would have to be smuggled into the country
> >
> >f) Many people such as in a location like Iran may lack access to a
> >standard payment system for the services (the percentage of Iranians with
> >access to buy things online with visa/mastercard/american express or
> >similar is quite low).
> >
> >
> >
> >There are already plenty of places in the world where if you set up a
> >1.2, 1.8 or 2.4 meter C, Ku or Ka band VSAT terminal using some sort of
> >geostationary based services, without appropriate government "licenses",
> >men with guns will come to dismantle it and arrest you.
> >
> >I am not saying it is an impossible problem to solve, but any system
> >intended for that sort of purpose would have to be designed for
> >circumvention, and not a consumer/COTS adaptation of an off the shelf
> >starlink terminal.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >On Sat, Mar 27, 2021 at 8:31 PM na...@jima.us <mailto:na...@jima.us>
> >mailto:na...@jima.us> > wrote:
> >
> >
> >   Please don't forget that RF sources can be tracked down by even
> >minimally-well-equipped adversaries.
> >
> >   - Jima
> >
> >   -Original Message-
> >   From: NANOG  ><mailto:jima...@nanog.org> > On Behalf Of scott
> >   Sent: Saturday, March 27, 2021 19:36
> >   To: nanog@nanog.org <mailto:nanog@nanog.org>
> >   Subject: Re: 10 years from now... (was: internet futures)
> >
> >
> >   On 3/26/2021 9:42 AM, Michael Thomas wrote:
> >   > LEO internet providers will be coming online which might make a
> >   > difference in the corners of the world where it's hard to get
> >access,
> >   > but will it allow internet access to parachute in behind the
> Great
> >   > Firewall?
> >   
> >   > How do the Chinas of the world intend to deal with the Great
> >Firewall
> >   > implications?
> >
> >
> >   This is what I hope will change in the next 10 years.  "Turning off
> >the
> >   internet" will be harder and harder for folks suppressing others,
> >many
> >   times violently, and hiding it from everyone else.  A small-ish
> >antenna
> >   easily hidden would be necessary.
> >
> >   scott
> >
> >
> >
> >
>
>
>
>
>


Re: 10 years from now... (was: internet futures)

2021-03-28 Thread Eric Kuhnke
I would also concur that the likelihood of Starlink (or a Oneweb, or
Kuiper) terminal being used successfully to bypass the GFW or similar
serious Internet censorship, in an authoritarian environment, is probably
low. This is because:

a) It has to transmit in known bands.

b) It has to be located in a location with a very good, clear view of the
sky in all directions (even a single tree obstruction in one section of the
sky, relative to where the antenna is mounted will cause packet
loss/periodic issues on a starlink beta terminal right now). Visually
identifying the terminal would not be hard.

c) Portable spectrum analyzers capable of up to 30 GHz are not nearly as
expensive as they used to be. They also have much better GUIs and
visualization tools than what was available 6-10 years ago.

d) You could successfully train local law enforcement to use these sort of
portable spectrum analyzers in a one-day, 8-hour training course.

e) The equipment would have to be smuggled into the country

f) Many people such as in a location like Iran may lack access to a
standard payment system for the services (the percentage of Iranians with
access to buy things online with visa/mastercard/american express or
similar is quite low).


There are already plenty of places in the world where if you set up a 1.2,
1.8 or 2.4 meter C, Ku or Ka band VSAT terminal using some sort of
geostationary based services, without appropriate government "licenses",
men with guns will come to dismantle it and arrest you.

I am not saying it is an impossible problem to solve, but any system
intended for that sort of purpose would have to be designed for
circumvention, and not a consumer/COTS adaptation of an off the shelf
starlink terminal.









On Sat, Mar 27, 2021 at 8:31 PM na...@jima.us  wrote:

> Please don't forget that RF sources can be tracked down by even
> minimally-well-equipped adversaries.
>
> - Jima
>
> -Original Message-
> From: NANOG  On Behalf Of scott
> Sent: Saturday, March 27, 2021 19:36
> To: nanog@nanog.org
> Subject: Re: 10 years from now... (was: internet futures)
>
>
> On 3/26/2021 9:42 AM, Michael Thomas wrote:
> > LEO internet providers will be coming online which might make a
> > difference in the corners of the world where it's hard to get access,
> > but will it allow internet access to parachute in behind the Great
> > Firewall?
> 
> > How do the Chinas of the world intend to deal with the Great Firewall
> > implications?
>
>
> This is what I hope will change in the next 10 years.  "Turning off the
> internet" will be harder and harder for folks suppressing others, many
> times violently, and hiding it from everyone else.  A small-ish antenna
> easily hidden would be necessary.
>
> scott
>
>
>
>


Re: IP reputation lookup (prefix not single IP)

2021-03-25 Thread Eric Kuhnke
Nothing more than anecdotal evidence, when I last looked into the
externally available network details on a number of low-budget VPS hosting
companies...   I would say that if anything, a person who really knows what
they're doing operating a properly MX, will face more difficulties today
than they did 3, 5 or 7 years ago operating the system in the same
netblocks as IPs which have been previously abused.

For obvious reasons the IP reputation systems and antispam tools at the
biggest destinations (gsuite/gmail, office365, etc) are treated as closely
guarded proprietary data.

My personal theory on a whole /24 acquiring a poor reputation, is that it
does have some correlation with the density of random $5/mo VPS customers
and the turnover of different customers between the same small group of
IPs. And exactly how many misconfigured smtp sources have existed in that
block within some previous range of time, how much spam has been
reported/flagged, etc.



On Thu, Mar 25, 2021 at 8:28 PM Randy Bush  wrote:

> > I think you will find that most SMTP / anti-spam focused RBL tools
> > give a very similar result for IP reputation on a per /24 block basis
>
> got cites?  this got me curious the other day.
>
> randy
>
> ---
> ra...@psg.com
> `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
> signatures are back, thanks to dmarc header butchery
>


Re: IP reputation lookup (prefix not single IP)

2021-03-25 Thread Eric Kuhnke
I think you will find that most SMTP / anti-spam focused RBL tools give a
very similar result for IP reputation on a per /24 block basis, for any
randomly chosen IP in the block, particularly where the /24 in question has
previously been used and announced by a dedicated server/VPS/virtual server
hosting company.


On Thu, Mar 25, 2021 at 9:26 AM vom513  wrote:

> Hello all,
>
> I’ve seen other folks asking the same/similar question in the past, but I
> don’t recall seeing more than a few options out there to *try* to suss this
> out.  Use case is someone I’m working with looking to buy a v4 block from a
> broker.
>
> So far I’ve checked Talos and Sorbs (both allow a prefix lookup).  Most of
> the other RBL/multi-RBL sites want a single IP (the use case being email of
> course).  I won’t abuse their service by trying to lookup each single IP in
> the block...
>
> Could anyone share anything/anywhere else I might look to get crumbs of
> info on a given preifx ?
>
> Thanks.


Re: OT: Re: Younger generations preferring social media(esque) interactions.

2021-03-23 Thread Eric Kuhnke
For persons considering mattermost, I would recommend instead looking into
a self hosted Matrix + Synapse (matrix protocol server daemon) setup, which
is fully open source.

https://en.wikipedia.org/wiki/Matrix_(protocol)

Element is one typical GUI client for it, but there are many options.
https://en.wikipedia.org/wiki/Element_(software)



On Mon, Mar 22, 2021 at 11:45 PM Cynthia Revström via NANOG 
wrote:

> I have used Mattermost but iirc it has very limited access control unless
> you have the enterprise version and generally doesn't seem to be made for
> public groups.
>
> This in addition to probably the main problem, it will have higher barrier
> to entry especially for those already using Discord for other purposes.
>
> -Cynthia
>
> On Tue, Mar 23, 2021, 07:38 Karl Auer  wrote:
>
>> On Tue, 2021-03-23 at 07:22 +0100, Cynthia Revström via NANOG wrote:
>> > Because Discord is proprietary, you can't host your own instance
>>
>> For reasons of confidentiality we implemented a MatterMost server for
>> company use. It is free, works well, runs on our own servers. It lacks
>> some of the bells and whistles that Discord has (in particular it has
>> no audio or screensharing), but as an instant messaging platform for us
>> it's worked very well indeed.
>>
>>
>> Regards, K.
>>
>> --
>> ~~~
>> Karl Auer (ka...@biplane.com.au)
>> http://www.biplane.com.au/kauer
>>
>> GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170
>> Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D
>>
>>
>>
>>


Re: Perhaps it's time to think about enhancements to the NANOG list...?

2021-03-20 Thread Eric Kuhnke
It's one thing to use a GUI tool when it's convenient and quick. I think
anyone that's ever experienced setting up a Unifi controller would probably
prefer provisioning a new 802.11ac AP from the GUI rather than doing it
manually at a command line.

But it's another thing to consider that we have a whole new generation of
people who *don't know and don't care* what's going underneath the GUI and
might not be able to do anything with the OS running on bare metal, if they
have to.

If we intend to abstract away configuring devices to a GUI level only and
not care about what's going on under the hood, then it's time for everyone
to just run out and renew their MCSE certifications and buy Meraki
subscriptions.



On Sat, Mar 20, 2021 at 6:35 PM David Siegel  wrote:

>
> ...not to mention that all mature networks are moving more towards GUI
> front ends for their automated network.  As the complexity of a network
> increases, CLI access becomes considerably more risky.
>
> The idea that "real engineers use the CLI" is dinosaur thinking that will
> eventually land those with that philosophy out of a job.  Just my personal
> $.02 (though I'm certainly not alone in my opinion).
>
> But I'd like to reiterate that the board's goal with modernization is not
> to alienate anyone from the existing community by forcing them into a
> web-interface.  Discourse is under evaluation, and if it doesn't accomplish
> the goal we'll try something else or build our own tool.
>
> Dave
>
>
>
>
> On Sat, Mar 20, 2021 at 6:52 PM Matthew Petach 
> wrote:
>
>>
>>
>> On Sat, Mar 20, 2021 at 5:13 PM scott  wrote:
>> [...]
>>
>>>  Of course, one would
>>> not find an HTTP GUI on the bigger networks dealt with on this list;
>>> only on the tiny networks.  So they're beginning learners and are, of
>>> course, welcome.  They will lean a lot, just as I did in the early days
>>> and do every day now days.
>>
>> [...]
>>
>>> scott
>>>
>>
>> Let's see...
>> Google: Gmail
>> Microsoft: Hotmail/Outlook/Office365
>> Yahoo/VerizonMedia: Yahoo Mail
>>
>> I'd have to say, there's some pretty big networks on this list that
>> use HTTP GUIs for their email.
>>
>> Of course, you might be big enough that you look down on the
>> networks of Google, Microsoft, and VZM as "tiny networks" -- in
>> which case, you're definitely entitled to your opinion, as all 8000
>> pound gorillas that look down on the puny 800 lb gorillas are.  ;)
>>
>> Matt
>>
>>
>


Re: Perhaps it's time to think about enhancements to the NANOG list...?

2021-03-20 Thread Eric Kuhnke
In my opinion we have two very different types of 'contact me off list'
things going on here.

We have commercial solicitations and people looking to make contacts for
buying transport circuits, capacity, etc.

And then on the other hand we have 'contact me off list' asks related to
network operational issues, when the subject pertains to what's going on
inside a particular AS, or in some peering or traffic routing problem. Not
everybody wants their own or their peer's dirty laundry aired in public if
something is broken or misconfigured in their relationship to the rest of
the global routing table. And particularly not in a context where it will
go in a public archive forever.




On Sat, Mar 20, 2021 at 4:53 PM Brielle  wrote:

>
> > On Mar 20, 2021, at 3:44 PM, Tom Beecher  wrote:
> >
> > A large portion of these emails lately have contained some variation
> > of 'contact me off list'. How does that provide any benefit to the
> > community? Is anyone else in the community getting any information
> > about what providers may be on a pathway that would help them? They
> > are not.
>
> This is how I’m viewing a lot of this too.  It’s like the posts on stack
> exchange et al, Reddit, and various forums that are just closed with
> “fixed” and no details or follow up.
>
> Kinda defeats the whole purpose of a mailing list with an archive since
> the same questions can come up again and again and no actual answers to the
> questions.
>
>
>
>
>


Re: Perhaps it's time to think about enhancements to the NANOG list...?

2021-03-18 Thread Eric Kuhnke
Perhaps the sales, marketing and 'business development' people who've never
typed "enable" or "configure" into a router a single day in their lives
might be better served with a dedicated list that is mission focused on
bizdev, and not operational issues.



On Thu, Mar 18, 2021 at 3:29 PM Matthew Petach 
wrote:

>
> On Thu, Mar 18, 2021 at 10:37 AM Tom Beecher  wrote:
>
>> CC back to the mailing list for visibility, since I ate the CC list.
>>
>> On Thu, Mar 18, 2021 at 1:31 PM Tom Beecher  wrote:
>>
>>> Rod-
>>>
>>> Please refer to the usage guidelines found here.
>>> https://nanog.org/resources/usage-guidelines/
>>>
>>> 14. Posts that encourage or facilitate an agreement about the following
 subjects are inappropriate: prices, discounts, or terms or conditions of
 sale; salaries; benefits, profits, profit margins, or cost data; market
 shares, sales territories, or markets; allocation of customers or
 territories; or selection, rejection, or termination of customers or
 suppliers.
>>>
>>>
>>>  I would tend to agree that while most of your posts to the list are
>>> within the guidelines, there have been occasions where a reasonable person
>>> could think you might be skirting the line a bit. In this case :
>>>
>>> - Your company works as a broker to procure capacity for others.
>>> - You sent an email to the list that wording wise would be exactly the
>>> same as many of us might send to someone they were looking for capacity
>>> from.
>>>
>>> I think most would agree this is pretty clearly against both the usage
>>> guidelines and the spirit of what this mailing list is about.
>>>
>>> I would also like to remind you that this list is administered by the
>>> NANOG organization. You have no authority to tell others to 'cease and
>>> desist', and insult someone as 'underemployed' is also not well tolerated
>>> here.
>>>
>>> I have looped in the list admins here. It would probably be a good idea
>>> to refrain from future messages that are clearly commercial in nature, or
>>> that contain unnecessary insults.
>>>
>>
>
>
> If only we had some way to segregate out different topics
> of interest or disinterest, so that people who weren't interested
> in questions about bandwidth availability could unsubscribe
> from those topics, and only subscribe to the topics that *did*
> interest them...
>
> #AFewDaysTooEarly
>
> ^_^;;
>
> Matt
>
>
>


Re: an IP hijacking attempt

2021-03-17 Thread Eric Kuhnke
I would encourage anyone who is not familiar with the full situation to
read the recent history of AFRINIC events:

https://afrinic.net/ast/pdf/afrinic-whois-audit-report-full-20210121.pdf

https://afrinic.net/20200826-ceo-statement-on-ip-address-misappropriation

https://krebsonsecurity.com/2019/12/the-great-50m-african-ip-address-heist/

On Wed, Mar 17, 2021 at 2:09 AM Brian Turnbow via NANOG 
wrote:

> Hi Noah,
>
>
> > Would you care to share the said prefix?
>
> This is the prefix we found associated with their name in the afrinic db.
>
> inetnum:169.239.204.0 - 169.239.207.255
>
>
> Cheers,
>
> Brian
>
>


Re: DPDK and energy efficiency

2021-03-05 Thread Eric Kuhnke
> Server PS maximum input wattage is 900W.  Present draw of 2.0A @ 208V is
~420W, so 420/900 = 46.67%

But in the real world an R640 would *never* draw 900W. Even if you were to
load it up with the maximal CPU configuration (2 x 125W TDP CPU per
socket), a full load of 2.5" 15K spinning drives, maximum RAM, and three
high wattage low-profile PCI-E cards, while simultaneously running CPU, RAM
and disk stress tests, you might get in the neighborhood of 550-600W under
load.

Much the same way that a desktop PC equipped with a nominally "850W" rated
active PFC 80+ gold power supply might be powering a motherboard and CPU
combo with a high CPU TDP, but total power consumption under stress
tests/benchmarks would be nowhere near 850W. That rating exists to ensure
that the power supply isn't running anywhere near its max capacity...



On Fri, Mar 5, 2021 at 3:33 PM Brian Knight  wrote:

> On 2021-03-05 15:40, Eric Kuhnke wrote:
>
> > For comparison purposes, I'm curious about the difference in wattage
> > results between:
> >
> > a) Your R640 at 420W running DPDK
> >
> > b) The same R640 hardware temporarily booted from a Ubuntu server live
> > USB, in which some common CPU stress and memory disk/IO benchmarks are
> > being run to intentionally load the system to 100% to characterize its
> > absolute maximum AC load wattage.
>
> We've got a few more hosts waiting to be deployed that are configured
> almost identically.  I'll see what we can do.
>
> I'm guessing those tests would pull slightly more power than the vEdge
> hosts, just because there's not much disk IO that happens on a
> networking VM.  These hosts have four SSDs for local storage.
>
> > What's the delta between the 420W and absolute maximum load the server
> > is capable of pulling on the 208VAC side?
> >
> > https://manpages.ubuntu.com/manpages/artful/man1/stress-ng.1.html
>
> Server PS maximum input wattage is 900W.  Present draw of 2.0A @ 208V is
> ~420W, so 420/900 = 46.67%
>
> > One possible factor is whether ESXI is configured to pass the pci-e
> > devices directly through to the guest VM, or if there is any
> > abstraction in between. For non-ESXI stuff, in the world of Xen or KVM
> > there's many different ways that a guest domU can access a dom0's
> > network devices, some of which can have impact on overall steady-state
> > wattage consumed by the system.
>
> The 420W server has its interfaces routed through the ESXI kernel.
> We're moving quickly to SR-IOV on new servers.
>
> > If the greatest possible efficiency is desired for a number of 1U
> > things, one thing to look at would be something similar to the open
> > compute platform single centralized AC to DC power units, and servers
> > that don't each have their own discrete 110-240VAC single or dual power
> > supplies. In terms of cubic meters of air moved per hour vs wattage,
> > the fans found in 1U servers are really quite inefficient. As a
> > randomly chosen example of 12VDC 40mm (1U server height) fan:
> >
> > https://www.shoppui.com/documents/9HV0412P3K001.pdf
> >
> > If you have a single 12.0VDC fan that's a maximum load of 1.52A, that's
> > a possible load of up to 18.24W for just *one* 40mm height fan. And
> > your typical high speed dual socket 1U server may have up to eight or
> > ten of those, in the typical front to back wind tunnel configuration.
> > Normally fans won't be running at full speed, so each one won't be a
> > 18W load, but more like 10-12W per fan is totally normal. Plus two at
> > least two more fans in both hot swap power supplies. Under heavy load I
> > would not be surprised at all to say that 80W to 90W of your R640's
> > total 420W load is ventilation.
>
> Which is of course dependent on the environmentals.  Fan speeds on our
> two servers are 25% for the 260W vs. 29% for 420W, so not much
> difference.  Inlet temp on both is ~17C.
>
> I checked out another R640 heavily loaded with vEdge VMs, and it's
> pulling similar power, 415W, but the fan speed is at 45%, because inlet
> temp is 22C.
>
> The TDP for the Xeon 6152 is 140W, which seems middle-of-the-road.  From
> the quick survey I did of Dell's configurator, the R640 can take CPUs up
> to 205W.  So we have headroom in terms of cooling.
>
> > In a situation where you're running out of power before you run out of
> > rack space, look at some 1.5U and 2U high chassist that use 60mm height
> > fans, which are much more efficient in ratio of air moved per time
> > period vs watts.
>
> Or ask the colo to turn the A/C lower ;)  (that moves the power problem
> elsewhere, I know)
>
> Thanks,
>
> -Brian
>


Microsoft Exchange zero day

2021-03-05 Thread Eric Kuhnke
ISPs/NSPs with customers running self hosted or on-premises Exchange may
want to be aware of this.


https://krebsonsecurity.com/2021/03/at-least-3-u-s-organizations-newly-hacked-via-holes-in-microsofts-email-software/

https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/


Re: DPDK and energy efficiency

2021-03-05 Thread Eric Kuhnke
For comparison purposes, I'm curious about the difference in wattage
results between:

a) Your R640 at 420W running DPDK

b) The same R640 hardware temporarily booted from a Ubuntu server live USB,
in which some common CPU stress and memory disk/IO benchmarks are being run
to intentionally load the system to 100% to characterize its absolute
maximum AC load wattage.

https://packages.debian.org/search?keywords=stress

https://packages.debian.org/search?keywords=stress-ng

What's the delta between the 420W and absolute maximum load the server is
capable of pulling on the 208VAC side?

https://manpages.ubuntu.com/manpages/artful/man1/stress-ng.1.html


One possible factor is whether ESXI is configured to pass the pci-e devices
directly through to the guest VM, or if there is any abstraction in
between. For non-ESXI stuff, in the world of Xen or KVM there's many
different ways that a guest domU can access a dom0's network devices, some
of which can have impact on overall steady-state wattage consumed by the
system.

If the greatest possible efficiency is desired for a number of 1U things,
one thing to look at would be something similar to the open compute
platform single centralized AC to DC power units, and servers that don't
each have their own discrete 110-240VAC single or dual power supplies. In
terms of cubic meters of air moved per hour vs wattage, the fans found in
1U servers are really quite inefficient. As a randomly chosen example of
12VDC 40mm (1U server height) fan:

https://www.shoppui.com/documents/9HV0412P3K001.pdf

If you have a single 12.0VDC fan that's a maximum load of 1.52A, that's a
possible load of up to 18.24W for just *one* 40mm height fan. And your
typical high speed dual socket 1U server may have up to eight or ten of
those, in the typical front to back wind tunnel configuration. Normally
fans won't be running at full speed, so each one won't be a 18W load, but
more like 10-12W per fan is totally normal. Plus two at least two more fans
in both hot swap power supplies. Under heavy load I would not be surprised
at all to say that 80W to 90W of your R640's total 420W load is
ventilation.

In a situation where you're running out of power before you run out of rack
space, look at some 1.5U and 2U high chassist that use 60mm height fans,
which are much more efficient in ratio of air moved per time period vs
watts.





On Fri, Mar 5, 2021 at 12:44 PM Brian Knight via NANOG 
wrote:

> On 2021-03-05 12:22, Etienne-Victor Depasquale wrote:
>
> > Sure, here goes:
> >
> > https://www.surveymonkey.com/results/SM-BJ9FCT6K9/
>
> Thanks for sharing these results.  We run DPDK workloads (Cisco nee
> Viptela vEdge Cloud) on ESXI.  Fwiw, a quick survey of a few of our Dell
> R640s running mostly vEdge workloads shows the PS output wattage is
> about 60% higher than a non-vEdge workload: 420W vs 260W.  PS input
> amperage is 2.0A@208V vs 1.4A, a 42% difference.  Processor type is Xeon
> 6152.  Stats obtained from the iDRAC lights-out management module.
>
> vEdge does not do any limiting of polling by default, and afaik the
> software has no support for any kind of limiting.  It will poll the
> network driver on every core assigned to the VM for max performance,
> except for one core which is assigned to the control plane.
>
> I'm usually more concerned about the lack of available CPU cores.  The
> CPU usage forces us not to oversubscribe the VM hosts, which means we
> must provision vEdges less densely and buy more gear sooner.  Plus, the
> increased power demand means we can fit about 12 vEdge servers per
> cabinet instead of 17.  (Power service is 30A 208V, maximum of 80%
> usage.)
>
> OTOH, I face far fewer questions about vEdge Cloud performance problems
> than I do on other virtual platforms.
>
>
> > Cheers,
> >
> > Etienne
>
>
> Thanks again,
>
> -Brian
>


Re: DPDK and energy efficiency

2021-03-05 Thread Eric Kuhnke
That was an unfortunate typo on my part, I meant to write "isn't
excessively difficult..."

Some real world examples of specific models of CPU + motherboard + PCI-E
NIC combinations with wattage figures at idle load, average load and
maximal load would be useful for comparison purposes.

On Fri, Mar 5, 2021 at 8:09 AM Tom Hill  wrote:

> On 05/03/2021 00:26, Eric Kuhnke wrote:
> > A great deal of this discussion could be resolved by the use of a $20
> > in-line 120VAC watt meter [1] plugged into something as simple as a $500
> > 1U server with some of the DPDK-enabled network cards connected to its
> > PCI-E bus, running DANOS.
>
> I'm fairly sure Etienne-Victor's email made specific reference to
> wattage measurements in both [2] and [3]. It would be fair to assume
> that the authors of those (IEEE) papers understood that you could
> measure wattage at the wall socket, before embarking on a paper
> regarding power efficiency.
>
> > Characterizing the idle load, average usage load, and absolute maximum
> > wattage load of an x86-64 platform is excessively difficult or
> complicated.
>
> It really isn't, particularly when the high figure is 400% of the low
> figure. You don't need milliwatt precision to see that your CPU is
> wasting power while not actually forwarding any packets.
>
> --
> Tom
>


Re: DPDK and energy efficiency

2021-03-04 Thread Eric Kuhnke
A great deal of this discussion could be resolved by the use of a $20
in-line 120VAC watt meter [1] plugged into something as simple as a $500 1U
server with some of the DPDK-enabled network cards connected to its PCI-E
bus, running DANOS.

Characterizing the idle load, average usage load, and absolute maximum
wattage load of an x86-64 platform is excessively difficult or complicated.

[1]
https://www.homedepot.com/p/Kill-A-Watt-Electricity-Monitor-P4400/202196386


On Thu, Mar 4, 2021 at 11:28 AM Etienne-Victor Depasquale 
wrote:

> *TL;DR - DPDK applications embody the phrase caveat emptor.*
>
> As Robert Bays put it:  "Please ask your open source dev and/or vendor of
> choice to verify."
> On the other hand, I do not recommend taking the following (citing Robert
> Bays again) for granted:
> "But the reality is [open source projects and commercial products] have
> all been designed from day one not to unnecessarily consume power."
>
> This note is presented in two sections.
> Section 1 presents the preamble necessary to avoid misinformation.
> Section 2 presents the survey.
>
> If so inclined, please read on.
>
> *SECTION 1*
> There are three issues at stake:
>
> 1.  the ground truth about the power/energy efficiency of (current)
> deployments that use DPDK,
> 2.  my choice of words for the first question, as this constitutes the
> claimed source of misinformation, and
> 3.  apportionment of responsibility for the attained level of
> power/energy efficiency of a deployment that uses DPDK,
>
> *Issue #1: ground truth on current deployments*
> I base on (a) research papers and (b) Pawel Malachowski's data. Numbered
> references are listed at the end of this e-mail.
>
> [1] investigates software data planes, including OvS-DPDK. Citing directly:
> "DPDK-OVS always works with high power consumption even when [there is] no
> traffic to handle.
> Considering the inefficiency [][in] power, DPDK provides power management
> APIs to compromise
> between power consumption and performance."
> "For DPDK-OVS, due to the feature of DPDK’s Polling Mode Driver (PMD),
> once the first DPDK port is added to vswitchd process,
> it creates a polling thread and polls DPDK device in continuous loop.
> Therefore CPU utilization for that thread is always 100%,
> and the power consumption r[]ises to about 138 Watt"
>
> [2] investigates multimedia content delivery and benchmarks *DPDK-OvS* in
> the process. Citing directly:
> "Even when no traffic was in transit,
> OvS-DPDK consumed approximately three
> times more energy than the other two data
> planes, adding 250 percent energy overhead
> (15.57 W) on top of the host OS."
>
> [3] proposes the use of ACPI P-states and the halt instruction to control
> power consumption,
> in the context of *a bespoke application*. Citing directly:
> "For example, a Xeon(R) E5-2620 v3 dual socket CPU consumes
> about 22W of power when it is idle; but if a DPDK-based software
> router runs on it, the CPU power soars to 83W even
> when no packets arrive. That is a power gap of more than
> 60W."
>
> [4] investigates the energy-efficient use of *Pktgen-DPDK*. Citing
> directly:
> "We find that high performance comes at the cost of high energy
> consumption."
>
> Pawel Malachowski  shows a list of cores (13 out of 16) in use by a DPDK
> application
> ("DPDK-based 100G DDoS scrubber currently lifting some low traffic using
> cores 1-13
> on 16 core host. It uses naive DPDK::rte_pause() throttling to enter C1").
> The list shows the cores spending most of their time in C1.
> This means that cores are in a low-power-idle state and therefore not in
> an active (C0) state.
> This shows a power-aware DPDK application.
>
> *Issue #2: my choice of words, as a source of misinformation*
> Issue has been taken with the text of question 1.
> I addressed this to the NANOG community,
> who are busy and knowledgeable.
> I chose, *with hindsight wrongly*, to paraphrase,
> with the expectation that a reader would interpret correctly.
> A better expression, that would still have been terse, would be:
> "Are you aware that *naïve* use of DPDK on a processor core keeps
> utilization at 100% regardless of packet activity?"
>
>
> *Issue #3: apportionment of responsibility for the attained level of
> power/energy efficiency of a deployment that uses DPDK*
> Pawel Malachowski states that "It consumes 100% only if you busy poll
> (which is the default approach)."
>
> Since it is the application that exploits the DPDK API,
> and since the DPDK API promotes run-to-completion (
> https://doc.dpdk.org/guides/prog_guide/poll_mode_drv.html),
> then *it is the application that determines power consumption*
> but it is DPDK's poll-mode driver *that poses a real threat to power
> efficiency, if used in "the default approach".*
>
> Robert Bays states:
> "The vast majority of applications that this audience would actually
> install in their networks do not do tight polling all the time and
> therefore don’t consume 100% of the CPU all 

Is there an established method for reporting/getting removed a company with 100% false peeringdb entries?

2021-03-04 Thread Eric Kuhnke
First, take a look at this:

https://www.peeringdb.com/asn/18894


Now look at these (or use your own BGP table analysis tools):

https://bgp.he.net/AS18894

https://stat.ripe.net/18894

The claimed prefixes announced, traffic levels and POPs appear to have no
correlation with reality in global v4/v6 BGP tables.

It is also noteworthy that I have inquired with a number of persons I know
who are active in network engineering in NYC, and nobody has ever
encountered this company.


Re: Famous operational issues

2021-02-23 Thread Eric Kuhnke
I would be more interested in seeing someone who HASN'T crashed a Cisco
6500/7600, particularly one with a long uptime, by typing in a supposedly
harmless 'show' command.


On Tue, Feb 23, 2021 at 2:26 PM Justin Streiner  wrote:

> An interesting sub-thread to this could be:
>
> Have you ever unintentionally crashed a device by running a perfectly
> innocuous command?
> 1. Crashed a 6500/Sup2 by typing "show ip dhcp binding".
> 2. "clear interface XXX" on a Nexus 7K triggered a cascading/undocument
> Sev1 bug that caused two linecards to crash and reload, and take down about
> two dozen buildings on campus at the .edu where I used to work.
> 3. For those that ever had the misfortune of using early versions of the
> "bcc" command shell* on Bay Networks routers, which was intended to make
> the CLI make look and feel more like a Cisco router, you have my
> condolences.  One would reasonably expect "delete ?" to respond with a list
> of valid arguments for that command.  Instead, it deleted, well...
> everything, and prompted an on-site restore/reboot.
>
> BCC originally stood for "Bay Command Console", but we joked that it
> really stood for "Blatant Cisco Clone".
>
> On Tue, Feb 16, 2021 at 2:37 PM John Kristoff  wrote:
>
>> Friends,
>>
>> I'd like to start a thread about the most famous and widespread Internet
>> operational issues, outages or implementation incompatibilities you
>> have seen.
>>
>> Which examples would make up your top three?
>>
>> To get things started, I'd suggest the AS 7007 event is perhaps  the
>> most notorious and likely to top many lists including mine.  So if
>> that is one for you I'm asking for just two more.
>>
>> I'm particularly interested in this as the first step in developing a
>> future NANOG session.  I'd be particularly interested in any issues
>> that also identify key individuals that might still be around and
>> interested in participating in a retrospective.  I already have someone
>> that is willing to talk about AS 7007, which shouldn't be hard to guess
>> who.
>>
>> Thanks in advance for your suggestions,
>>
>> John
>>
>


Re: Famous operational issues

2021-02-20 Thread Eric Kuhnke
>From a datacenter ROI and economics, cooling, HVAC perspective that might
just be the best colo customer ever. As long as they're paying full price
for the cabinet and nothing is *dangerous* about how they've hung the 2U
server vertically, using up all that space for just one thing has to be a
lot better than a customer that makes full and efficient use of space and
all the amperage allotted to them.


On Thu, Feb 18, 2021 at 11:38 AM t...@pelican.org  wrote:

> On Thursday, 18 February, 2021 16:23, "Seth Mattinen" 
> said:
>
> > I had a customer that tried to stack their servers - no rails except the
> > bottom most one - using 2x4's between each server. Up until then I
> > hadn't imagined anyone would want to fill their cabinet with wood, so I
> > made a rule to ban wood and anything tangentially related (cardboard,
> > paper, plastic, etc.). Easier to just ban all things. Fire reasons too
> > but mainly I thought a cabinet full of wood was too stupid to allow.
>
> On the "stupid racking" front, I give you most of a rack dedicated to a
> single server.  Not all that high a server, maybe 2U or so, but *way* too
> deep for the rack, so it had been installed vertically.  By looping some
> fairly hefty chain through the handles on either side of the front of the
> chassis, and then bolting the four chain ends to the four rack posts.  I
> wish I'd kept pictures of that one.  Not flammable, but a serious WTF
> moment.
>
> Cheers,
> Tim.
>
>
>


Re: Carrier Neutral Site - Freetown, Sierra Leone?

2021-02-19 Thread Eric Kuhnke
Sierra Leone is very much *not* French speaking, in the context of ISPs and
telecom.

There may be a significant minority of people who do speak French due to
its regional proximity to other countries, for business, but the language
of higher education, business, finance, telecom, real estate and so forth
is all in English.

On Fri, Feb 19, 2021 at 3:20 AM Rod Beck 
wrote:

> I am sure South Africa is better. I am really referring to French speaking
> Western Africa.
>
> -R.
>
> --
> *From:* NANOG 
> on behalf of Mark Tinka 
> *Sent:* Friday, February 19, 2021 5:09 AM
> *To:* nanog@nanog.org 
> *Subject:* Re: Carrier Neutral Site - Freetown, Sierra Leone?
>
>
>
> On 2/18/21 19:45, Rod Beck wrote:
>
> Every time I try to bring a circuit into Africa it is like a complete tour
> of Dante's Hell.
>
>
> A broad brush for such a large place.
>
> Mark.
>


Re: Carrier Neutral Site - Freetown, Sierra Leone?

2021-02-18 Thread Eric Kuhnke
There is really no such thing since there is just the one cable landing
station. I've previously spent months working in network infrastructure and
telecom in Sierra Leone, contact me off-list if you're serious about
getting something done there.




On Thu, Feb 18, 2021 at 9:46 AM Rod Beck 
wrote:

> Every time I try to bring a circuit into Africa it is like a complete tour
> of Dante's Hell.
>
> 
>
> Regards,
>
> Roderick.
>
> Roderick Beck
> Global Network Capacity Procurement
>
> United Cable Company
> www.unitedcablecompany.com
> https://unitedcablecompany.com/video/
> New York City & Budapest
>
> rod.b...@unitedcablecompany.com
>
> Budapest: 36-70-605-5144
>
> NJ: 908-452-8183
>
>
>
> [image: 1467221477350_image005.png]
>


Re: Famous operational issues

2021-02-18 Thread Eric Kuhnke
On that note, I'd be very interested in hearing stories of actual incidents
that are the cause of why cardboard boxes are banned in many facilities,
due to loose particulate matter getting into the air and setting off very
sensitive fire detection systems.

Or maybe it's more mundane and 99% of the reason is people unpack stuff and
don't always clean up properly after themselves.

On Wed, Feb 17, 2021, 6:21 PM Owen DeLong  wrote:

> Stolen isn’t nearly as exciting as what happens when your (used) 6509
> arrives and
> gets installed and operational before anyone realizes that the conductive
> packing
> peanuts that it was packed in have managed to work their way into various
> midplane
> connectors. Several hours later someone notices that the box is quite
> literally
> smoldering in the colo and the resulting combination of panic, fire drill,
> and
> management antics that ensue.
>
> Owen
>
>
> > On Feb 16, 2021, at 2:08 PM, Jared Mauch  wrote:
> >
> > I was thinking about how we need a war stories nanog track. My favorite
> was being on call when the router was stolen.
> >
> > Sent from my TI-99/4a
> >
> >> On Feb 16, 2021, at 2:40 PM, John Kristoff  wrote:
> >>
> >> Friends,
> >>
> >> I'd like to start a thread about the most famous and widespread Internet
> >> operational issues, outages or implementation incompatibilities you
> >> have seen.
> >>
> >> Which examples would make up your top three?
> >>
> >> To get things started, I'd suggest the AS 7007 event is perhaps  the
> >> most notorious and likely to top many lists including mine.  So if
> >> that is one for you I'm asking for just two more.
> >>
> >> I'm particularly interested in this as the first step in developing a
> >> future NANOG session.  I'd be particularly interested in any issues
> >> that also identify key individuals that might still be around and
> >> interested in participating in a retrospective.  I already have someone
> >> that is willing to talk about AS 7007, which shouldn't be hard to guess
> >> who.
> >>
> >> Thanks in advance for your suggestions,
> >>
> >> John
>
>


Re: Viable Third Option?

2021-02-17 Thread Eric Kuhnke
In the context of Montreal, to clarify, when you say Zayo are you referring
to Zayo Canada (former AT Canada/MTS-Allstream), or AS6461, the original
Abovenet AS which is Zayo USA's IP transit network?


On Wed, Feb 17, 2021 at 11:17 AM Eric Dugas via NANOG 
wrote:

> The details you mentioned about Cogent and HE are still right.
>
> I'm managing an eyeball network and have Cogent in our blend but I also
> have three other Tier1s and VERY extensive peering (public and private). We
> have (from the cheapest to most expensive) Cogent, Telia, Zayo and Tata. I
> have to mention that we're based in Montreal so less choices compared to
> your market. The only two other Tier1s available in Montrea is GTT and
> Lumen/CL/Level3.
>
> Cogent: difficult relations, good service overall
> Telia: excellent relations, good service overall
> Tata: good relations, good service overall
> Zayo: difficult relations, good service overall
>
> Eric
>
> On Feb 17 2021, at 1:49 pm, Mike Hammett  wrote:
>
> This is from the perspective of an eyeball network. I understand that
> content networks would have different objectives and reasons. For instance,
> I have little to no reason as an eyeball network to exchange traffic with
> any other eyeball network (aside from P2P games). For a content network,
> getting into the eyeball networks is their objective.
>
> My crystal ball tells me this thread will spiral out of control because
> people won't be able to keep it on topic, but it is a question that I hear
> VERY often. I also expect a lot of purely bad or outdated information to
> get thrown out.
>
> Please try to keep it on topic and not being pedantic over relatively
> unimportant details.
>
> There are two major low-cost providers, Cogent and HE.
>
> Cogent
>
>- Refuses to peer IPv6 with HE
>- Refuses to peer IPv6 with Google
>- Aggressive sales tactics
>
> Hurricane
>
>- Doesn't have Cogent IPv6 because of Cogent's refusal
>- Lack of communities for anything other than blackholes
>
>
> I know there are a variety of other providers such as Fusion Network that
> operate at similar price points, but are available in way fewer locations.
>
> What else is out there? Anyone else that isn't 5x, 10x the cost?
>
> Cogent and HE get looked down upon (and sometimes deservedly so), but when
> I talk to someone trying to sell me a port in 350 Cermak for 8x the cost of
> Cogent and HE, you better have a very good argument for why you're worth
> it...  and they never do. "We're not Cogent." "and?" Many times I'm quoted
> transit that costs more than Cogent + IX + HE and they don't really have a
> good argument for it.
>
> As an eyeball, I join an IX and there goes 50% - 85% of my traffic and
> almost all of my traffic that anyone is going to notice or complain about
> if there are issues (video streaming).
>
> I do understand that enterprise eyeballs may have different requirements.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
>
> Midwest Internet Exchange 
>
> The Brothers WISP 
>
>


Re: dumb question: are any of the RIR's out of IPv4 addresses?

2021-02-16 Thread Eric Kuhnke
That depends on your definition of grey market, there is an officially
approved ARIN IP block transfer process for people who are buying, via
brokers, discrete /24s and larger.



On Tue, Feb 16, 2021, 4:46 PM Michael Thomas  wrote:

>
> On 2/16/21 4:18 PM, Fred Baker wrote:
> > You may find this article interesting:
> >
> https://blog.apnic.net/2019/12/13/keep-calm-and-carry-on-the-status-of-ipv4-address-allocation/
> > <
> https://blog.apnic.net/2019/12/13/keep-calm-and-carry-on-the-status-of-ipv4-address-allocation/
> >
> >
> So aside from Afrinic, this is all being done on the gray market?
> Wouldn't you expect that price to follow something like an exponential
> curve as available addresses become more and more scarce and unavailable
> for essentially any price?
>
> Mike
>
>
> > Sent from my iPad
> >
> >> On Feb 16, 2021, at 3:07 PM, Michael Thomas  wrote:
> >>
> >> 
> >> Basically are there places that you can't get allocations? If so,
> >> what is happening?
> >>
> >> Mike
> >>
>


Re: Texas internet connectivity declining due to blackouts

2021-02-15 Thread Eric Kuhnke
See also, regional maps here. Thanks to CAIDA and the IODA project.

https://ioda.caida.org/ioda/dashboard

On Mon, Feb 15, 2021, 5:54 PM Sean Donelan  wrote:

> Not as bad as Myanmar (14%), Internet connectivity in Texas has been
> declining today.  According to NetBlocks, which normally monitors
> government imposed outages, reports network connectivity at 68% in Texas.
>
> https://netblocks.org/
>
> Texas operates a separate electric grid, with limited interconnections
> to the rest of North America.  For political reasons
>
> For those with long memories, ENRON a Texas based corporation, once upon a
> time drove rolling blackouts across California in order to make billions.
>


Re: Infomart Dallas is on generator

2021-02-15 Thread Eric Kuhnke
http://www.ercot.com/

The 501c(4) nonprofit entity which controls the Texas grid. They've been
publishing load shedding updates.

On Mon, Feb 15, 2021, 5:07 PM Randy Bush  wrote:

> > From the latest update it sounds like rolling power outages in Dallas as
> > most places in Texas
>
>
> https://www.texastribune.org/2011/02/08/texplainer-why-does-texas-have-its-own-power-grid/
>


Infomart Dallas is on generator

2021-02-15 Thread Eric Kuhnke
I have now heard from two reliable sources that Infomart Dallas is
presently on generator, and is likely to remain so until the cold
weather/electrical supply emergency in Texas has abated. No network impact
seen yet.


RIPE Atlas probe available on SpaceX Starlink beta terminal

2021-02-11 Thread Eric Kuhnke
https://atlas.ripe.net/probes/1001821/

I am running what I believe to be the first RIPE Atlas probe on a Starlink
beta test terminal.

When searching the index of public probes I did not find any other probes
with "spacex" or "starlink" in the descriptions.

This probe is at present not contained within AS14593 (Starlink). All beta
test terminals that I am aware of right now, including my own, are in cgnat
IP space and meet the public Internet via AS36492 (Google).

This particular terminal is topologically closest to things at major IX
points in the metro Seattle area. The absolute lowest ping time I've seen
to something at the Westin is 15.85ms, with averages more often between
21-32ms.

The site where this is installed will occasionally conduct other, non Atlas
related tests which result in full saturation of the upstream or downstream
connection, simulating a number of different types of real world use cases.
This means that occasionally the RTT ping to things in Seattle may rise as
high as 150ms, and artificially-induced packet loss will be introduced into
the connection.

Please feel free to contact me off-list with any questions.


Re: DoD IP Space

2021-02-11 Thread Eric Kuhnke
You don't, you wastefully assign a /24 to every unique thing that you think
needs an internal management IP block (even if there's 5 things that answer
pings there), and decide it's too much work to renumber things. Easy for a
big ISP that's also acquired many small/mid-sized ISPs to run out of v4
private IP space that way.



On Wed, Feb 10, 2021 at 4:05 AM Owen DeLong  wrote:

> Please explain to me how you uniquely number 40M endpoints with RFC-1918
> without running out of
> addresses and without creating partitioned networks.
>
> If you can’t, then I’m not the one making excuses.
>
> Owen
>
>
> > On Feb 9, 2021, at 15:44 , Izaac  wrote:
> >
> > On Fri, Feb 05, 2021 at 02:36:57PM -0800, Owen DeLong wrote:
> >> it is definitely possible to run out of RFC-1918 space with scale and
> no incompetence.
> >
> > No, it isn't.  It's the year 2021.  Stop making excuses.
> >
> > --
> > . ___ ___  .   .  ___
> > .  \/  |\  |\ \
> > .  _\_ /__ |-\ |-\ \__
>
>


Re: Problems with newish IP block assignment issues from ARIN

2021-02-08 Thread Eric Kuhnke
One common cause of this issue is entities out there that have very old
'bogons' filters in place for the larger block, as an entire /8, /12 to /16
size of space that, many years ago, was unallocated space. Without getting
the end point organizations running the httpd, firewalls or whatever to fix
their broken configuration, it's a hard issue to fix from your end.

On a longer term time scale like multiple years, the reachability of an IP
block like yours will gradually increase as people with broken services are
contacted by additional persons to say "hey, this really is valid ARIN IP
space".



On Mon, Feb 8, 2021 at 12:15 PM Justin Wilson (Lists) 
wrote:

> Folks,
> Have a gremlin we have been chasing around for several months now and it’s
> becoming a major issue as we are getting tighter on IPV4 and needing to
> give some provider assigned space back.
>
> In June we received a /22 from ARIN.  As is my workflow I started
> announcing it but waited a month while I checked out the geolocation
> databases for correct info, did testing ,etc. All this time our test
> accounts could browse web-sites, etc.
>
> We put one of the pools into production and things ran good for awhile.
> Then we started getting the occasional web-site was not working.  After
> several of these we started assigning the customer an IP out of one of our
> other ARIN blocks and the web-site would be fine and reachable. The issue
> seems to reside just on this /22.  We have other blocks from ARIN and they
> are just fine.  We can assign an IP out of this new block and can’t reach
> certain web-sites.  We turn around and assign out of another block and
> web-site works just fine.
>
> We have two upstreams and an IX on this network.  We have tried
> withdrawing the route on this particular /22 and isolating to one upstream
> alone and the problems still persist.
>
> Many of the web-sites in question are government (both state and local),
> online universities, and the occasional local news station.  They are
> diverse enough to not be traced down to a common point, except the IP
> block.
>
> We announce the IP block via BGP the same exact way we announce the other
> blocks. Traceroutes show the path going the same way no matter what IP
> block the customer has.
>
> It acts like the IP block was blacklisted at some point and got on some
> bad lists but I don’t want ti limit myself to that theory.  I have opened
> up a ticket with ARIN asking for any guidance.  Has anyone ran into this
> with new space assigned? Any tools, sites, etc. I can use to do further
> troubleshooting.  The IP block does not appear to have any blacklisted IPs
> according to MX toolbox, and some others.
>
> The block in question is 134.195.44.0/22.  It has been RPKI certified and
> has IRR entries.
>
> Thanks in advance
>
>
> Justin Wilson
> j...@mtin.net
>
> —
> https://j2sw.com - All things jsw (AS209109)
> https://blog.j2sw.com - Podcast and Blog
>
>


Starlink terminal data acquisition for network engineers

2021-02-06 Thread Eric Kuhnke
I thought about posting this to only NANOG, but since a great concentration
of beta testers of a technical/network engineering inclination are located
in the Pacific NW, decided to also include the SIX chat list.

You may have seen the Starlink android or ios consumer-friendly app, which
displays network traffic, uptime/downtime, and other link stats. I believe
this to be polled directly from the antenna unit itself over grpc.

The beta antennas are always 192.168.100.1. If you are using your own
router with the starlink beta system, in addition to its WAN interface
being an ordinary DHCP client in cgnat IP space, you'll need to manually
give it an address in that /24 and set up routing to reach the .1 IP as
needed.

reference: https://github.com/sparky8512/starlink-grpc-tools

reference: https://github.com/fullstorydev/grpcui

you'll need a fairly normal Linux or BSD box with:

git
go
python3
pip

use pip to install grpcio and grpcio-tools

install grpcurl: https://github.com/fullstorydev/grpcurl

do a git clone of the starlink-grpc-tools url above, also take a look at
its readme info

get the dish's protoset file and write it to new file dish.protoset , this
is an index of all data that can be polled
cd /home/eric/starlink-grpc-tools
/home/eric/go/bin/grpcurl -plaintext \
-protoset-out dish.protoset \
192.168.100.1:9200 \
describe SpaceX.API.Device.Device

/home/eric/go/bin/grpcurl \
-plaintext \
-d {\"get_history\":{}} \
192.168.100.1:9200 \
SpaceX.API.Device.Device/Handle | python parseJsonHistory.py

output of the above looks like this:
2021-02-06T08:15:56,3600,19.92034332,14,2,0.3125,0,0,0.0,0

full CSV header for the above:
datetimestamp_utc,samples,total_ping_drop,count_full_ping_drop,count_obstructed,total_obstructed_ping_drop,count_full_obstructed_ping_drop,count_unscheduled,total_unscheduled_ping_drop,count_full_unscheduled_ping_drop

since we are able to acquire the above in a comma-delimited csv format,
it's fairly easy to write a script storing the integers from any one of
those particular columns into a mariadb db, sqlite, influxdb, or whatever.

the following will output about 3.8MB of text for the full history (I
believe this to be the full copy of the ring buffer stored in RAM for the
terminal's statistics) , pipe it into a text file if you want to manually
look at it.

/home/eric/go/bin/grpcurl -plaintext -d {\"get_history\":{}}
192.168.100.1:9200 SpaceX.API.Device.Device/Handle


same as the above but human readable output

/home/eric/go/bin/grpcurl \
-plaintext \
-d {\"get_history\":{}} \
192.168.100.1:9200 \
SpaceX.API.Device.Device/Handle | python parseJsonHistory.py -v

current counter:   299673
All samples:   43200
Valid samples: 43200
Parsed samples:3600
Total ping drop:   20.03700998
Count of drop == 1:14
Obstructed:2
Obstructed ping drop:  0.3125
Obstructed drop == 1:  0
Unscheduled:   0
Unscheduled ping drop: 0.0
Unscheduled drop == 1: 0


see the get_history_notes.txt file for more info


SOME EXAMPLE QUERIES
these should match with what the json query is in the grpc GUI
# get status
/home/eric/go/bin/grpcurl \
-plaintext \
-d {\"getStatus\":{}} \
192.168.100.1:9200 \
SpaceX.API.Device.Device/Handle

# get device info
/home/eric/go/bin/grpcurl \
-plaintext \
-d {\"getDeviceInfo\":{}} \
192.168.100.1:9200 \
SpaceX.API.Device.Device/Handle

# get history, this outputs a huge amount of data
/home/eric/go/bin/grpcurl \
-plaintext \
-d {\"getHistory\":{}} \
192.168.100.1:9200 \
SpaceX.API.Device.Device/Handle


The following is copied/pasted from my notes file on things we can acquire,
and then use a tiny shell script with awk, sed, regex, whatever as needed
to trim out just the numbers, and put them somewhere else for polling by
snmp extend

/home/eric/go/bin/grpcurl \
-plaintext \
-d {\"getStatus\":{}} \
192.168.100.1:9200 \
SpaceX.API.Device.Device/Handle

notes on what's what:
figures we care about to parse out and turn into just the integers
snr can never be higher than 9
fractionobstructed appears to be the percentage of the time that the view
is obstructed, as long as the view
remains unobstructed, this number appears to slowly decrement over time
validS is valid seconds? i think
the S is almost likely always Seconds of time

"uptimeS": "304439"
"snr": 9,
"fractionObstructed": 0.0013524292,
"validS": 61815.74,
"last24hObstructedS": 53
"downlinkThroughputBps": 47915.73,
"uplinkThroughputBps": 34980.496,
"popPingLatencyMs": 29.26


example of running the command above twice, the second time a few minutes
after the first,
to see that fractionObstructed does decrement itself over time
first run: 0.0013524292
second run: 0.0013467998


Broadcom P2100G 100G PCI-E 4.0 interface and Linux

2021-02-02 Thread Eric Kuhnke
This might be a long shot, but if there is anyone out there with a system
that has one of these in it, running a very recent Linux kernel:

https://www.broadcom.com/products/ethernet-connectivity/network-adapters/100gb-nic-ocp/p2100g

I'm looking for a copy of the output from 'dmesg' on boot and output from
"lspci -v" to see exactly how it shows up on the PCI-E bus.


Re: Nice work Ron

2021-01-21 Thread Eric Kuhnke
> How many other Belize defuncts do they have?  How many offshore countries
like Belize are there in the region?

Based on my cursory knowledge of offshore corporate registrations in
Belize, Panama and the Cayman Islands, identifying those locations which
are only mailboxes versus actual business office addresses should not be
overly complicated or difficult.

In the era of Google Street View for most major urban areas the initial
search process can be done remotely, such as when it appears that dozens of
companies occupy one street address of a very small office building.

For instance look at the company registration offices, with hundreds of
corporate entities sharing one office suite address, which were created by
Mossack Fonseca in Panama City.

https://en.wikipedia.org/wiki/Mossack_Fonseca

The same principle would apply not just to LACNIC, but also to anybody who
wanted to go in detail through the number of ISPs and hosting companies
that nominally exist in Malta and Cyprus.


On Thu, Jan 21, 2021 at 10:25 AM Töma Gavrichenkov 
wrote:

> Peace,
>
> On Thu, Jan 21, 2021, 8:17 PM Jean St-Laurent via NANOG 
> wrote:
>
>>
>> https://krebsonsecurity.com/2021/01/ddos-guard-to-forfeit-internet-space-occupied-by-parler/
>>
>
> A disclaimer:
> - Standing for the sanity of the Internet routing;
> - Assuming (quite reliably) actual policy violation;
> - Assuming good faith
>
> — am I the only one to believe that (given that LACNIC had allocated an IP
> block to a company that doesn't conform to the LACNIC policies) what we
> urgently need to see next is the complete audit of the LACNIC operations,
> so that this doesn't look like selective enforcement?
>
> How many other Belize defuncts do they have?  How many offshore countries
> like Belize are there in the region?
>
> --
> Töma
>


Re: DoD IP Space

2021-01-20 Thread Eric Kuhnke
Additionally, examples of impersonating a corporate entity to acquire
unused IP space (Erie Forge and Steel's /16, anyone?) undoubtedly fall
under existing, pre-internet interstate commerce fraud laws...

http://web.mit.edu/net-security/Camp/2003/DBowie_IP_Hijacking.pdf

https://www.wired.com/images_blogs/threatlevel/files/edited-iphd-2.ppt



On Wed, Jan 20, 2021 at 9:54 AM John Curran  wrote:

> On 20 Jan 2021, at 12:17 PM, Bryan Fields  wrote:
>
>
> AFAIK IANA and the RIR's cannot enforce use of IP space assignments on any
> network.
>
>
>   While route hijacking isn't necessarily an ARIN issue, I will
> note that several US law enforcement agencies (FBI & NCIS Cybercrime units)
> are quite interested in such events and do investigate them looking for
> criminal activity.
>
> (See
> https://pc.nanog.org/static/published/meetings/NANOG77/2108/20191028_Elverson_Your_As_Is_v1.pdf
>  for
> details.)
>
> FYI,
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
>


Re: DoD IP Space

2021-01-20 Thread Eric Kuhnke
Organizations that I have seen doing as you describe, because they ran out
of RFC1918 IP space, are also often using their existing private IP space
wastefully in the first place. Rather than using DoD /8s internally, if
they absolutely need to support v4-only equipment on their internal
management networks, they might be better served by considering that maybe
every POP doesn't need its own /24.

I'm talking about things I've seen where all of the management/monitoring
IPs of the equipment at a site might fit very comfortably in a v4 /27. But
that would be a labor intensive IP space and management address auditing
process of renumbering things, fixing internal DNS and rDNS, and updating
any myriad of things that might have the direct IP addresses of stuff
hardcoded into configuration files.

Rather than doing all of the above, they simply go "hey here's a /8 that's
highly unlikely our management network will ever need to talk to it in a
global routing table", and continue on with their /24 plan per tiny POP.



On Wed, Jan 20, 2021 at 8:38 AM Dorn Hetzel  wrote:

> I am aware of some companies that have used parts of a DoD /8 internally
> to address devices in the field that are too old to ever support IPV6.
> Those devices also never interact with the public internet, and never will,
> so for them, I guess the only risk would be that some other internal system
> that wants to talk to those devices would not also be able to talk to any
> endpoint on the public internet that wound up using space allocated from
> that block, some time in the future.  Is that about right or am I missing
> some key failure point?
>
> On Wed, Jan 20, 2021 at 9:59 AM j k  wrote:
>
>> My question becomes, what level of risk are these companies taking on by
>> using the DoD ranges on their internal networks? And have they
>> quantified the costs of this outage against moving to IPv6?
>>
>> Joe Klein
>>
>> "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene
>> 1)
>> "*I skate to where the puck is going to be, not to where it has been."
>> -- *Wayne Gretzky
>> "I never lose. I either win or learn" - Nelson Mandela
>>
>>
>> On Wed, Jan 20, 2021 at 9:06 AM John Curran  wrote:
>>
>>> Indeed.
>>> /John
>>>
>>> > On Jan 20, 2021, at 8:47 AM, Cynthia Revström  wrote:
>>> >
>>> > But if you do this, make sure you keep track of where you might have
>>> put policies like this in, in case the DoD sells some the space or whatever
>>> in the future.
>>>
>>>


  1   2   3   >