Re: Ingress filtering on transits, peers, and IX ports

[Matt Harris]

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.
On Tue, Oct 13, 2020 at 5:22 PM Mel Beckman  wrote:

> You can also use Unicast Reverse Path Forwarding. RPF is more efficient
> than ACLs, and has the added advantage of not requiring maintenance. In a
> nutshell, if your router has a route to a prefix in its local RIB, then
> incoming packets from a border interface having a matching source IP will
> be dropped.
>
> RPF has knobs and dials to make it work for various ISP environments.
> Implement it carefully (as is be standing next to the router involved :
>

I received one of the aforementioned messages as well, and my response was
that perhaps the best overall step towards protection at scale from the
issue they raise would be for SPs to implement URPF facing stubby,
single-homed networks. This is effectively the low-hanging fruit and
doesn't require too much additional labor in terms of maintaining
additional ACLs or prefix lists. In the case of multi-homed networks,
things are less straight forward, but multi-homed networks make up a
minority even if we exclude consumer internet connections.

Take care,
Matt

Re: DE-CIX - Wednesday 11:00am - 1:30pm Eastern

[Matt Harris]

On Thu, Oct 29, 2020 at 11:10 AM Matt Hoppes <
mattli...@rivervalleyinternet.net> wrote:

> Hi Ed,
> Thank you for that clarification.
>
> On 10/29/20 12:05 PM, Ed dAgostino wrote:
> > All,
> >
> >
> > For clarification, DE-CIX New York operates over a dozen switches as
> > part of our local switch fabric.   ONE of our switches malfunctioned for
> > about a two hour period  prior to rebooting and that caused problems for
> > customer networks connected to that switch during that period.   All
> > other switches were not impacted and the DE-CIX New York exchange did
> > not go down.
> >
> >
> > Ed d'Agostino


It looks as though something's going on again right now. I just lost
sessions to one of the two route servers, and some but not all of my other
peers on DE-CIX NY.

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.

Re: Technology risk without safeguards

[Matt Harris]

On Wed, Nov 4, 2020 at 10:48 AM Suresh Kalkunte 
wrote:

> Hello,
>
> I believe the below described method of causing intentional (1) damage to
> equipment in data centers and (2) physical injury to a person at the
> workplace is on-topic for the NANOG community, if not, I look forward to
> your feedback. As a software developer who has subscribed to the NANOG
> mailing list for a number of years, I post this note relying on
> intellectual honesty that I have had the opportunity to observe since
> 1996-97.
>
> The below described technology risk is applicable to
> computing/communication equipment rendered vulnerable by Intentional
> Electromagnetic Interference (jamming an electronic device) and the risk of
> health sabotage affecting people (jamming a human) managing the Internet
> infrastructure enabled by intentional application of powerful
> radiofrequency fields (RF) emitted by re-purposed components salvaged from
> a kitchen heating appliance (Magnetron) or from an outdoor high gain/power
> Line of sight transceiver (unidirectional microwave radio) which has a harm
> causing range up to 25 meters (estimated using a Spectral Power Density
> calculator like www.hintlink.com/power_density.htm).
>
> This risk from mis-application of powerful RF is from human operated or
> IoT apparatus** with an avenue of approch from (a) subterrain placement
> aided by a compact/mini directional horizontal drilling machine (eg.
> principle of placing a stent in the heart) and/or (b) strategic placement
> in an obscure over-surface location to maximize negative impact on the
> target of opportunity.
>
> With building materials or ground offer insufficient* protection to block
> the passage of powerful RF and the absence of diagnostic/forensic tests to
> detect biomarkers expressed post-overexposure to harmful RF  (combination
> of RF frequency, Spectral Power Density/Specific Absorption Rate incident
> on a person and duration of exposure), intentional damage to electronic
> equipment and people is at present unrestricted.
>
> The purpose of bringing this method of exploting technology to your
> attention is with an interest to build the momentum for ushering in the
> much needed safeguards in this context.
>

While I'm a bit confused as to what this message is trying to ultimately
get at, it should be noted that folks who work with RF communications
equipment and other EM emitters which are strong enough to cause harm to a
person are generally well aware of the necessary precautions and take them
on a day to day basis when working with this equipment. If there's evidence
that some part of our industry is ignoring or failing to train their team
members on safety best practices, then let's hear that out specifically and
I'm all for working to rectify that.

On the other hand, the post seems to hint at intentionally using high
powered RF to inflict intentional harm on a person or to jam communications
signals. The former is relatively difficult to do by virtue of the amount
of power necessary. Quite basically, there are much easier ways to go about
injuring someone if that's what you want to do. Of course, intentionally
injuring another person is a criminal act in just about every jurisdiction.
As far as the latter goes, the ability to jam RF communications has existed
for as long as RF communication has, and the knowledge of how to accomplish
it is relatively widespread. It is also illegal in the US and most likely
many other jurisdictions as well, and in the US the FCC has enforcement
power with the ability to levy some pretty hefty fines on anyone who does
so, even inadvertently though negligent practices.

The post states that their intention is to "build the momentum for ushering
in the much needed safeguards in this context." but lacks specificity with
regard to what safeguards they propose beyond the legal/regulatory ones
that already exist, so I'm not sure what more can really be said here.

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.

Re: Technology risk without safeguards

[Matt Harris]

My first instinct is to let this be because the level of conspiracy theory
nuttiness seems to be very high and the level of knowledge of basic physics
seems to be very low, but since this list is archived in a way that
lay-people may reference it at some point in the future, I'm going to go
ahead and reply just this once more and just one point here so that a lack
of response here won't be used as fodder by conspiracy theorists.


Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.
On Wed, Nov 4, 2020 at 2:48 PM Suresh Kalkunte  wrote:

>
> At an employer where I developed Wi-Fi based SOHO device, an adjacent
> group was testing Line of Sight transceivers. Nobody warned me of the
> inclement health (a general physician in 2007 suspected cancer looking at a
> blood test) from close quarters exposure to the side lobes emanating from
> the microwave radio.
>

There is no scientific evidence that RF emissions in the bands used for
communications have any causal relationship with cancer in humans. This is
an internet conspiracy theory with no basis in reality or science. If your
doctor suspected that you had cancer caused by something related to
microwave band communications equipment, you need to find a new doctor.

Re: shouting draft resisters, Parler

[Matt Harris]

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.
On Mon, Jan 11, 2021 at 5:25 PM Joe Loiacono  wrote:

> Only if you believe censorship has nothing to do with free speech.
>
>
I'm not sure what you mean here. One can advocate for or against "free
speech" and whatever it may ultimately include or not include without
having to invoke a specific United States legal framework which doesn't
apply in many (most) contexts. Freedom of speech as a right of humankind
has existed as a concept since long before the US did, the US merely
enshrined in its constitution that the government should generally not
infringe on it, with very limited circumstances in which it may do so. This
is, in my opinion and that of others, a good thing. Where those lines are
to be drawn is largely up to the courts, and is often the subject of debate
among both jurists and laypersons.

I guess my overall point here is this: there's no reason you can't say
"free speech is an important right that we must protect" without invoking
any specific legal doctrine, if that's what you believe. That statement can
easily apply to any government agency, private corporation, public
corporation, or individual citizen, and be broadly relevant. Once you
invoke the first amendment, you're now limiting the context of your
advocacy.

On 1/11/2021 6:16 PM, Anne P. Mitchell, Esq. wrote:
> >>> That would make me wonder how many cases there have been of someone
> >>> "shouting fire in a crowded theatre" where there was no fire and at
> >>> least one person died as a result; ...
> >> This seems a wee bit distant from Parler or TOS or Sec 230.
> > That's because people continue to believe that this has something to do
> with the 1st Amendment, which of course it does not.  But you can't
> disabuse people of their poorly informed notions.
> >
> > Anne
>

Re: Hosting recommendations ... ?

[Matt Harris]

On Tue, Jan 19, 2021 at 3:27 PM Brandon Martin 
wrote:

> On 1/19/21 12:56 PM, Bryan Holloway wrote:
> >
> > I'm very curious about your assertion:
> >
> > Is nested virtualization really a thing?
> >
> > I mean, I'm not exactly trying to render Pixar's latest movie ... just
> > trying to push some bits around (light web-sites, some e-mail ...)
> >
> > It just seems inherently prone to issues.
> >
> > Could you back this up with any white-papers or documentation on the
> > subject? I'm genuinely interested ...
>
> With KVM, if you have a recent kernel and qemu, it pretty much "just
> works" on supported hardware.  AFAIK Xen supports "Xen on Xen", too, but
> I haven't used it and don't know much about it.
>
> The use case is pretty much exactly this.  You (the product consumer)
> are handed a product that amounts to a virtual machine on somebody
> else's $BIGBOX.  You want to deploy multiple virtual machines where you
> have direct control over their lifecycle, configuration, etc. and can
> bring in additional I/O resources, etc. at the hypervisor level
> (consider that, with KVM, the Linux kernel basically IS the hypervisor).
>   So, you run one or more VMs inside the top level VM that you're handed.
>
> It's full of lots of little wiggles and can be a pain to maintain if you
> have visibility into both levels of the equation, but it does seem to
> work and is surprisingly performant.
>

Nested virtualization is, however, pretty widely deployed for production
workloads. Take for instance Juniper's vSRX and vMX products. Both require
nested virtualization support as they run a Wind River Linux instance with
KVM directly on your virtual machine which may be on vmware, KVM, Hyper-V,
etc, and then Junos running nested within the WRL KVM virtual machine. So
it's not like this is something that's uncommon or not trustworthy, lots of
us are doing it every day with no serious problems and entirely acceptable
performance on modern hardware. I run a decent fleet of vSRX's on Hyper-V
and it works well. YMMV as always based on your own platform, but I don't
think that nested virtualization is something that we should be steering
clear of at this point.

- mdh

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.

Re: RADB contact needed

[Matt Harris]

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.
On Wed, Jan 20, 2021 at 10:56 AM Mel Beckman  wrote:

> Ostap,
>
> Why was this prefix revoked? And what is your interest in the matter?  I
> ask because, of late, there have been attempts to lockdown African Internet
> access by various political factions, for example the situation in Uganda.
>
>  -mel
>

It's looking like this block had been (probably fraudulently) parceled out
and sold in small chunks to legitimate-but-gullible companies? The first
/24 out of it and another latter /24 are advertised by a rural Nebraska
WISP with a single-homed upstream to a company that I know to be legitimate
who had added their entry to RADB for their customer. Most of the other
chunks look to be advertised by random seemingly-legitimate organizations
too.

When this space stops routing, there's going to be a big mess and I'm
pretty sure a lot of lawsuits.

Ooof.

Re: OVH datacenter SBG2 in Strasbourg on fire 🔥

[Matt Harris]

Matt Harris|Infrastructure Lead
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.
On Wed, Mar 10, 2021 at 9:43 AM Andy Ringsmuth  wrote:

>
> > On Mar 10, 2021, at 3:23 AM, Fredy Kuenzler  wrote:
> >
> > Very sad day for our colleagues at OVH AS16276 as they lost their
> datacenter SBG-2 in Strasbourg/France completly („everything is destroyed“)
> in a fire 🔥 and the neighboring SBG1/SBG3/SBG4 at least temporary.
> >
> >
> https://www.dna.fr/amp/faits-divers-justice/2021/03/10/strasbourg-important-incendie-dans-une-entreprise-situee-sur-un-site-seveso-au-port-du-rhin
>
> Sad to see of course, but also a little surprising that fire suppression
> systems didn’t, well, suppress the fire.
>
> Unless they didn’t exist?
>

I was just discussing this with a buddy of mine. I'm hoping we get a
post-mortem that helps us understand what happened and how we can all do
better potentially as an industry. The fact that fire fighters (ostensibly
professionals, based out of what appears to be an industrial areas no less)
were unable to get the fire under control definitely indicates to me that
there was something exceptional going on there beyond a typical fire in a
data center environment.

There had to have been cascading failures somewhere along the line, though,
imho: whether that involve the engineering, implementation, or execution
stage or multiple thereof remains to be seen...

 - Matt

Re: OVH datacenter SBG2 in Strasbourg on fire 🔥

[Matt Harris]

Matt Harris|Infrastructure Lead
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.
On Thu, Mar 11, 2021 at 4:46 AM Daniel Karrenberg  wrote:

> Maybe the innovative ‘green’ design had something to do with the
> rapid spread of the fire and the way fire suppression was engineered:
>
> https://us.ovhcloud.com/about/company/green-tech
>
> Further I conjecture that a halon system would not be feasible in such a
> structure.
>
> Daniel
>

There are plenty of effective options besides environmentally-destructive
Halon, dangerous-to-equipment water sprinkler, or dangerous-to-personnel
CO2 for fire suppression these days. Some of the most common today are foam
systems like FM-200 or 3m's Novec.

- Matt

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

[Matt Harris]

Matt Harris|Infrastructure Lead
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.
On Mon, Mar 22, 2021 at 8:34 AM Noah  wrote:

>
> Well baby boomers & gen-x will struggle to dump mail...I mean it simple
> and just works.
>
> We were trying to get a community of newbie techies mostly millennials &
> gen-z to actively engage on a list we subscribed them too for the past 2
> years and believe me, I can count no more than 10 posts mainly from we few
> mailing list folk...
>
> When we requested for feedback, them gen-z cried out loud for interactions
> to happen on some social media app through groups or channels, and since
> they are the target audience and the majority, we settled for discord and
> telegram which they actively engage on :-).
>
> We still maintain the mailing list though and most announcement are done
> via it but things are changing hey
>

I'm a gen-x guy myself, but I've gotten into discord largely as a
replacement for IRC as it's declined over the past decade and a half and
there are some actual good communities on there at this point. There's
actually a very good network engineering discord group, even.

I definitely don't care for web-based forums personally, and like many
other folks, I don't even have a facebook account. Email lists are
extremely accessible as they don't require any third-party accounts, and
there's a lot of transparency in terms of how you'll be exposed - that is,
your email address/headers and the content of your messages may end up
public, but no one's harvesting all of your web visits via intrusive
cookies and such.

- Matt

Re: Global Akamai Outage

[Matt Harris]

Matt Harris|Infrastructure Lead
816-256-5446|Direct
Looking for help?
Helpdesk|Email Support
We build customized end-to-end technology solutions powered by NetFire Cloud.
On Thu, Jul 22, 2021 at 11:35 AM Mark Tinka  wrote:

> https://edgedns.status.akamai.com/
>
> Mark.
>

Seems to be clearing up at this point, was able to get to a site just now
that I wasn't a little bit ago.

Re: Anycast but for egress

[Matt Harris]

Matt Harris|Infrastructure Lead
816-256-5446|Direct
Looking for help?
Helpdesk|Email Support
We build customized end-to-end technology solutions powered by NetFire Cloud.
On Tue, Jul 27, 2021 at 1:29 PM Vimal  wrote:

> (Unsure if this is the right forum to ask this question, but here goes:)
>
> From what I understand, IP Anycast can be used to steer traffic into a
> server that's close to the client.
>
> I am curious if anyone here has/encountered a setup where they use anycast
> IP on their gateways... to have a predictable egress IP for their traffic,
> regardless of where they are located?
>
> For example, a search engine crawler could in principle have the same IP
> advertised all over the world, but it looks like they don't...  I wonder
> why?
>

Hi Vimal,
I'm not sure I see what the benefit would be here. Maybe if you explain
what exactly you're trying to accomplish, someone can point you in the
right direction? What you're describing here isn't really analogous to how
anycast works. Anycast isn't really a protocol in and of itself, it's
simply the act of advertising IP space externally in a diverse way and then
routing that traffic to the nearest capable host once it's inside your
network, rather than to a single very specific host that exists in one
specific place.

- mdh

Re: netflow in the core used for surveillance

[Matt Harris]

On Wed, Aug 25, 2021 at 4:33 PM Paul Ebersman 
wrote:

> randy>
> https://www.vice.com/en/article/jg84yy/data-brokers-netflow-data-team-cymru
>
> randy> at&t, comcast, ... zayo, please tell us you do not do this.
>
>
> aaron> You know they do.
>
> No, you don't know that.
>
> The above all certainly collect this info. Not all sell it to anyone who
> asks.
>

Well, not just anyone who asks. But perhaps some of those who ask. You, for
example, as a random guy, might not have much luck. Various and sundry
other organizations, on the other hand, would likely have much better luck,
were they to pursue such a thing.

Matt Harris|Infrastructure Lead
816-256-5446|Direct
Looking for help?
Helpdesk|Email Support
We build customized end-to-end technology solutions powered by NetFire Cloud.

Re: FYI - Suspension of Cogent access to ARIN Whois

[Matt Harris]

On Tue, Jan 7, 2020 at 4:46 PM Martin Hannigan  wrote:

>
>
> On Tue, Jan 7, 2020 at 08:51 John Curran  wrote:
>
>> On 7 Jan 2020, at 5:01 AM, Martijn Schmidt via NANOG 
>> wrote:
>> >
>> > Out of curiosity, since we aren't affected by this ourselves, I know of
>> cases where Cogent has sub-allocated IP space to its customers but which
>> those customers originate from their own ASN and then announce to multiple
>> upstream providers.
>> >
>> > So while the IP space is registered to Cogent and allocated to its
>> customer, the AS-path might be something like ^174_456$ but it's entirely
>> possible that ARIN would observe it as ^123_456$ instead. Are such IP
>> address blocks affected by the suspension?
>>
>> As noted earlier, ARIN has suspended service for all Cogent-registered IP
>> address blocks - this is being done as a discrete IP block access list
>> applied to relevant ARIN Whois services, so the routing of the blocks are
>> immaterial - a customer using a suballocation of Cogent space could be
>> affected but customers with their own IP blocks blocks that are simply
>> being routed by Cogent are not affected.
>
>
>
> This is a disproportionate response IMHO. $0.02
>
> YMMV,
>
> -M<
>

Seems entirely reasonable to me. You break the rules, you lose the
privilege. Works the same way with my 7 year old.

Re: Jenkins amplification

[Matt Harris]

On Mon, Feb 3, 2020 at 12:50 PM Christopher Morrow 
wrote:

> On Mon, Feb 3, 2020 at 1:35 PM Christopher Morrow
Matt Harris|CIO
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver innovative IT solutions.

>  wrote:
> >
> > On Mon, Feb 3, 2020 at 1:26 PM William Herrin  wrote:
> > >
> > > On Mon, Feb 3, 2020 at 10:24 AM Christopher Morrow
> > >  wrote:
> > > > On Mon, Feb 3, 2020 at 11:45 AM Harald Koch  wrote:
> > > > > Jenkins, like a zillion other developer-oriented tools, should
> never be deployed Internet-facing.
> > > > > Reflection attacks inside an enterprise are handled by HR. :)
> > > >
> > > > good golly, so glad everyone's enterprise is a hard candy version of
> same.
> > > > no need for these remote workers, or discontiguous offices, or
> > > > 'internet centric workforces'.
> > >
> > > VPN.
> >
> > I love it when my home network gets full access to the corporate network!
>
> Sorry, to be a little less flippant and a bit more productive:
>   "I don't think every remote endpoint needs full access (or even some
> compromise based on how well you can/can't scale your VPN box's
> policies) access to the internal network. I think you don't even want
> to provide this access based on some loose ideas about 'ip address'
> and 'vpn identity'."
>
> Ideally you'd be able to authenticate and authorize and even
> account(!) based on a real user-id + passwd + token (2fa thing).
> Somethign akin to this:
>   https://cloud.google.com/beyondcorp/
>
> maybe using the googz work directly isn't your cup-o-joe(jane?) but...
> the idea itself is the point I was aiming for.
>

Re: Jenkins amplification

[Matt Harris]

On Mon, Feb 3, 2020 at 12:50 PM Christopher Morrow 
wrote:

>
> Sorry, to be a little less flippant and a bit more productive:
>   "I don't think every remote endpoint needs full access (or even some
> compromise based on how well you can/can't scale your VPN box's
> policies) access to the internal network. I think you don't even want
> to provide this access based on some loose ideas about 'ip address'
> and 'vpn identity'."
>

This isn't particularly difficult or costly to do right, though. pfSense on
a VM with relatively minimal resources running your VPNs works very well
and can easily be configured to authenticate against, for example, LDAP as
well. It also has a convenient firewall configuration user interface that's
very straight-forward, so you don't need some highly-paid network
engineering guru to manage the thing, either, so you can associate a given
identity with a given address and then apply firewall rules right at that
VPN border in addition to the other access controls that you should have in
place upstream. Certainly giving full access to everyone is overkill,
unnecessary, and can be problematic for obvious reasons - but at the same
time, we're talking about back doors here when many of the same folks
worried about these back doors also have wide open front doors at the same
time.

Matt Harris|CIO
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver innovative IT solutions.

Re: best email list?

[Matt Harris]

On Wed, Apr 8, 2020 at 1:08 PM Anne P. Mitchell, Esq. 
wrote:

>
>
> > On Apr 8, 2020, at 12:02 PM, David Funderburk 
> wrote:
> >
> > What email list companies or direct mail have you used with success?
> During this time I feel there are many companies that are or should be
> considering off-site back ups or putting in remote servers.  I'd like to
> contact some of these who could benefit from our data center.  Suggestions?
>
> You do understand that permission cannot be transferred, and that using
> purchased or rented email lists is a violation of all sorts of laws, right?
>

It's also just a bad idea. Legitimate professionals will chalk you up as a
spammer, and not want to do business with you. How many folks here with
budgets for such things explicitly avoid spammers? I know I do.

If you want to gain a positive reputation, the best way to do so is to
actually work for it. It can't be purchased and it certainly can't be
obtained by email blasting a bunch of random addresses you purchased - but
a negative reputation certainly can be obtained in those ways and very
quickly, to boot.

What you can do is put yourself out there effectively. If you own a data
center facility, make sure it's listed on the data center map website. If
you provide connectivity, make sure your network has correct information on
peeringdb and other sites where folks like us go for information on
connectivity providers. If you are providing off-site backups, make sure
your website clearly and effectively communicates your pricing model along
with the technology used to do so and your testing methodology and
frequency, for example, as well. That's the sort of information that
legitimate professionals want to see, will search for, and will hence get
you good placement within google results (there's no SEO black magic that
works, either.)

You can of course also purchase advertising space within contexts that your
potential customers are likely to visit.

Good luck!

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.

Re: Outsourced NOC Solutions

[Matt Harris]

On Mon, Jun 8, 2020 at 1:51 PM Miles Fidelman 
wrote:

> And... parenthetically, if a single link failure impacts customers, you're
> network is woefully badly designed.
>
Is that considered true by most leased dark fiber providers? If I'm leasing
a dark fiber circuit from a provider, I generally expect that what I'm
leasing is in fact one [or more] physical strands of fiber - not a somehow
redundant connection. Since he mentioned that this would be a dark fiber
network, I would tend to assume that's the product that he'd be offering.
Indeed, this has also been my experience with other providers, including
very large and relatively smaller ones - when leasing dark fiber, or
subscribing to a DWDM-based service, I'm going to be tied to a single,
specific path and physical disruptions to said path will impact my
connectivity. That's always been my expectation and experience at least -
am I wrong, or has this changed at some point?

- Matt

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.

Re: Router Suggestions

[Matt Harris]

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.
On Tue, Jun 16, 2020 at 9:52 AM Jared Brown  wrote:

> My no-effort quote from last month lists just the box at $13,000. Once you
> are all in the total is that 1.5 multiple Baldur mentioned compared to OP.
>
> However, if you google "mx204 price" the first hit wants very much to sell
> you one for <$11,000. Caveat emptor and YMMV.
>
> Jared
>

Not all MX204's are created equal, however. For edge applications, many
folks will want to go with the -IR model, and the -R model is the
fully-unrestricted one. These will cost substantively more than the base
model which has rib, fib, and vrf limitations enforced.

Client-side information gathering tool

[Matt Harris]

Hey folks,
I was hoping maybe someone could point me in a useful direction here. I'm
looking into software tools (ideally, they'd support Windows, Mac, and
Linux, though Windows is perhaps the only critical one) that can be sent
over to random users with varying (mostly very little) knowledge of how the
internet works to gather a bunch of data that they can then provide to us
to help identify connectivity issues between the client and a chosen
endpoint. IPv4 and IPv6 support are requirements. I've got a lot of clients
with VPN connections of varying sorts running on internet connections of
often very low quality, and sometimes even in places where reasonable
quality doesn't seem to even exist.

Right now, when these users complain, this often means my support folks get
to walk them through downloading winmtr and running that as well as other
command line tools to gather a bunch of other information about their
computer, its connection to their LAN, their LAN configuration as best as
we can tell, and their connection to the greater internet. This is somewhat
cumbersome of a process though. If we could send them something they could
click on and then copy/paste out of or otherwise direct the data to us,
that would save a fair bit of time and also be a lot less patience-grating
on the part of our clients.

Any links to potentially useful tools (commercial or free are both fine)
would be appreciated. The main goal is getting lots of relevant information
to us without having to walk an end-user through lots of steps to do so.
The more relevant data, the better.

Thanks,
Matt

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.

Re: Layer 3 Switches

[Matt Harris]

Cisco doesn't want to sell 2960 series anymore and they made that perfectly
clear to me over the past couple of years. I ended up switching to Juniper
EX gear in places I had been deploying 2960's previously. The EX3400 lineup
is better priced than the newer Cisco stuff, and imho a better value
overall in terms of what you get.

If you stick with Cisco, you'll likely be going with the Cat9200 or Cat9300
series. They're good switches, to be sure, but at the end of the day the
Junipers are just as good and cheaper.

Good luck on your project!


On Mon, Jun 29, 2020 at 10:41 AM Nathaniel Wingard via NANOG <
nanog@nanog.org> wrote:

> I’m looking to replace some access switches (Cisco Catalyst 3750 and
> 3560G). I really just need L2 features (stacking, PoE+, VLAN). I’ve found
> a 2960X that I like, but Cisco is pushing their 9200 series. The only
> downside I see is that the 9200s look to all have Layer 3 features. I’ve
> always shied away from L3 switches when I don’t need the L3 features, but I
> don’t have any solid reason not to just use the switches and turn off the
> L3 features I don’t need. I’m looking for thoughts on this approach.
>
>
>
> Thanks,
>
> Nathaniel
>
>
>
>
>

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.

Re: favorite network troubleshooting tools (online)

[Matt Harris]

Not one specific tool, but I often use various large SP looking glasses to
determine what their routing tables look like when necessary.

RIPE Atlas is another cool project that has also yet to be mentioned.

Cloudflare's RPKI tools may also be of use.


On Thu, Jul 16, 2020 at 9:08 AM Marcos Manoni 
wrote:

> https://stat.ripe.net/ has lots of widgets
> https://stat.ripe.net/widget/list
> http://irrexplorer.nlnog.net/ for detailed IRR info
> (https://bgp.he.net also have some)
>
> El mié., 15 jul. 2020 a las 14:41, Mehmet Akcin ()
> escribió:
> >
> > hey there,
> >
> > I recently have come across this http://ping.pe/ website, I have no
> association with this but it's pretty awesome. This made me wonder what
> other tools out there which I do not know about it.
> >
> > what are your favorite network troubleshooting tools?
> >
> > In addition to ping.pe, I like https://bgp.he.net but would love to
> hear your thought about other tool recommendations as especially the ones
> that are distributed.
> >
> > Mehmet
>

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.

Re: Is there *currently* a shortage of IPv4 addresses?

[Matt Harris]

On Wed, Aug 5, 2020 at 10:17 AM Josh Luthman 
wrote:

> We got a new block from ARIN 12-23-2019 19:40:59.  I remember many that
> were on the list for months to a few years that also got allocated that
> week.
>

There was an influx of available space at ARIN around December/January. We
ended up getting a /23 during that timeframe as well, even though we'd been
buying space from third parties for a couple of years prior to that
exclusively because of ARIN exhaustion. Whether ARIN or other RIRs may have
such an influx again in the future remains to be seen, but it does pay to
be on the wait list just in case that time comes.

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.

Re: 100g PCS Errors

[Matt Harris]

On Wed, Aug 19, 2020 at 9:16 AM J. Hellenthal via NANOG 
wrote:

> Id hope by this point you’ve already reseated not only the card but the
> connection to the card as well ?.
>
> Possibly a faulty card.
>

I'm guessing by card you mean the optic? These are QSFP28 ports.

Clean fiber as Daniel mentioned, reseat optic, the usual stuff. Try
replacement parts you have in stock, then go from there replacing the
cheapest components first before trying to replace the more costly ones.

What manufacturer optic are you using, and what sort of media specifically?

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.

Re: CenturyLink -> Lumen

[Matt Harris]

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.
On Wed, Sep 16, 2020 at 9:31 AM Tom Hill  wrote:

> On 16/09/2020 11:18, Matt Hoppes wrote:
> > Quantum Fiber?  Sounds like a misbranding. I highly doubt they are using
> > Quantum technology.
>
>
> Very prescient for when it becomes commercially possible though, eh? :)
>

How will they know if they have enough slack to patch a cut?

They won't know until they observe it...

Re: Juniper configuration recommendations/BCP

[Matt Harris]

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.
On Thu, Oct 8, 2020 at 5:51 PM Chris Boyd  wrote:

>
>
> > On Oct 8, 2020, at 10:55 AM,   wrote:
> >
> > JunOS is so linux based
>
> Um, my MX-204 says FreeBSD amd64.
>

Junos has always had a large basis coming from FreeBSD way back when.

There's no Linux going on in Junos itself as far as I know, however Juniper
does utilize Wind River Linux as an intermediary virtualization step for
some of their virtualized products like the vSRX.

Re: Securing Greenfield Service Provider Clients

[Matt Harris]

On Fri, Oct 9, 2020 at 2:27 PM Christopher J. Wolff 
wrote:

> Dear Nanog;
>
>
>
> Hope everyone is getting ready for a good weekend.  I’m working on a
> greenfield service provider network and I’m running into a security
> challenge.  I hope the great minds here can help.
>
>
>
> Since the majority of traffic is SSL/TLS, encrypted malicious content can
> pass through even an “NGFW” device without detection and classification.
>
>
>
> Without setting up SSL encrypt/decrypt through a MITM setup and handing
> certificates out to every client, is there any other software/hardware that
> can perform DPI and/or ssl analysis so I can prevent encrypted malicious
> content from being downloaded to my users?
>
>
>
> Have experience with Palo and Firepower but even these need the MITM
> approach.  I appreciate any advice anyone can provide.
>

Do you really want to do this? Ask yourself not whether you want to protect
your users from malicious content, but rather ask yourself do you want to
expose all of their financial, medical, and other personal details to
anyone who may have access (including potentially unauthorized access) to
this system? As a service provider with a customer/user base that you do
not directly control, the answer should almost certainly always be "no."

It's one thing to implement this sort of snooping in an office/corporate
environment: there you have direct control over systems to install MITM CA
certificates, and the ability to set policies like "don't view personal
websites or enter personal financial, medical, or other private details on
a work computer outside of communicating with HR" or somesuch.

Instead, I'd recommend distributing good anti-malware software that
provides endpoint protection for their devices and teaching security best
practices to your users. You can also block access to known-bad hosts and
addresses either at your border via packet filtering, or via the recursive
DNS servers that you feed to clients. This may have the unintended
consequence of false positives resulting in additional support inquiries,
but overall is much better than trying to MITM secure connections from your
customer/user base.

Good luck!

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.

Re: IP tracking system

[Matt Harris]

On Tue, Dec 14, 2021 at 10:12 AM Adam Thompson 
wrote:

> > This may have been asked and answered, but I couldn’t find the answer.
>
> The answer changes every year, anyway.
>
> > What are people recommending these days for IP tracking systems? I’m
> > looking for something to track the used/available IP addresses in my new
> > lab.
>
> FWIW, we use TeemIP/iTop, although I can't say I would recommend it, it
> does work.
>
> We've looked at NetBox, which is quite nice, but getting our data *out* of
> TeemIP/iTop proved to be much more difficult than expected, so we haven't
> migrated yet.  CANARIE (Canadian NREN) and all the subsidiary RANs here are
> adopting NetBox, AFAIK.
>

NetBox is just swell. I've been using it for a handful of years and it has
some great functionality in addition to a very friendly web UI, including
an API you can easily use from tooling to do stuff like auto-generate NAT
configs, DNS zones, DHCP configs, etc.

- mdh

Matt Harris|Infrastructure Lead
816-256-5446|Direct
Looking for help?
Helpdesk|Email Support
We build customized end-to-end technology solutions powered by NetFire Cloud.

Re: Incrementally deployable secure Internet routing: operator survey

[Matt Harris]

Matt Harris|Infrastructure Lead
816-256-5446|Direct
Looking for help?
Helpdesk|Email Support
We build customized end-to-end technology solutions powered by NetFire Cloud.
On Fri, Dec 17, 2021 at 12:51 PM Adrian Perrig  wrote:

> Dear Nanog,
>
> Knowing how challenging it is to apply new technologies to current
> networks, in a collaboration between ETH, Princeton University, and
> University of Virginia, we constructed a system that provides security
> benefits for current Internet users while requiring minimal changes to
> networks. Our design can be built on top of the existing Internet to
> prevent routing attacks that can compromise availability and cause
> detrimental impacts on critical infrastructure – even given a low adoption
> rate. This provides benefits over other proposed approaches such as RPKI
> that only protects a route’s origin first AS, or BGPsec that requires
> widespread adoption and significant infrastructure upgrades.
>
> Our architecture, called Secure Backbone AS (SBAS), allows clients to
> benefit from emerging secure routing deployments like SCION by tunneling
> into a secure infrastructure. SBAS provides substantial routing security
> improvements when retrofitted to the current Internet. It also provides
> benefits even to non-participating networks and endpoints when
> communicating with an SBAS-protected entity.
>
> Our ultimate aim is to develop and deploy SBAS beyond an experimental
> scope. We have designed a survey to capture the impressions of the network
> operator community on the feasibility and viability of our design. The
> survey is anonymous and takes about 10 minutes to complete, including
> watching a brief 3-minute introductory video.
>
>
> https://docs.google.com/forms/d/e/1FAIpQLSc4VCkqd7i88y0CbJ31B7tVXyxBlhEy_zsYZByx6tsKAE7ROg/viewform?usp=pp_url&entry.549791324=NANOG+mailing+list
>
> We thank you for helping inform our further work on this project. We will
> be happy to share the results with the community.
>
> With kind regards
>   Prateek Mittal, Adrian Perrig, Yixin Sun
>

Adrian,
After viewing the video you included, I'm still not sure what SCION is or
how it works (as best I can tell, a bunch of folks get together, share an
AS border, and just do private AS peering with one another inside, then the
shared AS border does the internet advertising of whatever public networks
they wish?), but it sounds like your proposed monolithic new exercise
wouldn't offer much beyond what could be done by allowing folks to get a
default route VPN to a provider that does strict AS border RPKI ROV
already. Can you describe how this would be better or stronger protection
from any given attack than that, in a meaningful enough way as to make it
worth potentially creating massive bureaucracies and new technical systems
which seems to rely on massive networks of VPNs overlaid over the existing
public internet?

- mdh

Re: Request to participate in 2-min study survey on IPv6 Adoption

[Matt Harris]

Matt Harris|Infrastructure Lead
816-256-5446|Direct
Looking for help?
Helpdesk|Email Support
We build customized end-to-end technology solutions powered by NetFire Cloud.
On Sun, Jan 30, 2022 at 7:07 PM Töma Gavrichenkov  wrote:

> Peace,
>
> On Thu, Jan 27, 2022, 4:38 PM Smahena Amakran 
> wrote:
>
>> For my studies, I am researching IPv6 adoption.
>>
>
> For your consideration, there's one thing that's always overlooked.
>
> E.g. I've been talking once to a big employee of a large content provider,
> and that person told me they don't enable IPv6 because doing otherwise
> produces tons of comment spam.
>
> The thing is, we have this spam problem. This is not really the
> "information security issue" you've mentioned, this is just a glimpse of a
> real issue.
>
> IPv6 is now cheap as chips. It's very dirty therefore. All kinds of bots,
> spammers, password brute force programs live in there, and it's
> significantly harder to correlate and ditch these with the sparse IPv6
> address space.
>
> ISPs don't typically focus on these kinds of things but ISPs, speaking of
> large ones, are also typically champions in IPv6 deployment.  It's usually
> content providers who don't do their stuff.  And, as sad as it gets, it's
> not getting away any time soon since it's there for a reason.
>

Have you tried treating a /64 in IPv6 in the same way that you'd treat a
/32 in IPv4 (and thusly, a /32 in IPv6 in the same way you'd treat larger
IPv4 blocks targeting bad provider space, etc?) rather than fighting every
/128? This seems to be a pretty common practice that has worked for others
in dealing with abuse issues on IPv6.

- mdh

Re: VPN recommendations?

[Matt Harris]

Matt Harris|Infrastructure Lead
816-256-5446|Direct
Looking for help?
Helpdesk|Email Support
We build customized end-to-end technology solutions powered by NetFire Cloud.
On Thu, Feb 10, 2022 at 12:03 PM William Herrin  wrote:

> Hi folks,
>
> Do you have any recommendations for VPN appliances? Specifically: I need
> to build a site to site VPNs at speeds between 100mpbs and 1 gbit where all
> but one of the sites are behind an IPv4 NAT gateway with dynamic public IP
> addresses.
>
> Normally I'd throw OpenVPN on a couple of Linux boxes and be happy but my
> customer insists on a network appliance. Site to site VPNs using IPSec and
> static IP addresses on the plaintext side are a dime a dozen but traversing
> NAT and dynamic IP addresses (and automatically re-establishing when the
> service goes out and comes back up with different addresses) is a hard
> requirement.
>

For OpenVPN, I like the Netgate boxes running pfsense. Works great, super
easy integrations with stuff like AC/LDAP/radius/etc for auth, frr and
others for your routing, etc. This is probably your best bet.

For IPSec I tend to stick to Juniper SRX boxes.

Good luck!

ASN in use, but no whois data?

[Matt Harris]

Hey folks,
I'm looking at an ASN 394183 and I can't find any whois or other contact
data. I've checked globally and then also ARIN directly and literally
nothing as if it weren't registered. It's announcing prefixes, at least one
of which is IRR invalid part of a larger old PSINET block, though, and I'm
seeing them in the global routing table.

Anyone have any idea how this could happen where an ASN is in use,
transiting several major providers to the internet, but no whois data as if
it didn't exist?

Thanks,
Matt

Matt Harris|Infrastructure Lead
816-256-5446|Direct
Looking for help?
Helpdesk|Email Support
We build customized end-to-end technology solutions powered by NetFire Cloud.

Re: Juniper vMX Trial - fake news?

[Matt Harris]

On Mon, Mar 14, 2022 at 1:23 PM Daryl G. Jurbala 
wrote:

> The last time I worked with vMX was several years ago.  The image was
> outdated to the point of having to fire up an older version of VMWare to
> export the two VMs so I could import them back into 6.  The
> documentation barely existed.  I had to figure out which vmware adapters
> corresponded to which vMX adapters.  No one really seemed to be able to
> help at Juniper, even though we ended up licensing the things so we were
> "real" customers of this product.
>
> It looked a lot lot an abandoned project.  So unless something has
> changed in the last few years it's not looking good.
>

Interesting. I haven't had an opportunity to try vMX because of its lack of
Hyper-V support, but we do run vSRX in production quite a bit including
junos versions from 17.x up to 21.x. It's kind of janky on Hyper-V but
works overall (the main issue being very very long boot times - 15+ minutes
to get up and running), but we also run it on KVM on Linux with the "vSRX3"
images, and that works a lot better. The vSRX3 images on KVM, I personally
haven't run into any issues with. The licensing costs are pretty
reasonable, too, imho.

Good luck with what you're trying to accomplish: maybe give the vSRX series
a shot if you're running on KVM.

 - mdh

Matt Harris|Infrastructure Lead
816-256-5446|Direct
Looking for help?
Helpdesk|Email Support
We build customized end-to-end technology solutions powered by NetFire Cloud.

Re: FYI - 2FA to be come mandatory for ARIN Online? (was: Fwd: [arin-announce] Consultation on Requiring Two-Factor Authentication (2FA) for ARIN Online Accounts

[Matt Harris]

On Tue, May 24, 2022 at 3:21 PM Laura Smith via NANOG 
wrote:

> Its 2022. Do we really still need a consultation on why mandatory 2FA is a
> good thing ? Even more so for something like ARIN ?
>

While it's probably obvious to most of us that mandatory 2fa is a good
thing, I think it should be likewise clear that community consultation is
also a very good thing as a general practice for changes such as this. A
good example is that several folks in the context of this discussion on the
ARIN-CONSULT list have voiced concerns related to SMS as the secondary
method, and others of us have discussed options which may be superior for a
variety of reasons.

- mdh

Matt Harris|VP of Infrastructure
816-256-5446|Direct
Looking for help?
Helpdesk|Email Support
We build customized end-to-end technology solutions powered by NetFire Cloud.

Re: IPv6 internet broken, cogent/hurricane not peering

[Matt Harris]

[Removing peer...@he.net from this because there's no reason to spam them.]


Matt Harris|VP of Infrastructure
816-256-5446|Direct
Looking for help?
Helpdesk|Email Support
We build customized end-to-end technology solutions powered by NetFire Cloud.
On Thu, Aug 11, 2022 at 9:21 AM VOLKAN KIRIK  wrote:

> the companies are here to trade, charge prices for their services so
> why blame cogent for doing what they supposed to be doing?
>
> why did hurricane stop BGP tunnel service? and started asking for 500
> usd/month for peering? expense of BGP servers? or did they realize ipv6
> prefixes does not cost MRC, so their network peers are not serious business.
>
> why did Google start charging for cloud gigabytes?
>
> if he.net opens free BGP tunnel service back; and also announce full
> transit routes on IXPs, thats just zero (payback)...
>
> if they provide free ip transit to everyone; I would think that cogent
> should provide free network access to them...
>
> if google doesnt charge for traffic in cloud services, then they will be
> largest in my eyes.
>
> if cogent asks for a price, then they have to pay (to become tier1)...
> simple as that. or they could stay as tier-2 as long as they want. thats
> called free as in freedom. not as in price.
>
In reality "tier 1" vs "tier 2" is about as meaningful as not at all. At
the end of the day, building a network has a variety of costs associated
with it. Some folks bury fiber, and some folks lease it from them. Some
folks peer on route servers at popular exchanges, and others don't. When
customers are seeking transit services, they go with a provider who is
on-net where it counts for them, can provide the capacity they need at a
reasonable price, and often also consider quality of that company's
services and reputation.

> *doesnt level3 pay comcast money for paid-peering?*
>
> building eyeball network, enabling fiber connectivity in buildings has
> much more meaning to me...
>
> so honestly i am fine with segmented ipv6 internet. i would just not
> prefer he.net in my IP transit blend, as i do not have to respect crying
> beggars and i could choose telia+cogent.
>
Many folks avoid Cogent for a variety of reasons, but in general their
policies towards congestion and their marketing practices have, at various
times, caused large segments of the community to speak up.

> he.net guys are just charging you money for dumping your traffic in IX
> Points, that you can do yourself, be eyeball or content network..
>
Can you prove in any meaningful way that this is less optimal or even
substantively different from what anyone who provides full table transit
service does?

> btw, losts of useless prefixes... think an asn has 1000 ipv6 prefixes but
> less than 1 ge traffic, while there are networks exceeding 10ge with just
> one prefix. ipv6 nat is spreading. just like ipv4 nat.
>
What? IPv6 NAT? Please provide data to support the claim that substantial
numbers of people are adopting NAT for IPv6?

> could you analyze traffic amount of ASNs? no. then dont fuckin call them
> largest or i will kick your monkey ass.
>
i am the god!
>
This is not appropriate behavior for NANOG's mailing list, imho. I'm not
sure what makes you think utilizing words like this is going to help your
point, but I guarantee it isn't.
And for the record, lots of folks here analyze traffic by AS source.

- Matt

Re: BCP38 For BGP Customers

[Matt Harris]

Hey Charles,
My recommendation would not be to run uRPF facing a BGP customer.

That said, you have two issues to address here: one is the acceptance of
prefix advertisements, and the other is the acceptance of traffic.

uRPF does nothing to help with the former, and the gold standard there is
generally considered to be RPKI. IRR based filtering is another reasonable
way to filter prefix advertisements you receive, and several well-known
IX's and transit providers for example do just this.

The latter, acceptance of traffic, is a broader challenge. In essence, you
don't really have a good way to know what traffic is legitimate and what
isn't. My advice would be simply to watch for things you don't expect, log
them when they occur in significant quantity, and manually review incidents
that are unexpected to understand why. If you cannot understand why, then
you can work with the client sending the traffic to try to understand it,
or block that specific traffic from that specific client. uRPF on a client
circuit raises exactly the issues you've already raised. Many clients, even
smaller ones, who choose to run BGP sessions with transit providers will
wish to be able to employ common TE practices, and by deploying uRPF, you
may very well be creating a nasty situation for them which potentially is
also difficult for smaller shops without high end tooling in place to
diagnose easily.

- mdh


On Mon, Nov 7, 2022 at 1:22 PM Charles Rumford via NANOG 
wrote:

> Hello -
>
> I'm are currently working on getting BCP38 filtering in place for our BGP
> customers. My current plan is to use the Juniper uRPF feature to filter
> out
> spoofed traffic based on the routing table. The mentality would be: "If
> you
> don't send us the prefix, then we don't accept the traffic". This has
> raised
> some issues amongst our network engineers regarding multi-homed customers.
>
> One of the issues raised was if a multi-homed BGP customer revoked a
> prefix from
> one of their peerings, but continued sending us traffic on the link then
> we
> would drop the traffic.
>
> I would like to hear what others are doing for BCP38 deployments for BGP
> customers. Are you taking the stance of "if you don't send us the prefix,
> then
> we don't accept the traffic"? Are you putting in some kind of fall back
> filter
> in based on something like IRR data?
>
> Thanks!
>
> --
> Charles Rumford (he/his/him)
> Network Engineer | Deft
> 1-312-268-9342 | charl...@deft.com
> deft.com
>

Matt Harris
VP OF INFRASTRUCTURE
Follow us on LinkedIn!
matt.har...@netfire.net
816-256-5446
www.netfire.com

Re: 1.1.1.1 support?

[Matt Harris]

Matt Harris
VP OF INFRASTRUCTURE
Follow us on LinkedIn!
matt.har...@netfire.net
816-256-5446
www.netfire.com
On Wed, Mar 22, 2023 at 3:36 AM Saku Ytti  wrote:

> Am I correct to understand that 1.1.1.1 only does support via community
> forum?
>
> They had just enough interest in the service to collect user data to
> monetise, but 0 interest in trying to figure out how to detect and
> solve problems?
>
> Why not build a web form where they ask you to explain what is not
> working, in terms of automatically testable. Like no A record for X.
> Then after you submit this form, they test against all 1.1.1.1 and
> some 9.9.9.9 and 8.8.8.8 and if they find a difference in behaviour,
> the ticket is accepted and sent to someone who understands DNS? If
> there is no difference in behaviour, direct people to community
> forums.
> This trivial, cheap and fast to produce support channel would ensure
> virtually 0 trash support cases, so you wouldn't even have to hire
> people to support your data collection enterprise.
>
> Very obviously they selfishly had no interest in ensuring 1.1.1.1
> actually works, as long as they are getting the data. I do not know
> how to characterise this as anything but unethical.
>
>
> https://community.cloudflare.com/t/1-1-1-1-wont-resolve-www-moi-gov-cy-in-lca-235m3/487469
> https://community.cloudflare.com/t/1-1-1-1-failing-to-resolve/474228
>
> If you can't due to resources or competence support DNS, do not offer one.
>

Saku,
When something is provided at no cost, I don't see how it can be unethical
unless they are explicitly lying about the ways in which they use the data
they gather.
Ultimately, you're asking them to provide a costly service (support for
end-users, the vast majority of whom will not ask informed, intelligent
questions like the members of this list would be able to, but would still
demand the same level of support) on top of a service they are already
providing at no cost. That's both unrealistic and unnecessary. There's an
exceedingly simple solution, here, after all: if you don't like their
service or it isn't working for you as an end-user, don't use it.

On the same token as network operators, it might be nice if
cloudflare's admins were accessible to address potential issues that may
actually be related to legitimate network misconfigurations or other
problems on their end that result in issues resolving some folks' resources
- and I suspect they may in fact be via this list or other similar ones, or
other open resources that are widely available to folks who are in the
know. That said, with regards to any specific case, we don't know whose end
the issue lies on. It's possible that the folks managing the Cypress
government resources have taken steps actively, or passively misconfigured,
their systems in such a way that causes the root problem that you're
pointing out. As I administer neither of the related networks, I can't
speak to this, but I think it's just as likely based on a coin flip that
they are responsible for the issue as it is that cloudflare is responsible
for the issue. On top of that, I suspect getting technology help from a
random government entity may be far less fruitful than even a public forum
would be.

Good luck getting a resolution to your resolution.

Re: Caveat emptor: avoid Inseego 5G products unless you still believe in classful routing

[Matt Harris]

On Tue, Mar 28, 2023 at 2:25 PM Matthew Petach 
wrote:

>
> In the category of "I can't believe I still have to worry about this in
> 2023"
> comes an unfortunate discovery I made recently when setting up a network
> for a local non-profit.  The Inseego FX2000 5G router looked like a nice
> product, it supports OpenVPN out of the box, flexible firewall rules, etc.
>
> What I did *NOT* expect from a device made in 2023, and didn't think to
> ask about ahead of time, is whether it supported classless routing.
>
> Setting the unit up, I discovered the hard way that the developers are
> apparently still working from 1989 textbooks.  The only netmask the
> router will accept for a 10.x.x.x. subnet is 255.0.0.0.  Absolutely
> refuses
> to accept a different length netmask.
>
> Even the user manual reflects the inherent classful assumption:
>
> "
> IPv4
> IP Address: The IP address for your FX2000, as seen from the local
> network. Normally, you can use the default value.
> Subnet Mask: The subnet mask network setting for the FX2000. The default
> value 255.255.255.0 is standard for small (class "C") networks. If you
> change the LAN IP Address, make sure to use the correct Subnet mask for the
> IP address range of the LAN IP address
> "
>
> So, before anyone else makes the same mistake I did, I thought I'd give
> the
> community a heads-up to avoid the Inseego line of 5G products, as they're
> woefully behind the times in their understanding of IPv4 subnetting as it
> exists in 2023.  ^_^;
>
> Thanks!
>
> Matt
>

But how is their IPv6 support? ;)

Matt Harris
VP OF INFRASTRUCTURE
Follow us on LinkedIn!
matt.har...@netfire.net
816-256-5446
www.netfire.com

Re: Aptum refuses to SWIP

[Matt Harris]

On Thu, May 4, 2023 at 9:09 PM Forrest Christian (List Account) <
li...@packetflux.com> wrote:

> I can't speak for aptum, but I'm curious as to why this is important to
> you?   I'm not trying to discount this at all,  just curious why this
> matters in the internet of 2023.
>
> I went through a couple years back and removed all of our mostly outdated
> SWIP data and replaced it with generic information.  But I run an eyeballs
> network and I don't remember the last time we allocated something shorter
> than a /28 to a customer.
>
> I can think of a couple reasons it might be good for the swip to still
> reflect the actual customer.   But most of the ones I can think of don't
> apply as much anymore.   About the only things I can think about which may
> matter has to do with reverse dns delegation if the parent block is smaller
> than a /16 and maybe having specific contact or address information in
> specific circumstances.
>
> Mainly I'm asking to update my personal knowledge of how these records are
> used anymore.
>

Without taking rdns into consideration, a primary use is managing whois
data to enable proper routing of abuse reports. So for an eyeball network,
you probably want those routed to your organization since most of your
customers won't have IT staff capable of dealing with them.

- mdh

Matt Harris
VP OF INFRASTRUCTURE
Follow us on LinkedIn!
matt.har...@netfire.net
816-256-5446
www.netfire.com

Re: BGP routing ARIN space in APNIC region

[Matt Harris]

Matt Harris
VP OF INFRASTRUCTURE
Follow us on LinkedIn!
matt.har...@netfire.net
816-256-5446
www.netfire.com
On Fri, Jun 9, 2023 at 2:49 PM Matthew Petach  wrote:

>
> Hi Mike,
>
> In general, no, there's nothing that prevents you from doing that.
> In days gone by, some networks used to require consistent advertisements
> from a given ASN in all locations in order to peer.
> In your case, that would have made it economically disadvantageous to use
> the same ASN in Makai as California, as you'd end up backhauling a lot of
> traffic.
> These days, consistent advertisement requirements have largely gone by the
> wayside.
> Now, from a network reachability perspective, you should also think about
> your own internal network connectivity.
> If you're using the same ASN in California and Makati, you'll need
> redundant internal network connections between the two countries to ensure
> you don't end up with a partitioned ASN.
> Remember, California won't accept the advertisements from Makati over the
> external Internet, as AS-PATH loop detection will drop the announcements;
> likewise, Makati won't hear the advertisements of the California IP space.
> So, if your network design is a single internal backbone link from CA to
> PH, with an expectation that if the link goes down,  you can just use
> transit providers to reach the other location, you'll be in for an unhappy
> surprise when your backbone link goes down.
> For that reason, many networks find that the cost of acquiring a second,
> distinct ASN for the remote location is considerably lower than the
> headache of trying to ensure the single ASN is never partitioned.
>
> But that's really more from a network design perspective; from a policy
> perspective, there's largely nothing preventing you from doing that.
>
> Best of luck!
>
> Matt
> On Fri, Jun 9, 2023 at 12:28 PM Mike 
> wrote:
>
>> Hello,
>>
>>  I'm certain this must have been covered before but I can't find a
>> lot of good-seeming answers. Essentially, I am a California based ISP
>> and have plans to open up shop in Makati Philippines. I have an ASN and
>> several /22's of ipv4 and a few /44s of ipv6 out of my assigned ranges
>> that I intend (desire) to bring with me. I am just wondering if there is
>> any network policy, filtering, or other reason why I simply couldn't
>> just pop up there advertising my space and away I go? I do have ROA
>> setup with arin already which should otherwise verify/validate me (great
>> tool by the way, thank you).
>>
>>
>> Thank you.
>>
>
I would also note that, from an end-user perspective if we're talking about
ISP services to customers on both ends here, you may run into geolocation
issues where some geolocation providers decide that many/all of your users
are in one location or the other, creating problems for them both with
performance when they are misdirected to the wrong frontend servers, as
well as in terms of convenience if they are being served content in the
wrong location, or service issues related to access to streaming services,
etc.

- mdh

Openstack modules for nx/juniper

[Matt Harris]

Hey folks,
For those of you running/managing/dealing with openstack installations,
would you be so kind as to shed some light on what you're doing for
integrating Juniper and Cisco nexus devices specifically? My goals include
basic stuff like managing vxlan/vni allocation and integration, etc,
managing the ports to which compute nodes are connected, vpnaas, and maybe
some other relatively (imho) basic functionality.

The official juniper neutron plugin is from 2016 and the Cisco stuff isn't
any better. Hoping there's some newer, better option out there that I
should be working with, but if it's actually the case that folks are just
still running just fine with the older modules on modern openstack then
that's fine too. What I really want to avoid is having to hire dev
contractors to write code to deal with this.

Thanks,
Matt

Matt Harris
VP OF INFRASTRUCTURE
Follow us on LinkedIn!
matt.har...@netfire.net
816-256-5446
www.netfire.com

Re: sending again in case Zoom didn't email it correctly

[Matt Harris]

Figures it'd be people from Lawrence.  I'm pretty sure everyone there is
drunk all of the time.  ;)

Although admittedly I only stop in there for drinks when I'm on my way back
from motorsports events in Topeka.  Definitely a nice little town if what
you want is a beer.

Re: Purchasing IPv4 space - due diligence homework

[Matt Harris]

On Wed, Apr 3, 2019 at 10:34 AM John Alcock  wrote:

> Well,
>
> I did all three above and still had issues.  I am still having issues.  I
> had to contact many people to get off of various blacklists, etc.  These
> are lists that are not publish and you will not know until you start using
> the space.
>
> Here is the thing.  You will have problems.  Just be prepared to make lots
> of phone calls and send lots of emails.  Once you get to the right person,
> things can get a moving.
>
> John
>

My experience has been quite different and quite a bit better.  One of the
things I paid attention to was whom the previous owner of the block was,
what sort of company they were, and hence what their likely use case was.
I have purchased/deployed a few /23s so far and have yet to run into any
issues with blacklists.  Some of the space I've purchased came from a
small-town ISP which was acquired, and some came from newly-defunct
retail-sector organizations.  I stayed away from anything that had been
associated with any sort of hosting, or that seemed to have been leased out
in the past, etc.  You can often check historical routing tables to see if
more than one AS has announced the space in the past X number of years to
identify blocks that have been leased around, and that's one other
component you might want to consider looking at.  But ultimately I think my
best tactic has been to just check out the organization I'm acquiring it
from and make sure they've owned it since the beginning via ARIN records.
Dealing with a reputable broker is probably a good start, too.  I've had no
issues working with Hilco.

Good luck!

Re: Facebook (account)

[Matt Harris]

> > On Apr 9, 2019, at 21:05, Nathan Anderson  wrote:
> > a FB page that this account of hers was apparently the only admin for.
> >
>

Redundancy: it's not just a concept to be applied to devices and wiring.

Re: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd)

[Matt Harris]

On Fri, Apr 26, 2019 at 11:28 AM Carlos Friaças via NANOG 
wrote:

>
> Hi,
>
> Just to let everybody know that a petition was started in order to try
> to enable a policy discussion about "BGP Hijacking is an ARIN Policy
> Violation".
>
> If you would like to read the proposal, it is available at:
> https://www.arin.net/participate/policy/proposals/2019/ARIN_prop_266_v2/
>
> Discussions are already ongoing at RIPE and LACNIC.
>
> Best Regards,
> Carlos
>

Hey Carlos,
Can you (or someone else on the list, perhaps even someone who was involved
in voting this down) provide some more details as to why it was rejected?
What were the arguments in favor of rejecting the proposal?  This seems
like an interesting idea to me, and one that I can't immediately come up
with any arguments against from my own perspective.  There's probably some
room for discussing and tuning specifics, but ultimately the concept seems
reasonable to me.  What am I missing here?

Thanks,
Matt

Re: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd)

[Matt Harris]

On Fri, Apr 26, 2019 at 12:49 PM William Herrin  wrote:

> I personally support the petition. I think the out of scope reasoning is
> flawed. By enforcing minimum assignment sizes, ARIN has long acted as a
> gatekeeper to the routing system, controlling who can and can not
> participate. For better or worse, that puts the proposal in scope.
>
> I personally think it's for worse. I oppose the proposal itself. I'd just
> as soon ARIN not act as a gatekeeper to BGP and certain don't want to see
> it expand that role.
>

A couple of things spring to mind here now that I've given this a few more
minutes' thought.  I agree with your reasoning as to why it makes sense for
this to be considered in scope for ARIN.

As far as expanding roles goes... Over the past few decades, we've all
watched as the internet became less and less "wild wild west" and more and
more controlled (sometimes centrally, sometimes in a more or less
decentralized way) by various organizations and entities.   In various and
sundry ways, bad actors could get away with plenty of things in 1990 that
they cannot so easily today.  It may be the case that this problem will be
"solved" in some way by someone, but that "someone" may end up being a less
engaged community or a less democratic organization than ARIN is.
Ultimately, ARIN does a better job than some other internet governance
bodies of promoting stakeholder and community interaction and some degree
of democracy.  We have to consider the question: if some organization is
going to expand into this role, is it better that ARIN be the organization
to do so instead of one which may be ultimately less democratic and more
problematic?

One major problem with the proposal, having given it a couple of minutes
thought, that I can see as of now would be enforcement being dependent on
knowing whom the perpetrator is.  If I decide to announce to some other
networks some IP space owned by Carlos, but I prepend Bill's ASN to my
announcement, how does Carlos know that I'm the bad actor and not Bill?
Having good communication between network operators to determine where the
issue actually lies is critical.  Unfortunately, that doesn't always
happen.  When we talk about leveraging ARIN's authority or potentially
applying penalties of any sort to bad behavior, we have to be able to be
certain whom the bad actor is so that the penalties are not inappropriately
applied to an uninvolved or innocent third party.

Additionally, a question of scope does arise with regard to which resources
ARIN would be able to enforce any such policy with regard to.  Indeed, the
proposal as written currently calls for a "pool of worldwide experts"
despite being a proposal submitted to an RIR which is explicitly not
worldwide in scope.  For example, if a network with an ASN assigned by ARIN
is "hijacking" address space that is allocated by APNIC (or any other RIR)
to an entity outside of ARIN's region, would this be an issue for ARIN to
consider?  What if ARIN-registered address space is being "hijacked" by an
entity with a RIPE ASN and which is not located within ARIN territory?  I
suspect that for this proposal to have any meaningful enforcement
mechanisms, it would require inter-RIR cooperation on enforcement, and
that's a very large can of worms.  Not one that is impossible to overcome,
but likely one which will require several years of scrutiny, discussion,
and negotiation prior to any real world implementation.

Ultimately, I don't think I can support a proposal this vague, either.  For
something like this I think we need a lot more objective language and a lot
more specifics and details.  We must make policies easy to comply with, and
at all costs avoid vagueness which may allow for anything less than
completely fair and objective enforcement - regardless of how simple the
concept may seem to us on the outset.

Take care,
Matt

Re: Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd)

[Matt Harris]

On Fri, Apr 26, 2019 at 4:37 PM Jon Lewis  wrote:

>
> Anecdotally, ARIN has, in the past, gotten involved in this sort of thing.
> Many years ago, during an acquisition that went sour at the last minute,
> the renegging seller went to ARIN complaining that we were hijacking his
> IP space.  ARIN contacted our upstreams and pressured them to pressure us
> to stop advertising the IP space.  Perhaps there's no official policy, and
> perhaps they wouldn't do this today without one?
>

I would argue that action without an explicit official policy that outlines
the circumstances under which what action is taken is just asking for
awkward situations to arise.

- Matt

Google weird routing?

[Matt Harris]

Hey folks,
Looking at an mtr going out via a couple of different transit circuits,
Google seems to be doing weird things.

RTT pinging google.com is coming up with like 250-300ms times, but mtr's
are telling me my packets are hitting google's network very quickly.
Google's network then seems to send them on a rather long trip before
reaching the google.com frontend servers.

An example:

 6  213.200.123.170 (213.200.123.170)  3.450 ms
ae-1-3502.ear4.Newark1.Level3.net (4.69.211.177)  1.469 ms  1.634 ms
 7  72.14.213.34 (72.14.213.34)  1.336 ms  1.372 ms  1.381 ms
 8  108.170.248.52 (108.170.248.52)  2.474 ms *  2.150 ms
 9  216.239.62.170 (216.239.62.170)  1.401 ms 216.239.62.150
(216.239.62.150)  1.400 ms 216.239.62.168 (216.239.62.168)  2.985 ms
10  216.239.57.136 (216.239.57.136)  20.043 ms 216.239.59.0 (216.239.59.0)
 20.235 ms 216.239.57.196 (216.239.57.196)  20.382 ms
11  209.85.254.241 (209.85.254.241)  2.155 ms 108.170.235.61
(108.170.235.61)  74.295 ms 209.85.241.43 (209.85.241.43)  78.593 ms
12  72.14.239.155 (72.14.239.155)  96.254 ms 216.239.57.196
(216.239.57.196)  19.672 ms 72.14.239.155 (72.14.239.155)  96.328 ms
13  108.170.235.217 (108.170.235.217)  153.391 ms 108.170.236.119
(108.170.236.119)  153.445 ms 108.170.235.221 (108.170.235.221)  152.858 ms
14  172.253.51.111 (172.253.51.111)  220.084 ms 66.249.94.141
(66.249.94.141)  218.039 ms 72.14.239.197 (72.14.239.197)  75.008 ms
15  209.85.241.86 (209.85.241.86)  276.281 ms 72.14.235.160 (72.14.235.160)
 276.104 ms  277.497 ms
16  108.170.235.105 (108.170.235.105)  217.030 ms 209.85.248.4
(209.85.248.4)  217.338 ms 66.249.94.141 (66.249.94.141)  217.573 ms
17  72.14.236.75 (72.14.236.75)  276.349 ms  276.097 ms 72.14.239.235
(72.14.239.235)  277.180 ms
18  bom07s01-in-f14.1e100.net (216.58.199.142)  276.139 ms  276.980 ms
64.233.174.27 (64.233.174.27)  279.212 ms

As you can see from this traceroute output, Level3 is delivering my packets
to Google (hop#7 and beyond) just fine, however all of the hops including
#7 and beyond are all inside of google's network.

My packets are originating from AS 394102.

Anyone from google have any idea what's going on there?

Thanks,
Matt

Re: Google weird routing?

[Matt Harris]

On Thu, May 23, 2019 at 2:55 PM Jared Mauch  wrote:

> I would say that it says BOM at the start of the name, perhaps they are
> sending you to India?
>
> Are you using a DNS service that uses ECS facing the various CDN/Cloud
> providers or a different one?
>

This is my thinking, too, however my recursive DNS servers are all on the
same network as the systems trying to reach google, all of which are on IP
space that I own and announced exclusively by AS 394102 here in the US.
I've also taken care to maintain as many geoip service entries as could be
found/maintained, including maxmind's.  Where they would get the idea that
my packets should go to India is beyond me.

On Thu, May 23, 2019 at 3:06 PM Christopher Morrow 
wrote:

> not sure where you are starting from (really) .. can you provide a:
>   dig www.google.com
>
> for me? My guess is that as Jared noted you got somehow looking like
> you are in india to whatever does that magic :)
>

Google's coming back with bom* addresses; no idea why though.

;; ANSWER SECTION:
www.google.com. 300 IN  A   172.217.26.228


Hoping someone over there can shed some light on why they are sending my
packets on a world trip.  :)

Thanks,
Matt

Re: Google weird routing?

[Matt Harris]

On Thu, May 23, 2019 at 3:24 PM Filip Hruska  wrote:

> Google maintains their own GeoIP database. If you peer with them and have
> access to the peering portal, you can correct the location yourself.
> Otherwise they have a public form somewhere.
>
> --- Filip
>

Googling around a bit does not yield results for that form... any chance
anyone here has a link to that?  Would be much appreciated!

Thanks,
Matt

Re: Google weird routing?

[Matt Harris]

On Thu, May 23, 2019 at 3:44 PM Christopher Morrow 
wrote:

> On Thu, May 23, 2019 at 4:11 PM Matt Harris  wrote:
> > On Thu, May 23, 2019 at 3:06 PM Christopher Morrow <
> morrowc.li...@gmail.com> wrote:
> >>
> >> not sure where you are starting from (really) .. can you provide a:
> >>   dig www.google.com
> >>
> >> for me? My guess is that as Jared noted you got somehow looking like
> >> you are in india to whatever does that magic :)
> >
> >
> > Google's coming back with bom* addresses; no idea why though.
> >
> > ;; ANSWER SECTION:
> > www.google.com. 300 IN  A   172.217.26.228
> >
>
> that's an ip in india alright :)
> I don't see why that's happening (in quick searching).
>
> >
> > Hoping someone over there can shed some light on why they are sending my
> packets on a world trip.  :)
>
> I'd be cuirous about:
>   dig www.google.com @8.8.8.8
>
> as well, please (jared's question as well)
>

Interestingly...


user@host # dig www.google.com @8.8.8.8

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> www.google.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2110
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.google.com.IN  A

;; ANSWER SECTION:
www.google.com. 299 IN  A   216.58.203.164

;; Query time: 16 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu May 23 16:55:04 EDT 2019
;; MSG SIZE  rcvd: 59

user@host   # host 216.58.203.164
164.203.58.216.in-addr.arpa domain name pointer bom07s11-in-f4.1e100.net.

Still comes back with a bom* host, so it looks like it's not based on the
DNS recursion server used.

Re: Google weird routing?

[Matt Harris]

On Thu, May 23, 2019 at 4:01 PM Patrick Schultz 
wrote:

> https://support.google.com/websearch/contact/ip/
>
>
Thanks!

Giving that a shot.  It's still loading www.google.com though if I try to
hit it in a browser (not redirecting to a different language/CCTLD specific
site though) so I had to put that in along with that I'm in the US, not
sure that whoever sees that form will understand my issue and there's no
freeform comments section to mention "but it's loading from India!"

Re: Spamming of NANOG list members

[Matt Harris]

On Thu, May 23, 2019 at 4:13 PM Hansen, Christoffer <
christof...@netravnen.de> wrote:

> Appreciate the warning!
>
> On 23/05/2019 19:46, Valerie Wittkop wrote:
> > These messages are not flowing through NANOG servers, nor using the
> NANOG domain. They are not messages coming from the NANOG organization.
> Please be aware if you receive a message matching this description and
> always make sure to scan attachments for a virus.
>
> The one I received looked like this:
>
> > From: "NANOG" 
>
> ...
>
> Has it been considered switching to "-all", instead of only "~all" in
> the spf record?
>
> > $ dig +short +nocmd +nocomments TXT nanog.org
> > "v=spf1 include:_spf.google.com ip4:104.20.199.50 ip4:104.20.198.50
> ip4:50.31.151.75 ip4:50.31.151.76 ip6:2001:1838:2001:8::19
> ip6:2001:1838:2001:8::20 ip6:2400:cb00:2048:1::6814:c632
> ip6:2400:cb00:2048:1::6814:c732 ~all"
>
> -Christoffer
>

The SPF record wouldn't make a difference since that email was sent from @
cegips.pl, not from @nanog.org.  You'd have to change the SPF record for
the cegips.pl domain to impact their ability to send from that address.

Re: someone is using my AS number

[Matt Harris]

On Wed, Jun 12, 2019 at 11:46 AM Carsten Bormann  wrote:

> On Jun 12, 2019, at 18:10, David Guo via NANOG  wrote:
> >
> > Send abuse complaint to the upstreams
> >
> > Get Outlook for iOS
>
> Yes, but which of these is more effective?
>

With some upstreams, I wonder if getting Outlook for iOS might not be just
as effective as contacting them...

Re: SSL VPN

[Matt Harris]

On Thu, Jun 13, 2019 at 12:59 PM Mark Tinka  wrote:

>
> OpenVPN in pfSense?
>
> We run tons of these around the world.
>
> Mark.
>
>
With the client config generator package, "openvpn-client-export",
installed, this is imho the best option for an end-user VPN. pfSense has a
much nicer UI than OpenVPN AS, and that UI also supports other things you
might need (like routing protocols via bird or quagga, managing the
firewall, etc) as well. I can't see any reason to pay money for OpenVPN AS
when you compare it to what you get for free with pfSense.  The NetGate
pfSense appliances are quite nicely spec'd, too, if you just have cash
burning a hole in your pocket.  It also easily ties in OpenVPN
authentication to RADIUS or LDAP, and getting it working with Active
Directory on the backend is trivially simple.

Re: SSL VPN

[Matt Harris]

On Thu, Jun 13, 2019 at 6:12 PM Eric Tykwinski 
wrote:

> This is the second time I’ve seen WireGuard this past week, and honestly
> sounds really promising.
> I’m probably going to test out on VyOS since I know it has support, but
> any word on ASA or JunOS?
> I.E. is this going to export to hardware since it’s in the kernel already?
>

The kernel? Which kernel?

Given that neither Cisco nor Juniper ever adopted support for running
OpenVPN on their platforms, I suspect it's unlikely that they'd adopt
support for Wireguard. I would venture that as far as appliance support,
the best bet is likely to be NetGate and pfSense, but I think Wireguard is
going to have to come out with an "OK, we're comfortable with being
considered production-ready" statement first, given that the front page of
their website right now still proclaims the opposite. Once that happens -
and the ball is largely in Wireguard's court to move that forward - then we
should expect to see more mainstream adoption into products like pfSense.

Re: provider email maintenance standard

[Matt Harris]

On Mon, Jun 17, 2019 at 8:27 AM Martin Pels 
wrote:

> https://www.facebook.com/groups/maintnote/
>

You may want to explain what you're linking to, since that url points to
context which is locked to those of us who are not authorized to view it.
It's very helpful when dropping a link to provide some context, and
especially if the link points to content which is locked behind an
authentication page.

Re: Crowdfunding critical infrastructure

[Matt Harris]

On Thu, Jun 27, 2019 at 10:41 AM Eric S. Raymond  wrote:

> The members of this list are, I think, much more aware tham most that
> a lot of critical Internet software is maintained by unfunded
> volunteers, and of the systemic risks that result from this.
>
> I'm attacking the problem at the root, applying what the Internet has
> taught us about decentralization and avoidiing single poimts of
> failure. In part because I'm currently struggling with medical bills
> (nothing life-threatening, just ankle surgery) but I've been worrying
> about the larger problem for a decade.
>
> Please read http://loadsharers.net
>
> Of course I would like everyone on here to take the pledge and spread
> the word in technical communities where they have influence. But
> beyond that, there are several members of this list who are clearly
> qualified to join as advisers. We're going to need that as the
> Loadsharers network scales up.
>

Interesting concept, and seems like a good idea. What's the end goal look
like? Encouraging folks to contribute to specific individuals directly may
be a little more difficult though, compared to, say, getting a legitimate
organization going that provides (likely objectively-determined
merit-based) payouts to the sort of folks you're talking about. Is that on
the table, or is the goal more to just encourage direct payments from one
individual to others?

I think many of us assume that doing the sort of work you're referring to
will definitely result in the regular receipt of many prestigious,
high-paying job offers. If that's not the case, maybe something else we can
do is to help find full-time employment/funding for folks who contribute
and need it.

Hope your ankle's feeling better soon!

Re: Crowdfunding critical infrastructure

[Matt Harris]

On Thu, Jun 27, 2019 at 11:32 AM Tom Beecher  wrote:

> Encouraging folks to contribute to specific individuals directly may be a
>> little more difficult though, compared to, say, getting a legitimate
>> organization going that provides (likely objectively-determined
>> merit-based) payouts to the sort of folks you're talking about.
>>
>
> Adding an organization in front of that whose sole reason for existence is
> to decide who gets what % of the money doesn't make a lot of sense, mostly
> because it is just creating another layer of people who are then going to
> feel entitled to be compensated for taking the time to decide who should be
> compensated.
>

I don't think anyone needs to be compensated for that. I think that you can
certainly run a volunteer organization. The time required would be minimal
enough that normally-employed folks could participate without issue in
managing it. Having that tax deductible status, in the US at least, would
be a big benefit and would also bring in institutional/corporate donors and
the like as well. Non-profits have been run for making infrastructure
software before and have been at least somewhat successful. ISC is an
example of this. Something a bit more decentralized could work just fine,
too, imho.

As far as just asking people to give to others at random, I think you'll
see less uptake and potentially issues with parity (for example, if you add
worthy folks to a list, those at the top of the list will likely benefit
more from random contributors just because they select those at the top of
the list - so how do you decide who gets to be where on such a list?), and
little if any interest from institutional/corporate donors. A formal
organization structure with rules written down in public also helps to
ensure transparency and if you set objective, meritocratic rules for the
disbursement of funds and you keep things transparent around them, I think
that would attract a lot of contributions.

Just my opinions, though.

Re: Ideas to products (Shark Tank(-ish) @ Austin)

[Matt Harris]

On Sat, Jun 29, 2019 at 11:35 AM Mehmet Akcin  wrote:

> Great point ;-) thanks Tom
>
> On Sat, Jun 29, 2019 at 09:29 Tom Daly  wrote:
>
>> Mehmet,
>>
>> Good idea, the opportunity for innovation and supporting ideas of others
>> in our operator groups is important, but NANOG is probably the wrong venue.
>>
>> Have you considered NANOG's 501c3 not-for-profit status in your analysis
>> of bringing this idea to the community? As a presenter, how would one
>> protect his/her intellectual property being shown to the proposed "sharks"
>> and/or the audience? (would an audience be permitted in the room?)
>>
>> I can't speak for the NANOG Board nor the Program Committee, but as an
>> interested party in NANOG's 501(c)3 not-for-profit status, I am pretty
>> certain this activity would jeopardize our recognized exemption with the
>> IRS. I think this is an important detail you explore before proceeding.
>>
>
As someone who had dealt with non-profit management many times and served
on several non-profit entity boards of varying sorts, I don't see any issue
here at all with simply hosting such an event. As long as NANOG handles the
procedes from the event properly, there should be no issue. In fact, there
are 501(c)3 organizations which exist with a primary goal very similar to
this: connecting investors with potential investments. Check out Code2040,
the Techstars Foundation, and Change Catalyst, among others.

I'd like to hear why you feel this sort of event may cause an issue or
jeopardize NANOG's tax status. Can you be a bit more clear about why you
are concerned about this? Perhaps there's something I'm overlooking.

As far as intellectual property goes, it would of course be up to the
presenter how much they would want to share publicly. Not all intellectual
property is a "trade secret", plenty is covered by copyrights and patents
and can generally be shared with an audience without granting said audience
unlimited rights to that intellectual property. For example, just because
you attend a concert with a particularly performer does not mean you then
have rights to illegally download that performer's mp3s. Of course anyone
who does treat their work product as a trade secret would not share such
work product with any audience. If a presenter did wish to share additional
information with the "shark"/investor participants above and beyond what is
shown to the general audience, they could establish non-disclosure
agreements with the interested parties. NDA's between potential investors
and recipients of investments are extremely common. This would of course be
between the presenter and their attorney to determine the appropriate
course of action and to draw up any relevant documents. Any time anyone is
considering accepting an investment in their work product, I would very
highly recommend that they engage an attorney whom they trust in order to
vet any agreements and ensure that they fully understand all ramifications
thereof.

Good luck folks!

Re: Level3/CenturyLink IRR Contact

[Matt Harris]

On Mon, Jul 8, 2019 at 11:20 AM Joe Nelson  wrote:

> Does anyone know who to contact to have old information removed from
> Level3/CenturyLink's IRR.  My ASN still shows in their registry with stale
> information from an old customer of theirs but I can't seem to find anyone
> at CenturyLink that even knows what an IRR is so I'm just going in
> circles.  I'd like to just have the stale info removed so when I add my
> info to Merit, there isn't a conflict.
>
> Thanks,
>
> Joe
>

Same issue here. Was never able to get anyone to correct it after trying a
solid handful of email contacts there.

What's weird is that the entry was created while I owned the space and was
created by a large enough organization that I'm not sure it's fraud (plus
they've never tried announcing the space that I've seen) but I don't see
how it'd have been a typo based on the space they are announcing, so I'm
not sure exactly what the people involved were thinking. My IPv6 /32 is in
the Level3 IRR db though, with an origin set to AS22773 which is an
organization I've never had any relationship with whatsoever.

Good luck!

Re: Antennas in the data center

[Matt Harris]

On Thu, Jul 18, 2019 at 8:01 AM Robert Webb  wrote:

> Anyone out there deal with data center design?
>
> Looking for any info available which provides guidelines on putting
> antennas, like LTE booster, in the data center.
>

Not quite sure what you're looking for here Robert. As far as placing
something like an LTE booster in a data center, you'd just use common sense
(place it in the best possible place from a connectivity standpoint). Is
this something you're considering in order to provide service to folks who
run LTE backup connections on their gear (like serial concentrators)?
Wireless/RF site surveys and how to do them effectively are pretty
well-documented at this point.

Or are you asking about roof access/deploying antennas on a rooftop
safely/securely?

Re: Antennas in the data center

[Matt Harris]

On Thu, Jul 18, 2019 at 8:30 AM Robert Webb  wrote:

> So I have a situation where I am trying to get LTE to an out of band
> router and there is no signal available in the data center. There was a
> booster setup purchased and I have a manager telling me that standards,
> industry and not local, prohibit the installation.
>
> He has yet to produce any documented industry standard so I thought I
> would reach out to see if anyone here has heard of this.
>
> We fall under NIST controls and I haven't found anything there and have
> also looked at TIA and not found anything.
>

I've never heard of any industry standard preventing such a thing. There
are a few questions this raises though. The first and most obvious being,
are you sure that a "booster setup" will actually help? Have you done a
site survey to figure out how to actually accomplish what you need to
accomplish? The other question is whether perhaps the issue he has is with
the specific "booster setup" chosen. Perhaps there's something naughty
about it, in particular, that has caused him to not want it in his facility
(cheap Chinese radios are known, for example, for polluting the spectrum
outside of the frequencies that they are designed to operate within.) Maybe
he has other folks doing legit RF stuff in there and doesn't want to risk
that pollution?

Re: 44/8

[Matt Harris]

On Thu, Jul 18, 2019 at 10:45 PM William Waites  wrote:

>
> Then we can decide, openly and transparently, if, for example, some piece
> of
> 44/8 should be returned to IANA for allocation to the RIRs.
>

This sounds like the more correct answer with regard to what should be done
with space that isn't and is probably never going to be used that is
allocated to a community organization.

After reading the analogy above regarding spectrum space, I shudder to
think what the community response would be if the FCC were to tacitly allow
the ARRL to receive several million (or billion in this case) dollars from,
say, Verizon in exchange for some part of our exclusive amateur bands.
Indeed the ARRL has a fund (the "Spectrum Defense Fund") with the purpose
of employing lawyers and public policy folks to help prevent our community
resources from shrinking out from under us.

73's - K1RIN

Re: 44/8

[Matt Harris]

On Fri, Jul 19, 2019 at 9:38 AM Brielle  wrote:

>
> > On Jul 19, 2019, at 6:03 AM, John Curran  wrote:
> > Be specific in your report regarding what change you believe was in
> error and why – we investigate all such reports and will correct any
> changes made in error.
>
> Actually, I’d love to hear an official statement from ARIN about the state
> of this transfer - it’s legitimacy, ARINs involvement with it, who approved
> of the transfer (if any) etc.
>

That would be an interesting read.


> Was ARIN not involved?  If not, why not?  44/8 isn’t like a normal
> assignment.  It’s a legacy assignment likely with stipulations from when it
> was originally assigned to the HAM group(s).
>

So my understanding based on what Job has said in this thread, without
looking myself, is that it seems as though 44/8 was brought under an ARIN
RSA either as part of this deal or as a pre-requisite to this deal
happening. Hence it's no longer "legacy" space that isn't covered by an RIR
RSA but is instead now covered by an ARIN RSA.

This is interesting because amateur radio is a global (and beyond - the
folks on the ISS participate!) pursuit, one which is officially sanctioned
by almost every national government in the world, and which has
international involvement overseen by the ITU (
https://life.itu.int/radioclub/ars.htm).

A /8 is an exceptionally large IPv4 block, and governance thereof, when
held in trust for the benefit of a greater community, should always be
transparent. At the very least, we must admit that there was a tremendous
failure of transparency here.

- Matt (K1RIN)

Re: 44/8

[Matt Harris]

On Fri, Jul 19, 2019 at 9:54 AM John Curran  wrote:

>
> As stated before, ARIN did receive and process a request from the 44/8
> registrant to transfer a portion of the block to another party.
>
> For all transfer requests, we review and confirm:
>
> - That the source of the transfer is the legal entity which holds the
> rights to the address block in the registry
> - That the transfer is authorized by an registered officer of that legal
> entity
> - That the recipient org has approval per policy to receive an address
> block of the appropriate size
>
> You may have other questions that are better referred to the registrant
> (Amateur Radio Digital Communications); e.g. regarding why the request was
> made –
> I will note that the contact information for the block is current in the
> Whois database, and available at <
> https://search.arin.net/rdap/?query=44.0.0.0>
>

Hey John,
I think perhaps the relevant questions for ARIN here are:

1> How did the organization currently holding the rights to the 44/8 block
come to hold those rights, and how did ARIN verify that it held those
rights?
2> Did ARIN ensure that the establishment of an ARIN RSA for the 44/8 block
did not violate any prior agreements related to the stewardship of the 44/8
block? If so, how was this done?
3> What were the terms under which the rights to the 44/8 block was held by
said organization prior to the establishment of an ARIN RSA?
4> When was an ARIN RSA established which covered the 44/8 block?

The bigger question here is how we got to the point where an organization
with virtually no transparency came to hold the legal rights to a community
asset without any sort of oversight or contractual obligations with regard
to management of said resource. Ultimately that means figuring out if the
legacy agreements by which 44/8 was held by the organization did indeed
include encumberences on the sale or transfer of the space (which would
make sense, if I am giving stewardship of a large community asset to an
organization, I'm going to include stipulations about what they can't do
with it, and selling it to a for-profit entity for cash is going to be #1
on that list.)

Thanks,
Matt

Re: 44/8

[Matt Harris]

On Fri, Jul 19, 2019 at 10:29 AM John Curran  wrote:

>
> Matt -
>
> Chris is correct.   Those who received IPv4 address blocks by InterNIC (or
> its predecessors) prior to the inception of ARIN on 22 December 1997 are
> legacy resource holders, and continue to receive those same registry
> services for those blocks (Whois, reverse DNS, ability to update) without
> any need for an agreement with ARIN.  This has been provided without any
> fee to the original registrants (or their legal successors) as recognition
> of their contributions to the early Internet.
>

Hey John, I understand that, however my understanding is that the
establishment of an ARIN RSA is required prior to the transfer of a block
or a portion or a block via ARIN (such as the transfer of 44.192/10). Thus,
this would mean that the 44/8 block is now governed by an (well, more than
one, now that it's split) ARIN RSA (or LRSA) whereas it was not before.  Is
that not correct?

Thanks!

Re: 44/8

[Matt Harris]

On Fri, Jul 19, 2019 at 10:41 AM John Curran  wrote:

> On 19 Jul 2019, at 11:34 AM, Matt Harris  wrote:
>
> Hey John, I understand that, however my understanding is that the
> establishment of an ARIN RSA is required prior to the transfer of a block
> or a portion or a block via ARIN (such as the transfer of 44.192/10). Thus,
> this would mean that the 44/8 block is now governed by an (well, more than
> one, now that it's split) ARIN RSA (or LRSA) whereas it was not before.  Is
> that not correct?
>
>
> Matt -
>
> ARIN doesn’t discuss details of specific registrations publicly; you need
> to refer any such questions to the registrant.
>

Without discussing any specific registration whatsoever, my understanding
is that what I stated is the case as a matter of policy. Was just looking
for confirmation that my reading of ARIN policy docs was not incorrect. :)

Thanks!

Re: 44/8

[Matt Harris]

On Mon, Jul 22, 2019 at 2:47 PM John Curran  wrote:

>
> In which case, I’d recommend contacting Hank Magnuski to obtain
> documentation of your particular interpretation, as there are no published
> policy documents which indicate anything other than an allocation from the
> general purpose IPv4 space for an "amateur packet radio" research network
> (and in particular nothing that would indicate that stewardship over the
> allocation should rest with any party other than the assigned contact for
> the block.)
>

I would point out here that "stewardship" and "ownership" are two very
different things. "Stewardship" refers to the day to day care and feeding
of something and generally does not confer the right to dispose of that
thing. An example might be amateur radio spectrum. The ARRL is given some
degree of stewardship over our spectrum here in the US, which is a
community resource issued by the powers that be (globally the ITU, and in
the case of the US specifically, the FCC) for those who take the time to
get licensed. They can set limitations on its use, but they cannot sell it
to Verizon. Thus, the ARRL is a steward of our amateur spectrum, which is
not "owned" by any entity but rather is held in trust as a community
resource by the FCC which allows for stewardship of that resource by the
ARRL.

Ownership would, of course, infer the right to dispose of that thing,
including by selling it in whole or in part to a third party.

Re: 44/8

[Matt Harris]

On Tue, Jul 23, 2019 at 10:05 AM Nathan Brookfield <
nathan.brookfi...@simtronic.com.au> wrote:

> Yeah because v6 only is the answer plus tour assuming all of these clubs
> have routers and BGP and the money to get an allocation and ASN
>

If any amateur radio folks want to use a v6 block that's been allocated to
them for amateur radio/digital comms/etc purposes, there are probably
plenty of folks who already have routers/bgp sessions/ASNs who'd be happy
to announce their space for them at no cost. If someone doing so were to
ask me nicely, I really can't think of a reason not to. It doesn't really
cost me anything and no one's pushing enough traffic on ham bands to amount
to enough to even think about the bandwidth usage under most circumstances.
There's plenty of overlap between hams and people who want to support the
hobby, and network operators with resources to spare. And if things don't
work out, since it's your own space, you can take it and go elsewhere if
needed - it can't be sold out from under you.

Additionally, one can run their own bgp with extremely inexpensive gear
these days. Ubiquiti's edgerouters will do it (around $100 USD), or a
whitebox running pfsense or any number of other FOSS operating systems. You
don't need multiple full tables from several providers plus a half-dozen IX
sessions to announce a /48 for ham radio use. That same low-cost gear can
tunnel the space to wherever you need it, too, if needed. Remember, we're
almost always talking about very very low bandwidth applications here on
amateur spectrum.

Re: Estimated LTE Data Utilization in Failover Scenario

[Matt Harris]

On Wed, Jul 31, 2019 at 9:21 AM Shaun Dombrosky 
wrote:

> Good Morning,
>
>
>
> First time NANOG poster, apologies if I breach etiquette.
>
>
>
> Does anyone have any first-hand data on how much data a small-medium
> business (SMB) can expect to consume in a failover scenario over a 4G/LTE
> connection?  Retail, under 50 head count, using PoS, maybe cloud accounting
> software, general internet activity, 8 hour time period.  Wonder if anyone
> is using a Cradlepoint or SD-WAN solution that could pull a few quick
> numbers from a dashboard for me.  I haven’t had much luck in my searches.
>
>
>
> Appreciate any info anyone can provide.
>
>
>
> Thanks,
>
>
>
> *Shaun Dombrosky*
> *Data Network Engineer*
>
>
>
>
>
> E: sdombro...@blackfoot.com
>
> *www.blackfoot.com <http://www.blackfoot.com/> *
>
>
>
> Stay connected with Blackfoot:
>
>
>
> [image: cid:image001.png@01D2A238.12101D80]
> <https://www.facebook.com/GoBlackfoot/?utm_source=Outlook&utm_medium=Sig&utm_name=2017EmpSig&utm_content=Social>
> [image: cid:image002.png@01D2A238.12101D80]
> <https://www.linkedin.com/company/blackfoot-telecommunications-group/?utm_source=Outlook&utm_medium=Sig&utm_name=2017EmpSig&utm_content=Social>
>   [image: cid:image003.png@01D2A238.12101D80]
> <http://www.twitter.com/GoBlackfoot/?utm_source=Outlook&utm_medium=Sig&utm_name=2017EmpSig&utm_content=Social>
>   [image: cid:image004.png@01D2A238.12101D80]
> <https://www.youtube.com/BlackfootTelecom?utm_source=Outlook&utm_medium=Sig&utm_name=2017EmpSig&utm_content=Social>
>
>
>
>
>
> *This e-mail and any files transmitted with it are confidential and are
> intended solely for the use of the individual or entity to which they are
> addressed.  If you are not the intended recipient or the person responsible
> for delivering the e-mail to the intended recipient, be advised that you
> have received this e-mail in error and that any use, dissemination,
> forwarding, printing, or copying of this e-mail is strictly prohibited. If
> you have received this e-mail in error, please immediately reply to the
> sender by email notifying them of the error and delete the original and
> reply copies. Thank you.*
>
>
>


-- 
Matt Harris - Chief Security Officer
Security, Compliance, and Engineering
Main: +1-816-256-5446
Mobile: +1-908-590-9472
Email: m...@netfire.net

Re: Estimated LTE Data Utilization in Failover Scenario

[Matt Harris]

On Wed, Jul 31, 2019 at 9:21 AM Shaun Dombrosky 
wrote:

> Good Morning,
>
>
>
> First time NANOG poster, apologies if I breach etiquette.
>
>
>
> Does anyone have any first-hand data on how much data a small-medium
> business (SMB) can expect to consume in a failover scenario over a 4G/LTE
> connection?  Retail, under 50 head count, using PoS, maybe cloud accounting
> software, general internet activity, 8 hour time period.  Wonder if anyone
> is using a Cradlepoint or SD-WAN solution that could pull a few quick
> numbers from a dashboard for me.  I haven’t had much luck in my searches.
>
>
>
> Appreciate any info anyone can provide.
>
>
>
> Thanks,
>

Hey Shaun,
I'd recommend pulling that data from the device normally facing their
internet connection. Does it support netflow or even just basic snmp
statistics that you could graph? Ostensibly the traffic level would be the
same regardless of whether using an LTE backup connection or the primary
internet connection unless you somehow prohibited certain traffic when on
LTE. Ultimately though, your best bet is going to be to get real stats over
the course of a couple of weeks and then you'll understand better the
traffic patterns based on time of day, day of the week, etc, as well, as
this is likely relevant.

Good luck!

Re: Help needed configure a server

[Matt Harris]

Hi Peter,
I might suggest that you start at the beginning, perhaps with google or
some classes - either something in person, or maybe just some introductory
videos online that discuss entry level IT topics.

As far as recommended hardware, a raspberry pi may be a quick, inexpensive
way to get started.

Good luck!


On Thu, Aug 1, 2019 at 12:48 PM peter agakpe  wrote:

> I am a newbie trying to configure and put a home server online as starter
> project.  with some help. Specifically, dns server specifics, port
> forwarding, recommended hardware and software, such as router, dns server,
> security, etc. I would greatly appreciate any help.
>
>
>
> Thanks
>
> Peter
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>


-- 
Matt Harris - Chief Security Officer
Security, Compliance, and Engineering
Main: +1-816-256-5446
Mobile: +1-908-590-9472
Email: m...@netfire.net

Re: What can ISPs do better? Removing racism out of internet

[Matt Harris]

On Sun, Aug 4, 2019 at 10:41 PM Mehmet Akcin  wrote:

> What can we do better as network operators about hate sites like 8Chan?
>

What is a "hate site" and who gets to decide what constitutes a "hate
site"? These are the most dangerous questions of our time, because once we
begin sliding down the slippery slope of unbounded, subjectively-determined
censorship, we may find that we don't agree with what all is being
censored. To make this point perhaps more saliently, the vast majority of
regimes worldwide that engage or have engaged in censorship have done so
primarily in order to quell dissent against their policies and leaders. We
could implement a "great firewall" much like China has, but how long would
it be before it was viewed as a useful political tool to silence
opposition?

Could you imagine one side determining that any content related to,
perhaps, safe access to abortion, is counter to their ideal society and
hence "too dangerous" to allow the citizenry to view? Could the other side
then determine just as easily that content related to, say, gun rights is
objectionable and dangerous, also?

In my humble opinion, no one can or should be trusted with that sort of
power, and that is why we have the first amendment in the US constitution.


> I applaud cloudflare’s (perhaps slightly late) decision on kicking 8chan
> off its platform today after El Paso attack.
> https://blog.cloudflare.com/terminating-service-for-8chan/
>

Cloudflare is a private entity and can host or not host whatever it wants,
of course.


> I am sure there are many sites like this out there, but could network
> operators do anything to make these sites “not so easy” to be found,
> reached, and used to end innocent lives?
>

Websites can't end innocent lives; only actions taken offline by their
participants can do that. Having all of these sites online and as
in-the-open as possible has a benefit of allowing law enforcement to
monitor activity therein through legal means which allow for oversight and
due process, US constitutional concepts which protect all of us from
potential abuses of power. If we as operators wish to help prevent crimes
and violence, then we should foster good relationships with law
enforcement, and inform them of anything that we notice which may be
related to the commission of or threats of violence. They can then follow
prescribed paths which protect everyone involved to determine whether
enforcement action is necessary/possible without violating anyones' rights.
I'm not claiming the system is perfect, of course, but I don't think
anyone's going to do a whole lot better.

There is no perfect system. Bad people can and will still do bad things.
The best that we each can do is to be aware of our surroundings at all
times both online and off, and protect ourselves, our families, our homes,
and our communities.

- Matt

Re: syn flood attacks from NL-based netblocks

[Matt Harris]

On Fri, Aug 16, 2019 at 5:05 PM Jim Shankland  wrote:

> 1. Rate seems too slow to do any actual damage (is anybody really
> bothered by a few bad SYN packets per second per service, at this
> point?); but
>

Common technique used by port scanners to evade detection as a DoS attack
by fw/ids/etc.

2. IPs/port combinations with actual open services are being targeted
> (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs
> with those services running), implying somebody checked for open
> services first;
>

Or they're just checking if certain common ports are open with the
intention of later trying known exploits against those which are reachable
in order to attempt to compromise the hosts. Build the DB of reachable
hosts/ports now, come back with exploits later.

3. I'm seeing this in at least 2 locations, to addresses in different,
> completely unrelated ASes, implying it may be pretty widespread.
>

Sounds like a relatively common pattern though.

Is anybody else seeing the same thing? Any thoughts on what's going on?
> Or should I just be ignoring this and getting on with the weekend?
>

I wouldn't worry too much about it unless you have reason to believe some
of the likely-forthcoming exploits may actually work. Of course, if that's
the case, you should fix them anyhow.

Have a good weekend!

Re: BGP Enabled transit in Chicago (River North) and equipment recommendation

[Matt Harris]

On Tue, Sep 3, 2019 at 12:44 PM ADNS NetBSD List Subscriber 
wrote:

>
> Also, we’d like to ditch our 3640 router in favor of a smaller “desktop”
> size router, but none of them seem to do BGP (not surprising).  Any
> recommendations on hardware would be welcome as well
>

I can think of lots of smaller, even desktop sized routers that have no
problem doing BGP assuming you're only taking a single transit circuit and
only accepting a default route from your upstream provider. Ubiquiti's
tiniest EdgeRouters which cost around $100 will do BGP just fine under
those circumstances if you're not pushing tons of traffic or pps. If you
want something a little nicer/fancier, you can get a Juniper SRX (probably
a 300, 320, or 345 depending on how much bandwidth you're going to use). If
you want to run multiple transits and take full tables, then at that point
I'd recommend going a bit bigger: maybe a Juniper MX or a Cisco ASR. But
even the higher-end Ubiquiti EdgeRouter series products can handle full
tables if you understand and accept their limitations in doing so if budget
is a huge concern but you still need to take full tables.

Take care,
Matt

Re: This DNS over HTTP thing

[Matt Harris]

On Tue, Oct 1, 2019 at 8:22 AM Stephane Bortzmeyer 
wrote:

> On Tue, Oct 01, 2019 at 12:11:32PM +0200,
>  Jeroen Massar  wrote
>  a message of 101 lines which said:
>
> >  - Using a centralized/forced-upon DNS service (be that over DoT/DoH
> >  or even plain old Do53
>
> Yes, but people using a public DNS resolver (of a big US corporation)
> over UDP is quite an old thing and nobody complained. I really wonder
> why there was so little reaction against OpenDNS or Google Public DNS
> and suddently a lot of outcry against DoH...
>

Mainly because no one was ever forcibly-defaulted to those, while browser
makers are now going to be defaulting to sending queries to a specific set
of DoH servers not set by dhcp/etc locally, but rather chosen by the
browser maker, in a way that most users won't even realize/notice, hence
allowing the browser maker to determine who gets to see the queries the
user is making while surfing the web in that browser. This is a major
change from how browsers and other applications have historically behaved,
where DNS servers were set either locally on the host, or via dhcp or
somesuch at the LAN level. This change will almost certainly be made
without the user explicitly consenting to it.

Effectively, there is no outcry against DoH. There is outcry against how
some browser makers are implementing some configuration changes. It
wouldn't matter what protocol they were using, even if they simply skipped
local/LAN resolver configs and went straight to udp/tcp 53 on their chosen
servers for recursive queries.

Browser makers rule the world in a number of ways already, like choosing
which TLS root certificates to include, and setting default search engines
and settings (sometimes on update, even overriding explicit user settings,
as was the case when Firefox switched to a paid arrangement with Yahoo.)
There's a lot of potential for abuse here, and so oversight in the form of
"outcry" seems entirely justified when such changes occur.

Re: IPv6 Thought Experiment

[Matt Harris]

On Wed, Oct 2, 2019 at 11:33 AM Antonios Chariton 
wrote:

> Dear list,
> First of all, let me apologize if this post is not allowed by the list. To
> my best interpretation of the guidelines [1] it is allowed, but may be in a
> gray area due to rule #7.
>
> I would like to propose the following thought experiment about IPv6, and I
> would like your opinion on what you believe would happen in such a case.
> Feel free to reply on or off list.
>
> What if, globally, and starting at January 1st, 2020, someone (imagine a
> government or similar, but with global reach) imposed an IPv4 tax. For
> every IPv4 address on the Global Internet Routing Table, you had to pay a
> tax. Let’s assume that this can be imposed, must be paid, and cannot be
> avoided using some loophole. Let’s say that this tax would be $2, and it
> would double, every 3 or 6 months.
>

By virtue of depletion at the RIRs, there's effectively already a one-time
IPv4 tax, the cost of procuring the addresses. This has indeed increased
over time, and eventually we will reach a point where for many
organizations acquiring IPv4 address space is not realistic either because
they cannot afford it or (if you look at someone like AWS/Azure/etc who
blow through lots of addresses) just won't be able to acquire the scale
they need. This is happening on its own.

IPv6 deployment is happening, albeit slowly. Mobile providers are
increasingly using IPv6 traffic to avoid having to push more CGNAT gear,
consumer and small business ISPs are getting on board bit by bit, and while
there may have been some point a bunch of years ago in looking into ways to
speed adoption prior to the RIR depletion situation that we're now faced
with, I'm not sure there's any meaningful benefit to trying to artificially
push things forward at this point.

Re: IPv6 Thought Experiment

[Matt Harris]

On Wed, Oct 2, 2019 at 11:48 AM Dovid Bender  wrote:

> Antonios,
>
> It's certainly financial but it's not just companies being cheap. For
> example for smaller companies with a limited staff and small margins. They
> may want to have v6 everywhere but lack the resources to do it. It would
> for certain speed up the process but there would be collateral damage in
> the process.
>

For a small organization with limited staff and small margins, I'm curious
where the actual burden in supporting IPv6 lies. In my experience, it's not
any more costly than deploying IPv4 is (and really, less so over the past
couple of years since you can get IPv6 RIR allocations while adding IPv4
capacity means shelling out thousands or tens of thousands of capex
dollars.) I've never had an IX or transit provider or anyone else charge me
more because I'm running IPv6 in addition to my IPv4, and any gear that
doesn't support IPv6 at this point is likely old enough to be EoL and
requiring replacement due to potential (major, very costly) security issues
anyhow.

Re: IPv6 Pain Experiment

[Matt Harris]

On Wed, Oct 2, 2019 at 3:46 PM John Levine  wrote:

> In article  rcjz0hb1bcq2zy1hsdyosn...@mail.gmail.com> you write:
> >For a small organization with limited staff and small margins, I'm curious
> >where the actual burden in supporting IPv6 lies. In my experience, it's
> not
> >any more costly than deploying IPv4 is ...
>
> Right, but that means it doubles your deployment costs since IPv4
> isn't going away any time soon.  First you have to get IPv6 into your
>

I'd strongly disagree that it anywhere near doubles costs. Ultimately
you're buying hardware X and it's going to cost whatever it costs. So what
more do you really need to do to support IPv6? Well, let's say you're using
OSPF. This means you'll also need to use OSPFv3, but that's not hard
because your OSPFv3 configs are going to basically mirror your OSPF
configs. You'll need to run IPv6 over iBGP, perhaps, and over eBGP to your
peers and transits, but that's just another set of addresses bound to
interfaces, sessions that mirror the IPv4 ones, and policy rules/filters.
If you're doing super heavy TE, then the filter configs might take some
effort, but if we're talking about smaller shops, doing heavy TE is
unlikely. At that point, you just add a v6 address to your layer3
interfaces and you're good to go for the network side.

Most of the time you spend configuring things won't be v4 or v6 specific,
and the v4 specific configurations can be copy/pasted with a quick string
swap to support v6 in a lot of cases.

network, directly or through a tunnel (thanks, HE.)  Then you have to
> assign IPv6 addresses to every device that has a name, put that in
> your DNS and configure the devices, either by whatever means the
> device has (typically a web control panel) or maybe by a DHCP entry,
>

But once you have the basics down - your layer3 gateways, routing
protocols, etc - this process of getting the hosts on board can take as
long as you'd like. The only deadlines are ones you impose.

if the device can be persuaded to use DHCP rather than SLAAC.  In
> many cases, notably web servers, you need yet more configuration to
> connect each v6 address with whatever service the v6 adddress is
> supposed to provide.
>

I've done this plenty of times and never found it to be particularly
difficult or time-consuming. If you have a lot of systems, hopefully you
have some sort of automation or configuration management which will allow
you to test and deploy to production in at least a less-manual fashion. If
you don't have a lot of systems, then you can just iterate through them and
take 10-15 minutes each to get a v6 address bound and firewall rules
updated.


> Then you have to set up firewall rules to match your v4 firewall rules.
>

Which usually means copy/pasting and a quick string swap.


> Then you spin it all up, and you have to check that every device
> actually does respond on its IPv6 address, and that it acts reasonably
> to mixed v4 and v6 requests (so-called happy eyeballs.)
>

Or just throw it in the monitoring system you already have, but again, this
can all be part of a process that happens over as long a course of time as
you need it to.


>
> None of this is impossible, I've done it all, but I've also often
> asked myself what exactly is the benefit of doing all this.  On my
> home network the v4 stuff is behind a NAT so v6 allows me access
> to devices from the outside (carefully managed with the firewall)
> but on my hosted servers which have v4 addresses for everything, meh.
>

I think ultimately the perception of the work required to deploy IPv6 is a
much greater hurdle to IPv6 adoption than the actual work required to
deploy IPv6.

Re: IPv6 Pain Experiment

[Matt Harris]

On Thu, Oct 3, 2019 at 10:42 PM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Doug Barton wrote:
>
> >> Automatic renumbering involving DNS was important design goal
> >> of IPv6 with reasons.
> >>
> >> Lack of it is still a problem.
>
> > Meanwhile, the thing that most people miss about IPv6 is that except in
> > edge cases, you never have to renumber. You get a massive address block
> > that you can use as long as you pay your bill.
>
> That is called "provider lock-in", which is the primary
> reason, when IPng WG was formed, why automatic renumbering
> is necessary for IPv6.
>

If this is a concern, then get an allocation from your local RIR and
announce it yourself. Then no provider lock-in based on address space of
any sort.

In general any sort of provider move is going to be disruptive if you don't
have your own address space, so that should be taken into account when
choosing to use address space that is somebody else's for production
services that need to be reachable globally.

> So, again, stop spreading FUD.
>
> Look at the fact that IPv6 failed badly.
>

Huh? IPv6 has succeeded slowly, not failed badly. There are loads of us
using it in production today just fine.

Re: worse than IPv6 Pain Experiment

[Matt Harris]

On Wed, Oct 9, 2019 at 5:28 PM Owen DeLong  wrote:

>
> > URLs are an obvious candidate to consider because they're in use, seem
> > to basically work to identify routing endpoints, and are far from a
> > random, out of thin air, choice.
>
> In reality, you’re not really talking about URLs here, even. You’re talking
> about DNS host names. (The part before the // isn’t really part of what
> you want to consider in your network routing scenario, neither is anything
> that comes after the first /).
>
> It’s not that we couldn’t use some form of hierarchically structured human-
> readable name for this purpose… It’s that using DNS host names _REALLY_
> wouldn’t work well.
>

Except what if we used basic textual representations for addresses that
kind of looked like DNS names, but didn't actually try to use DNS names?
Let's even assume we keep DNS largely unchanged, but introduced "B records"
to handle the new addressing scheme, similar to how we introduced 
records to handle translating between names and IPv6 addresses. Perhaps we
also add a special-case "TLD-alike" called .address to indicate when we
want to connect to the specified address and not do a DNS lookup of the
name we've requested?

For example, let's say my internet domain is nanog.org. I might have DNS
setup for nanog.org, but I may also claim addressing space under nanog.org.
Since my ASN is 64500, I will use it to advertise "nanog.org" to my peers:
so when you check a looking glass for nanog.org, you'll see that it's
routing to AS 64500 just like any IPv4 or IPv6 announcement.

Now if you want to visit a website called www.nanog.org, and you punch that
into your web browser, it's going to do a DNS lookup. Assuming this
addressing scheme is preferred over IPv4 or IPv6, the first thing your
browser will do is a DNS lookup for a B record for "www.nanog.org" - and in
my nanog.org zone, I'll have one or more B records pointing to the address
hosting the site, for example:
www.nanog.org. IN B webserver1.nanog.org
Upon receiving this, your browser will then initiate a port 443 TCP
connection (or UDP for QUIC or whatever its protocol of choice is, in this,
the year 3305) to webserver1.nanog.org, which is what will be in the packet
headers. Its upstream router will see this and route it until it reaches a
member of the DFZ at which point that DFZ router will then determine that "
webserver1.nanog.org" is part of "nanog.org" and that "nanog.org" is
announced by AS64500 which is available from two transit providers, prefer
one of them based on whatever traffic engineering rules are the norm in
3305, and send the packet on to the next hop for that route.
On the other hand, if you wish to simply load whatever comes up when you
make an HTTPS request to port 443 on webserver1.nanog.org, you might enter "
https://webserver1.nanog.org.address/"; which will then skip the DNS check
and simply try connecting to webserver1.nanog.org.

When I think about it, this actually seems shockingly
reasonable, potentially massive RAM requirements for routers aside (we're
getting there anyway!). Am I missing something?

Re: VDSL

[Matt Harris]

On Tue, Oct 15, 2019 at 12:25 PM Rod Beck 
wrote:

> Hi,
>
> I discovered that the Budapest cable company was using VDLS to provide
> services up to 500 megs into the buildings where my flats are located. VDSL
> is a pretty old standard. I recollect people talking about it back in 1998.
>
> Is it being heavily deployed in Last Mile networks state side?
>

Hey Rod,
Are you sure they're using VDSL (I'm assuming you mean VDSL2 which is still
in fairly wide use around the world)? 500mbit VDSL2 would have a very short
run limitation afaik. It wouldn't be last mile, more like last meter. :)

It's not super-widely used in the US today since Verizon and others have
built out increasing FTTH networks and always had to compete with DOCSIS
based services which are very widespread here, though I wouldn't be
surprised if it was still frequently the "better than satellite!" service
available in some rural areas that aren't too hard to reach with cabling. A
decade ago, you would've seen a lot more VDSL2 deployments here in the US,
though usually no more than 25 or 50 mbit capacity for the end-user.

https://en.wikipedia.org/wiki/List_of_VDSL_and_VDSL2_deployments has a
bunch of interesting details though I can attest to some of them being
fairly out of date.

Re: VDSL

[Matt Harris]

On Fri, Oct 18, 2019 at 8:46 AM Ryland Kremeier 
wrote:

> Can confirm. Currently on VDSL in rural Missouri, speed is capped at
> 5Mb/s, but has the capability of 7.5Mb/s. All customers from the provider
> here are on VDSL.
>

I'm guessing from your email address that you get that from your electric
coop, too? At the state fair a couple of months ago, I had the opportunity
to speak to the guy who architected and implemented the FTTH rollout for
Ralls County electric coop, up north of StL along the IL border. They did,
from what I could tell from my conversation, everything right and were
providing gigabit services to their users even in relatively rural areas.
Hopefully you guys will get something like that going at some point soon as
well!

Re: IPv4 and Auctions

[Matt Harris]

On Thu, Oct 24, 2019 at 7:08 AM Matt Hoppes <
mattli...@rivervalleyinternet.net> wrote:

> A thought crossed my mind the other day as I was having a discussion with
> someone.
>
> Every entity is suppose to justify their need for IPv4 address space from
> ARIN. This was always (in recent history) the case.
>
> No entity is suppose to be given more IPv4 space until they have nearly
> exhausted their previous space.
>

A lot of entities received very large allocations prior to depletion being
a concern. A lot of entities received very large allocations prior to NAT
even being a thing. Back in the late 90s/early 00s, lots of very large
scale projects were going on in very large organizations to get away from
every desktop, PC, and printer having a world-routable IPv4 address.

Interestingly, that came with a shift in mentality away from having
firewalls at various borders - a mentality we really need to resurrect on a
lot of networks as IPv6 takes off.

How is it, then, that we daily for the last 2-3 years have places like
> Hilco that have sometimes 15-20 large IPv4 blocks up for auction?
>
> Supposedly we are completely out of IPv4 space, yet every day large blocks
> are being sold for money, yet they were never returned because they weren’t
> needed.
>

Why would you return an asset that has value when you could sell it
instead? I mean, look, I'm all for charity, but this is hardly feeding any
orphans or curing any diseases or sending any talented low income kids to
NANOG.

Besides the fact that from the standpoint of the RIR, processing transfers
is less hassle than processing a return and then keeping wait lists going
indefinitely. Better to shift focus to IPv6 as far as allocating space
goes, and let folks like Hilco worry about lining up buyers and sellers for
IPv4 space. Remember, Hilco makes more profit on facilitating those
transactions than an RIR most likely would with their fee structures that
are designed to keep them functioning efficiently, not to keep them engaged
in cumbersome legacy businesses.

Another thought: being that IPv4 address space is essentially leased to you
> from ARIN, can you even legally auction your space to someone else? I know
> it’s happening, but it would almost be like me auctioning my apartment to
> another random person.


Legally speaking, the RSA with ARIN is not particularly similar to most
rental housing contracts.

Besides that, many apartment leases do allow sub-letting or transferring
the lease, as well.

Take care,
Matt

Re: Iran cuts 95% of Internet traffic

[Matt Harris]

On Mon, Nov 18, 2019 at 11:29 AM Scott Weeks  wrote:

>
>
> --- s...@donelan.com wrote:
> From: Sean Donelan 
>
> Its very practical for a country to cut 95%+ of its Internet connectivity.
> Its not a complete cut-off, there is some limited connectivity. But for
> most ordinary individuals, their communication channels are cut-off.
>
> https://twitter.com/netblocks/status/1196366347938271232
> --
>
>
> Does anyone know the network mechanics of how this happens?  For
> example, do all fiber connections go through a governmant choke
> point for suppression?  If so, what's to stop ubiquity-style
> microwave over the border to sympathetic folks on the other side?
>
> scott
>

Implementation specifics vary. Most rely on state control of consumer ISPs
and implement a variety of systems at that layer. Many also have
chokepoints for international connectivity as well.

Penalties for evading the censorship regime? I don't know specifically what
those entail, but probably at the very least fines and confiscation of
equipment, possibly imprisonment, or even worse in some places? Scanning
for RF emissions on common communications frequencies isn't particularly
difficult, nor is police just looking around their jurisdictions for such
antennas on the exterior of buildings.

Of course, there will always be ways around these sorts of things for
people who have the means/resources/technical capability to do so, and some
will be much harder to get caught with than others. But the 0.01% of people
who have the means and resources aren't the real target anyway, as many
people with the means are people who already have a lot to lose and hence
tend to remain loyal to the state to begin with. The 0.01% who have the
technical capability to do something like build a unidirectional
transceiver from parts and deploy it in a way that it won't easily be
detected are a small enough group that they can be written off. It's the
other 99.8% whom they're worried about and against whom censorship regimes
have the best overall efficacy.

Re: Is anyone able to contact GTT?

[Matt Harris]

On Tue, Dec 10, 2019 at 8:51 AM Bottiger  wrote:

> I sent an email to noc at gtt.net from 2 different emails and both got a
> reply saying:
>
> 5.1.0 - Unknown address error 550-'5.4.1 Recipient address rejected:
> Access denied [HE1EUR01FT058.eop-EUR01.prod.protection.outlook.com]'
>
> Not sure if this means if they are blocking my email or if their email is
> broken.
>

Are you a GTT customer? If so, then I suspect the email you're looking for
is inoc@ not noc@ ? The response indicates that the recipient address was
rejected, not the sender address and I've always used inoc to contact them
about my transit circuits.

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Matt Harris]

On Tue, Dec 31, 2019 at 2:30 AM Matt Hoppes <
mattli...@rivervalleyinternet.net> wrote:

> Why do I need Wikipedia SSLed?  I know the argument. But if it doesn’t
> work why not either let it fall back to 1.0 or to HTTP.
>
> This seems like security for no valid reason.


Being able to authenticate that the content you've requested is coming from
the source from which you requested it seems like a pretty valid reason to
me. If you live in a privileged nation with democratic governance, and you
have ISP choice and your ISP doesn't and won't hijack your connections and
you're not otherwise in an environment where your connections may be
hijacked for any number of reasons by any number of parties, then you may
not think about this very much. Employing the best (popular,
well-supported, well-documented, completely open) current standard, TLS
1.2, instead of supporting deprecated, known-flawed previous versions of
that protocol also seems like an entirely reasonable idea, too.

If you don't like that this potentially disenfranchises users of old
devices (and there's perhaps a case to be made here), then the ire should
be imho directed towards the device vendors for not issuing security
updates for whatever version you wish were able to support modern
technology. Not at free web-based services for ending support for
deprecated, known-flawed protocols/ciphers/etc. If google wanted to issue
an update for older android versions to support TLS1.2 then they absolutely
could, though users may see some detrimental performance impact to using
modern technology on an outdated device.

This isn't a new issue, and we as the greater internet community have
generally tackled it by taking aggressive measures towards deprecating
known-flawed technologies on a conservative timeline.

RFC5246 was published over a decade ago.

- mdh

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Matt Harris]

On Tue, Dec 31, 2019 at 9:11 AM Seth Mattinen  wrote:

> On 12/31/19 12:50 AM, Ryan Hamel wrote:
> > Just let the old platforms ride off into the sunset as originally
> > planned like the SSL implementations in older JRE installs, XP, etc. You
> > shouldn't be holding onto the past.
>
>
> Because poor people anywhere on earth that might not have access to the
> newer technology don't deserve access to Wikipedia, right? Gotta make
> sure information is only accessible to those with means to keep "lesser"
> people out.
>

The better solution here isn't to continue to support known-flawed
protocols, which perhaps puts those same populations you're referring to
here at greatest risk, but rather to enable access to open technologies for
those populations which ensures that they can continue to receive security
updates from a vendor that doesn't have a big financial motive to deprecate
devices and force users to purchase upgraded hardware instead of just
receiving security updates to their existing devices.

On Tue, Dec 31, 2019 at 10:07 AM Mike Hammett  wrote:

> If you want the increased security and can afford so, by all means use it.
>
> If you cannot afford the increased security, I guess the response is to
> just bugger off...  we don't need your kind?
>

I'm curious how increased security necessarily costs significant amounts of
money. The bandwidth used to download a package or the source code for the
latest version of OpenSSL (or any number of other crypto libraries) is
relatively negligible. The issue only arises when folks are trapped in
expensive upgrade cycles by vendors with the aforementioned financial
motives.

I don't have a great solution to income inequality and economic disparity
on a whole, but the solution to this specific issue is definitely not to
put those populations at risk by encouraging them and others to continue
using known-flawed technology.

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

[Matt Harris]

On Tue, Dec 31, 2019 at 10:34 AM Royce Williams 
wrote:

> On Tue, Dec 31, 2019 at 7:17 AM Matt Harris  wrote:
>
>>
>> The better solution here isn't to continue to support known-flawed
>> protocols, which perhaps puts those same populations you're referring to
>> here at greatest risk, but rather to enable access to open technologies for
>> those populations which ensures that they can continue to receive security
>> updates from a vendor that doesn't have a big financial motive to deprecate
>> devices and force users to purchase upgraded hardware instead of just
>> receiving security updates to their existing devices.
>>
>
> Unfortunately, this is the high-tech privilege equivalent of saying "let
> them eat cake" - because of upgrade friction on mobile in under-resources
> areas (including, I might add, specific sub-populations of US consumers!)
>

Perhaps more unfortunately, the other option - to continue supporting
known-flawed protocols - is simply saying "let them be victimized."

Accepting that we should instead support technologies that place those very
same populations at risk is coming from a place of privilege for the
reasons I mentioned previously: you live somewhere with relatively
peaceful/democratic governance, usually have at least some ISP choice, and
are likely not otherwise under the thumb of an oppressive regime at some
level of another - so when your browser makes a TLS1.0 connection, you
probably don't even think about it, much less worry about it, because you
don't have to. The populations we're discussing here, on the other hand,
all too often do.

What it comes down to is a question of whether we want to solve what we
know today is a real problem or let it fester until abuse reaches an
untenable level in some big, news-headline-making way. One way we can
combat this specific issue is to make open technologies accessible. But
that requires major investment on our side of the world, and prior attempts
to do so (Ubuntu's open source phone OS for example) have largely been
commercial flops.

- mdh

Re: earthlink email problems

[Matt Harris]

On Tue, May 22, 2018 at 2:00 PM, jimmy keffer 
wrote:

> my has problems sending mail to earthlink.net the sever has a ptr abd
> reverse dns set but i get this To: ji...@horsezipsworld.com
>
>Remote server replied: 550 ERROR: No or mismatched reverse DNS (PTR)
> entries for 23.227.197.10
>
> any one here who can help my server sends mail to servers fine gmail etc
> jimmy
>

Your A record does not match that IPv4 addr:

(mdh@kirin) [~/]# host 23.227.197.10
10.197.227.23.in-addr.arpa domain name pointer horsezipsworld.com.
(mdh@kirin) [~/]# host horsezipsworld.com
horsezipsworld.com has address 23.227.197.11

You may want to set something up like mail. which points to
23.227.197.10
and then set the PTR for  23.227.197.10 to mail. so that you have a
matching set.  PTR's that don't match are unreliable - I can set a PTR for
my IP addresses to matt.google.com, but that doesn't mean I have any
authority regarding google.com.

Take care,
Matt

Re: Whois vs GDPR, latest news

[Matt Harris]

 Maybe I'm going out on a limb here, but was domain whois ever really that
useful?  I can't remember ever using it for any legitimate sort of
activity, and I know it gets scraped quite a bit by spammers.  Most of the
data is bogus these days on a lot of TLDs which allow "anonymous
registrations" and which registrars often charge an extra dollar or two
for.  Showing the authoritative nameservers is neat, but a simple NS record
query against the next level up would suffice to provide that information
as well.  The date of expiration may be useful if you're trying to grab a
domain when it expires, but registrar policies often drag that out anyways
and half the time the registrar squats on any decent domain when it expires
anyhow.  Date of original registration may be interesting for one reason or
another... but none of this data is personally identifiable information
anyhow.

Now on the other hand, RIR whois is actually very useful for determining
the rightful owner and abuse contacts for IP address space... Since RIRs
are designated by region and, afaik, only RIPE NCC data would be impacted
by GDPR... well, I'm surprised this isn't being talked about more than the
domain name side of things.

Take care,
Matt

Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap

[Matt Harris]

On Mon, Jun 11, 2018 at 4:16 PM, Scott Weeks  wrote:

> Hmm...  Faster and better?
>
> The links seem to be an IPv6 cheerleader write up.
> I looked at the URLs and the URLs one pointed to and
> pulled out everything related to IPv6 being
> faster/better.
>
>
Is it possible that simply having a much smaller routing table overall in
terms of sheer number of prefixes in the DFZ has a positive performance
impact on passing packets, which coupled with the fact that implementations
may be routed better/more efficiently due to a lack of "legacy cruft"
creates a better experience for many packets?

Just a theory/hypothesis with no data to back it up.

Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap

[Matt Harris]

On Mon, Jun 11, 2018 at 5:03 PM, Ca By  wrote:

>
> A similar take, is that big eyeballs (tmobile, comcast, sprint, att,
> verizon wireless)
>

There're a lot of big eyeball networks missing from that list.  Spectrum
biz class, no IPv6, for one.  And some big "content"-ish ones, too.
Google's cloud service, for example?  No IPv6 for VMs you lease from them.
And some of the biggest "web hosting providers" in the world still don't
have IPv6 deployed, and they host millions if not billions of sites which,
individually, have very little traffic, but in aggregate amount to a fair
bit.

Re: Anyone from Delta on list?

[Matt Harris]

On Fri, Jul 13, 2018 at 2:21 PM, John Levine  wrote:

> In article <2d8e2754-662a-4029-b6fa-6714b1b6c...@semperen.com> you write:
> >-=-=-=-=-=-
> >
> >If so, can you contact me off list, please and thank you?
>
> Delta the airline?  Delta the hotel chain?  Delta the plumbing fixture
> maker?  Delta the construction company?
>

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

Re: Rising sea levels are going to mess with the internet

[Matt Harris]

On Mon, Jul 23, 2018 at 8:25 AM, William Herrin  wrote:
>
>
> Government regulation which results in increased costs.
>
> Climate science is interesting and worthy, but it's still too shaky
> and incomplete to justify trillion dollar decisions.
>
> For anyone who would have us Act Now Before It's Too Late, alarmist is
> the right term.
>
> Regards,
> Bill Herrin
>

The United States has lowered carbon emissions while the EU and China
continue to increase.

https://www.epa.gov/sites/production/files/2018-01/documents/2018_complete_
report.pdf

https://rhg.com/research/taking-stock-2018/

https://www.greentechmedia.com/articles/read/european-
renewables-are-up-so-are-carbon-emissions#gs.=_L422U


I'm not sure exactly what this means, but in general, I think it's fair to
say that the US has taken a more market-driven approach that includes
working with industry to decrease carbon emissions.  During the same time
frame the EU, China, and other nations and regions that tend towards more
heavy handed top-down regulatory approaches to problems such as this seem
to be having trouble making progress and are in fact still headed in the
wrong direction.

Draw your own conclusions from that.  ;)

Re: Rising sea levels are going to mess with the internet

[Matt Harris]

On Mon, Jul 23, 2018 at 10:50 AM, Nick Hilliard  wrote:

>
>> The available data does not support your speculation.
>
> https://data.worldbank.org/indicator/EN.ATM.GHGT.KT.CE?locations=US-EU-CN
>>
>
> Nick
>

Which data are you referring to?  Did you look at the three links that I
provided?

My linked stats are from the past couple of years, but the worldbank link
you posted contains a chart which only comes to 2012 at the latest, six
year old data.  The EPA report covers 1990-2016, the Rhodium Group report
primarily looks at 2005-2016 but also analyzes some information from 2017
and speculates on trends in the coming decades, and the GreentechMedia link
specifically looks at the EU and its member states during 2017.

So I'm very confused as to which data you're referring to, and which
speculation you're referring to, since it seems you're just pointing at
data which is several years out of date compared to the information I
provided in my post, which I believe to be the best and most recently
currently published.

Avast / Privax abuse contact

[Matt Harris]

Anybody know anyone at or anything about Privax or Avast?  AS 198605 is
announcing the problem networks.

Getting a ton of SIP brute force attacks from their space, and emails with
addresses/timestamps to the abuse contacts listed at RIRs/etc have not
yieled any responses.  Attacks still coming.

Thanks!

Re: Best practices on logical separation of abuse@ vs dmca@ role inboxes

[Matt Harris]

On Sun, Aug 5, 2018 at 5:46 PM, Rich Kulawiec  wrote:

> This is a solvable problem.  If they're sending unsolicited bulk email
> (aka "spam"), then they are, by definition, spammers.  Block them and
> move on.  If/when they decide to send proper DMCA notices and send them
> to the proper address, perhaps you can then allow them to petition for
> the privilege of access to your mail system.
>
> ---rsk
>

But then the question becomes "how are they supposed to find the 'proper
address' for their reports?"  If you run a whois server and link it from
your RIRs or create a custom "DMCA Compliance" POC in the RIR listings then
you could maybe list that sort of thing there, but most address maintainers
do neither, so by default whatever address is listed on those net block
records with the RIR seems appropriate enough to me.  There's no other
established protocol for determining an appropriate contact (like calling
the associated phone number and asking, or trying to determine your web url
and browing that site for it, or something else much more involved.)  If
there should be a different protocol established for that, then we need to
figure it out and document that and get a critical mass of reporters to buy
in to it.

Re: Best practices on logical separation of abuse@ vs dmca@ role inboxes

[Matt Harris]

On Mon, Aug 6, 2018 at 10:09 AM,  wrote:

>
> Asked and answered already.
>
> On 8/5/2018 16:53:35, "John Levine"  wrote:
> >See https://www.copyright.gov/dmca-directory/
>
> If you are in fact registered there, it becomes *their* problem to send
> their reports to the address you registered.
>
>
I forgot that exists; seems like the only legitimate source for that
information, then.