ARIN Fantasy WHOIS: NET-216-179-183-0-1

[Ronald F. Guilmette]

As if to underscore the point I just tried to make about the fundamental
unreliability of ARIN WHOIS records, I just stumbled onto this rather
curious entity which was apparently given a sub-allocation of 216.179.183.0/24
beneath the 216.179.128.0/17 (Azuki, Inc.) block as of 2012-01-10:

OrgName:Rogers Communications Inc
OrgId:  RC-82
Address:E 2nd St,Campbell
City:   Gillette
StateProv:  WY
PostalCode: 82716
Country:US
RegDate:2012-01-10
Updated:2012-01-10
Ref:https://rdap.arin.net/registry/entity/RC-82

Other that the fact that it has an oddly similar name to one of Canada's
largest and most well-known Internet and cell phone companies, the only
other thing that's rather remarkable about it is that it was given the
216.179.183.0/24 block, by Azuki, Inc. in 2012.  What's odd about that?
Well, only the fact that this *Wyoming* incarnation of Rogers Communications
had apparently already died and gone to Valhalla some 14 years earlier,
in 1998:

https://wyobiz.wy.gov/Business/FilingDetails.aspx?eFNum=070023242004106130056183154143023082073130141117

Moral of the story:  Don't ever let anybody tell you that ghosts... even
ghosts of long dead companies... aren't real or that they do not walk
among us.  Their immortal auras pervade the very ether we breath.

And they have their own IPs, apparently.

But, you know, if your customers are getting hack attacks emmanating from
216.179.183.0/24... well... to quote the old Ghostbusters tag line "Who
you gonna call?"  (Hint:  Don't waste your time calling the number in the
WHOIS record.  It's just some bloody preschool.)

Regards,
rfg

Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17

[Hank Nussbacher]

On 15/08/2019 06:16, Ronald F. Guilmette wrote:

- If the resource owner is no where to be found, why should we as a
community care?

I'm so glad you asked.


Regardless, in -either- the case where no heir can be found -or- in the
case where the rightful heir is either just too dumb or just too lazy
to take the minimal steps necessary to reclaim the property (and/or before
this has ocurred) the community should care because the kind of people who
either steal or squat on IPv4 blocks are, almost without exception, not the
kind of people who anybody sane wants to be accepting packets from, let
alone peering with.  There is, in my opinion and experience, a high
degree of correlation between skulduggery with respect to -obtaining-
(illicitly) IPv4 address blocks and using those addresses in a manner
which is not at all conducive to the general welfare of the Internet or
its users.


So if the rightful is apathetic, then won't these new "malicious blocks" 
just end up in numerous blacklists and all the illegal activity being 
performed from those usurped blocks will just be blocked in the end?  
Since the RIRs won't do much(as much as we have tried) why not just 
leave it be (as much as it may hurt to do that) and let the bad blocks 
just become part of the blacklist sludgepool?



Report it on some webpage and call it "Internet
Resources stolen", document every incident as you do via email, send a
copy to the appropriate RIR and upstream ISP allowing the hijack in
question to show that you did the appropriate effort and we can then
move on.

I can and will stop posting here, and go off an blog about this stuff
instead, if the consensus is that I'm utterly off-topic or utterly
uninteresting and useless.  But a few folks have told me they find
this stuff interesting, and it has operational significance, I think.
So for now, at least, I'd like to continue to share here.


Suggestion: post here a link to your new blog for every incident you 
find.  State here something like "/22 stolen from  registered in 
country aaa by yyy located in country bbb".  Those that are interested 
will click on the link and I suggest you allow comments on every blog 
post so that people can respond and comment.


Regards,

Hank

Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17

[Ronald F. Guilmette]

In message <20190810003820.gd2...@jima.tpb.net>, 
Niels Bakker  wrote:

>* r...@tristatelogic.com (Ronald F. Guilmette) [Sat 10 Aug 2019, 02:26 CEST]:
>>As far as I am aware, no RIR makes any effort whatsoever to vet 
>>changes to WHOIS records, either for IP blocks or ASNs or ORG 
>>records.
>
>This is hilarious.  You should hear the whining from any EU-based 
>operator who has to implement the transfer of RIPE NCC resources in 
>a corporate acquisition.
>
>I recently was involved with one of those and the amount of due 
>diligence required by the RIPE NCC was pretty intense.  If I were at 
>an RIR I'd be insulted by your claim of "no... effort whatsoever".

I do not and would not dispute that at least a few RIRs... in particular
ARIN and RIPE... are -very- good and -very- diligent these days in their
vetting of the legitimacy of what the RIRs themselves, and on their
(secret) -internal- books list as "registrants" of number resources.

But what is listed on the internal books of any given RIR is -not- what
appears in the WHOIS records.  It's just that simple.  Your RIR may
have given you a full rectal exam prior to giving you your IP addresses.
But how does that help -me- if you're sending me bad packets and your
WHOIS records says the following?

Registrant:Salvador Dali
Address:   12345 Moon St., The Universe, 9
Phone: <>

Regards,
rfg

Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17

[Ronald F. Guilmette]

In message <4fcb73bf-224f-e011-f310-522193c86...@efes.iucc.ac.il>, 
Hank Nussbacher  wrote:

>Just as an observer to your long resource theft postings:
>- Do you attempt to contact directly the organization or person who have 
>had their resource taken over?

To the extent that I can spare the time, and to the extent that I am able
to do so, (which is often limited by time zone differences) yes, I do.

>- Do they care or are they apathetic?

Before answering let me clarify first the two different classes of problems
that I've most often been looking at.

Everybody including myself has in the past used the term "hijack" but
I'm going to try to stop doing that, in future, and instead use the more
precise terms "squatting" and "theft", where "theft" involves a case
where the relevant WHOIS records have been materially "fiddled" by the
usurper.

In both cases, the usurpers generally aim, first and foremost, for the
low hanging fruit, which is to say legacy blocks that were abandoned
years and years ago, sometimes even decades ago, back when IP addresses
had zero monitizable value.

When contacted, victims in these cases are typically at first utterly
perplexed, and when I explain to them that I am trying to give them
back stuff that they already own, and which in some cases is worth
considerable money on the open market, they *do* look a gift horse
in the mouth, and they assume, quite reasonably I think, given the
current way of the world, that *I* am trying to run some kind of
elaboarate scam on them.  It takes a lot of talking on my part to
convince them that no. I'm actually just a good samaritan, and that no,
I am -not- going to be asking them to first send any sort of "release
fee" via WesterUnion or Bitcoin or WebMoney before they can have their
own blocks back.

Even after they have been convinced that this ain't a scam and that they
do own the stuff I say they own, most are often entirely lackadaisical
about getting off their butts and then working with the relevant RIRs
to get their own stuff back.  Even when I try to get them fired up
by telling them that "cybercriminals" have stolen their blocks, and
the fact that evil that is being done under their names may negatively
affect THEIR public reputations, it's still like watching paint dry,
for me anyway.  Clearly, nobody but me has any sense of urgency about
these things at all.

>- If the resource owner is no where to be found, why should we as a 
>community care?

I'm so glad you asked.

Before answering I should first note that it is actually quite rare when
a sufficient amount of research on my part fails to turn up a relevant
"successor or assign" which would, by rights, be the modern day entity
with a legitimate claim on the asset.  So the "nowhere to be found" case
is by far the exception, rather than the rule.

Regardless, in -either- the case where no heir can be found -or- in the
case where the rightful heir is either just too dumb or just too lazy
to take the minimal steps necessary to reclaim the property (and/or before
this has ocurred) the community should care because the kind of people who
either steal or squat on IPv4 blocks are, almost without exception, not the
kind of people who anybody sane wants to be accepting packets from, let
alone peering with.  There is, in my opinion and experience, a high
degree of correlation between skulduggery with respect to -obtaining-
(illicitly) IPv4 address blocks and using those addresses in a manner
which is not at all conducive to the general welfare of the Internet or
its users.

>Report it on some webpage and call it "Internet 
>Resources stolen", document every incident as you do via email, send a 
>copy to the appropriate RIR and upstream ISP allowing the hijack in 
>question to show that you did the appropriate effort and we can then 
>move on.

I can and will stop posting here, and go off an blog about this stuff
instead, if the consensus is that I'm utterly off-topic or utterly
uninteresting and useless.  But a few folks have told me they find
this stuff interesting, and it has operational significance, I think.
So for now, at least, I'd like to continue to share here.

As regards to reporting to RIRs or upstreams, what makes you think that
either of those would care one wit?  The RIRs are not the Internet
Police, or so I am told.  They don't configure routers.  Upstreams are,
in my experience utterly intransigent and unresponsive, especially in
the absence of public exposure of the self-evident problem(s) like
the time I tried to get Telecom Italia to get off their asses and do
something... anything... about their criminal mass squatting customer.
It wasn't until much later on, after WhiteOps and Google had exposed
the massive click fraud operation that was behind all that that Telecom
Italia saw fit to lift even a single finger to actaully DO anything at
all.  And the last time I looked, Telecom Italia was *still* peering
with the exact same crooked ASN, even though most or all of 

Re: Protecting 1Gb Ethernet From Lightning Strikes

[Eric Kuhnke]

Another copper cable considered a "gold standard" for outdoor shielded +
9th ESD drain and ground wire, intended for long term rooftop and tower
installation is Shireen. There's a variety of types.

https://www.shireeninc.com/osc/cables/cat6



On Wed, Aug 14, 2019 at 6:30 PM Brandon Martin 
wrote:

> On 8/13/19 2:32 PM, Warren Kumari wrote:
> > This probably won't fully solve your problem, but I run a bunch of
> > Ubiquiti access points and similar -- I suffered a number of lightning
> > related outages, and then started using their TOUGHcable -
> > https://www.ui.com/accessories/toughcable/
>
> While ToughCable isn't bad (especially for the price), if you want
> something REALLY durable both physically and against electrical
> transients, I've been very happy with Primus C6CMXFS-1864BK.  It costs
> quite a bit more than the ToughCable but has real water blocking (which
> means you had better be prepared to deal with "Icky Pic"), heavy
> shielding with drain, meets or exceeds CAT6 (which means you can push
> gigE a bit beyond 100m pretty reliably if you've got a tall tower or a
> hut far away from a tower base), and has 23AWG wire so PoE, especially
> Ubnt's crummy 24V passive POE, can go farther, too.
>
> Be warned it's a bear to terminate.  In addition to the waterblock, the
> cable diameter is too large for typical crimp-on RJ45 ends.  You have to
> either use special ends (which Primus sells, among others) or terminate
> it to a punch block which, while not usually a problem in a hut, is
> often problematic up on a tower.
>
> Ubnt also makes an outdoor fiber media converter I've found useful for
> "small cell" style wISP deployments where I can drag my own fiber to the
> tower/pole and don't want/need a hut or enclosure at the base.  Part
> number is F-POE-G2.  That'll let you get your power and signal
> separated.  I do wish they'd just put SFP slots in their radios, but at
> the price they sell them for, I guess I can't complain too much.  I'd
> put real 802.3af/at PoE higher on the list of wants, honestly.
>
> As to actual surge protectors, I see there have been some other
> suggestions in the list, and I'll defer to them.  I've personally had
> decent luck with just making sure the Ubnt passive POE injectors (which
> I need since I don't usually use their switches) are well grounded to be
> mostly sufficient (along with the tower and hut having proper grounding
> infrastructure).  I've not lost any radios, though I've had some lockups
> requiring power cycle after nearby lightning strikes on some of the
> lower end WA based platforms.  The XC based platforms seem hardier.  My
> sample size isn't huge, though.
>
> I'm usually of the impression that, unless you've got carrier (cellular
> or committed-rate microwave) class wireless gear on the tower or
> aggressive SLAs you have to meet from a wireless PoP, it's probably
> cheaper overall to just take reasonable precautions against lightning
> than it is to try to make things handle a "direct" strike.  Figure in
> the wISP world, tech moves so fast that you're having to put new things
> on the tower at least every 3-5 years anyway, so as long as an
> unscheduled trip up to the tower doesn't cost you $ARM+$LEG, it's
> probably easier to just take a lightning strike that fries everything
> due to extreme proximity as an unscheduled upgrade than the try to
> handle it electrically.
>
> "Nearby" strikes, static, electrical transients on your utility line,
> etc. are a different matter.  Those you can economically protect against
> i.e. the protection will not cost as much or more than the gear and
> service you're protecting.
> --
> Brandon Martin
>

Re: Protecting 1Gb Ethernet From Lightning Strikes

[Brandon Martin]

On 8/13/19 2:32 PM, Warren Kumari wrote:

This probably won't fully solve your problem, but I run a bunch of
Ubiquiti access points and similar -- I suffered a number of lightning
related outages, and then started using their TOUGHcable -
https://www.ui.com/accessories/toughcable/


While ToughCable isn't bad (especially for the price), if you want 
something REALLY durable both physically and against electrical 
transients, I've been very happy with Primus C6CMXFS-1864BK.  It costs 
quite a bit more than the ToughCable but has real water blocking (which 
means you had better be prepared to deal with "Icky Pic"), heavy 
shielding with drain, meets or exceeds CAT6 (which means you can push 
gigE a bit beyond 100m pretty reliably if you've got a tall tower or a 
hut far away from a tower base), and has 23AWG wire so PoE, especially 
Ubnt's crummy 24V passive POE, can go farther, too.


Be warned it's a bear to terminate.  In addition to the waterblock, the 
cable diameter is too large for typical crimp-on RJ45 ends.  You have to 
either use special ends (which Primus sells, among others) or terminate 
it to a punch block which, while not usually a problem in a hut, is 
often problematic up on a tower.


Ubnt also makes an outdoor fiber media converter I've found useful for 
"small cell" style wISP deployments where I can drag my own fiber to the 
tower/pole and don't want/need a hut or enclosure at the base.  Part 
number is F-POE-G2.  That'll let you get your power and signal 
separated.  I do wish they'd just put SFP slots in their radios, but at 
the price they sell them for, I guess I can't complain too much.  I'd 
put real 802.3af/at PoE higher on the list of wants, honestly.


As to actual surge protectors, I see there have been some other 
suggestions in the list, and I'll defer to them.  I've personally had 
decent luck with just making sure the Ubnt passive POE injectors (which 
I need since I don't usually use their switches) are well grounded to be 
mostly sufficient (along with the tower and hut having proper grounding 
infrastructure).  I've not lost any radios, though I've had some lockups 
requiring power cycle after nearby lightning strikes on some of the 
lower end WA based platforms.  The XC based platforms seem hardier.  My 
sample size isn't huge, though.


I'm usually of the impression that, unless you've got carrier (cellular 
or committed-rate microwave) class wireless gear on the tower or 
aggressive SLAs you have to meet from a wireless PoP, it's probably 
cheaper overall to just take reasonable precautions against lightning 
than it is to try to make things handle a "direct" strike.  Figure in 
the wISP world, tech moves so fast that you're having to put new things 
on the tower at least every 3-5 years anyway, so as long as an 
unscheduled trip up to the tower doesn't cost you $ARM+$LEG, it's 
probably easier to just take a lightning strike that fries everything 
due to extreme proximity as an unscheduled upgrade than the try to 
handle it electrically.


"Nearby" strikes, static, electrical transients on your utility line, 
etc. are a different matter.  Those you can economically protect against 
i.e. the protection will not cost as much or more than the gear and 
service you're protecting.

--
Brandon Martin

Re: Protecting 1Gb Ethernet From Lightning Strikes

[Eric Kuhnke]

I would begin by referencing the grounding section here:

https://www.blm.gov/sites/blm.gov/files/Lands_ROW_Motorola_R56_2005_manual.pdf

Of utmost importance is that everything is bonded to the same potential.
This means that if they have stuff on a roof, outdoor antennas or APs,
whatever, it ground needs to be bonded to the building's AC electrical
service entrance ground, ufer ground if one exists, and so forth.

This is probably the lowest cost ohm meter that is suitable for real world
use:
https://www.amazon.com/Extech-382252-Ground-Resistance-Tester/dp/B00390G3YA

The WISP community has over the past twenty years of painful experience
learned to use a combination of high quality ethernet surge protectors
(previously mentioned McCown Tech suppressors or their competitors) and
comprehensive grounding.



On Tue, Aug 13, 2019 at 11:23 AM Javier J 
wrote:

> I'm working with a client site that has been hit twice, very close by
> lightening.
>
> I did lots of electrical work/upgrades/grounding but now I want to focus
> on protecting Ethernet connections between core switching/other devices
> that can't be migrated to fiber optic.
>
> I was looking for surge protection devices for Ethernet but have never
> shopped for anything like this before. Was wondering if anyone has deployed
> a solution?
> They don't have a large presence on site (I have been moving all of their
> core stuff to AWS) but they still have core networking / connectivity and
> PoE cameras / APs around the property.
> Since migrating their onsite servers/infra to the cloud, now their
> connectivity is even more important.
>
> This is a small site, maybe about 200 switch ports, but I would only need
> to protect maybe 12 core ones. but would be something I could use in the
> future with larger deployments.
> it's just a 1Gbe network BTW.
>
> Hope someone with more experience can help make hardware recommendations?
>
> Thanks in advance.
>
> - Javier
>

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[Ronald F. Guilmette]

In message , 
John Curran  wrote:

>Alas, it’s not those who fail to properly configure RPKI that are likely to be
>litigating, but rather their impacted customers and those customers' business
>partners who all were unable to communicate due to no fault of their own. 
>
>Such a matter will not be thrown out of court, but will be the start of a long
>and very expensive process involving claims, discovery, experts, etc...

Perhaps.  There are certainly some big players (AWS) that if routing were
interrupted for even, say, 12 hours, a lot of folks would get really mad
about.

Correct me if I'm wrong, but one of your presentation slides seemed to
suggest that a separate arms-length legal entity could be established
to do the RPKI stuff, thus offloading most or all of the potential
liability onto and into this separate entity, which could conveniently
have minimal assets of the kind that might inspire members of the
plaintiff's bar who are looking for deep pockets.

Is that an actual possibility, or did you just throw that in there for the
sake of completness?

Personally, I don't much care how the problem gets solved, as long as it
gets solved.  The fundamental BGP problem has been known and discussed
now for 20+ years and it is only getting more dire and ominous, day by day.


Regards,
rfg

Access to Level3 PoP?

[Nicholas Warren]

We are needing access into Level3/Centurylink's PoP at Monett Missouri to test 
our fiber. Does anyone have an email, phone number, or smoke signal we could 
use to get access to test fiber?

Support is, sadly, not being very helpful.

Nich Warren

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[Anne P. Mitchell, Esq.]

> There's obviously a disconnect where people aren't worried about indemnifying
> Spamhaus for using their block list, but are worried about indemnifying ARIN 
> for
> using the TAL.

That would be because there is a rather substantial difference between 
publishing an IP address for which you have spam in hand, and are saying (and 
only saying) "I received spam from this IP address" (not to mention something 
which people use to only affect inbound email), and hosting something on which 
others rely for making their acceptance decision of all legitimate Internet 
traffic, as well as for the ability to not move malicious (or even accidentally 
misconfigured) Internet traffic.

Anne

Anne P. Mitchell, Attorney at Law
Dean of Cybersecurity & Cyberlaw, Lincoln Law School of San Jose
CEO/President, Institute for Social Internet Public Policy
SuretyMail Email Reputation Certification
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Legislative Consultant
GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant
Board of Directors, Denver Internet Exchange
Board of Directors, Asilomar Microcomputer Workshop
Legal Counsel: The CyberGreen Institute
Former Counsel: Mail Abuse Prevention System (MAPS)
Member: California Bar Association

Re: Protecting 1Gb Ethernet From Lightning Strikes

[Alan Buxey]

hi,

have seen and suffered from same.  nearby strikes can cause enough
surge to fry things.  best solution - air-gaps where possible between
devices (eg fibre to link switches),  surge protectors on ethernet
cables where needed (eg feeds from Access points) - and if the APs
have external antennae
then use lightning arrestors on the coax cables.

why main wireless vendors still don't do SFP/SFP+-based APs I don't
know... (would mean only the AP cooks and the edge switch isnt the
victim

alan

Re: Protecting 1Gb Ethernet From Lightning Strikes

[Mikael Abrahamsson]

On Wed, 14 Aug 2019, Chris Knipe wrote:


Think surge protectors will protect against strikes that is far away, and
the residual surge it creates.

A direct strike?  Don't think there's anything that will really protect
against that.


https://imgur.com/a/dzTVw5a has been posted lately here in a swedish 
fiber-related facebook group.


So even though you might have fiber coming in, remember that both the 
power grid and copper network cables are conductors and can make the 
lightning strike jump between devices. So the OP of this thread is right 
in wanting to protect both the network cables and power cables.


PS. I don't have more details about this specific case.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[Valdis Klētnieks]

On Wed, 14 Aug 2019 16:07:49 -, John Curran said:

> > But I suspect a lot of companies are reading it as: "If a spammer sues you 
> > for using
> > a block list that prevents them from spamming your customers, you can't end 
> > up
> > owing money to the block list maintainers.  But if you rely on the ARIN 
> > TAL, and get
> > sued by an address hijacker, you could end up owing money to ARIN".

> It's is not "you owe money to ARIN", but it could be "you need to defend both
> yourself and ARIN from your customers litigation should you get it wrong."

Is there any workable way to remove or diminish the perception of liability in
the case of using it *correctly*?   I admit that (a) I'm not a lawyer and (b)
when I actually tried to read it I couldn't actually tell if it was "you
promise to defend us if you screw it up and customer traffic gets accidentally
dropped on the floor" or "you promise to defend us if you use it correctly and
miscreant traffic is intentionally dropped on the floor"...

There's obviously a disconnect where people aren't worried about indemnifying
Spamhaus for using their block list, but are worried about indemnifying ARIN for
using the TAL.



pgpPfQJhUFewN.pgp
Description: PGP signature

Re: Protecting 1Gb Ethernet From Lightning Strikes

[Chris Knipe]

Think surge protectors will protect against strikes that is far away, and
the residual surge it creates.

A direct strike?  Don't think there's anything that will really protect
against that.

On Wed, Aug 14, 2019 at 7:29 PM  wrote:

>
> Are "surge protectors" really of much use against lightning? I suspect
> not, other than minor inductions tho perhaps some are specially
> designed for lightning. I wouldn't assume, I'd want to see the word
> "lightning" in the specs.
>
> I once had a lightning strike (at Harvard Chemistry), probably just an
> induction on a wire some idiot had strung between building roofs (I
> didn't even know it existed) and the board it was attached to's solder
> was melted and burned, impressive! More impressive was the board
> mostly worked, it was just doing some weird things which led me to
> inspect it...oops.
>
> My understanding was that the only real protection is an "air gap",
> which a piece of fiber will provide in essence, and even that better
> be designed for lightning as it can leap small gaps.
>
> Check your insurance, including the deductibles, keep spares on hand.
>
> P.S. My grandmother would tell a story about how what sounded like the
> ever-controversial "ball lightning" came into her home when she was
> young. Good luck with that!
>
>   https://en.wikipedia.org/wiki/Ball_lightning
>
> --
> -Barry Shein
>
> Software Tool & Die| b...@theworld.com |
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*
>


-- 

Regards,
Chris Knipe

Re: Protecting 1Gb Ethernet From Lightning Strikes

[bzs]

Are "surge protectors" really of much use against lightning? I suspect
not, other than minor inductions tho perhaps some are specially
designed for lightning. I wouldn't assume, I'd want to see the word
"lightning" in the specs.

I once had a lightning strike (at Harvard Chemistry), probably just an
induction on a wire some idiot had strung between building roofs (I
didn't even know it existed) and the board it was attached to's solder
was melted and burned, impressive! More impressive was the board
mostly worked, it was just doing some weird things which led me to
inspect it...oops.

My understanding was that the only real protection is an "air gap",
which a piece of fiber will provide in essence, and even that better
be designed for lightning as it can leap small gaps.

Check your insurance, including the deductibles, keep spares on hand.

P.S. My grandmother would tell a story about how what sounded like the
ever-controversial "ball lightning" came into her home when she was
young. Good luck with that!

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

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: new BGP hijack & visibility tool “BGPalerter”

[Alarig Le Lay]

Hi,

You can build it yourself, see
https://github.com/nttgin/BGPalerter#more-information-for-developers

I think that the binaries are here for thoses that don’t want to install
all the build-chain.

-- 
Alarig

On 14/08/2019 19:06, Ryan Hamel wrote:
> Job,
>
> I appreciate the effort and the intent behind this project, but why
> should the community contribute to an open source project on GitHub
> that is mainly powered by a closed source binary?
>
> Ryan
>
> On Wed, Aug 14, 2019, 10:55 AM Job Snijders  > wrote:
>
> Dear NANOG,
>
> Recently NTT investigated how to best monitor the visibility of
> our own and our subsidiaries’ IP resources in the BGP Default-Free
> Zone. We were specifically looking how to get near real-time
> alerts funneled into an actionable pipeline for our NOC &
> Operations department when BGP hijacks happen.
>
> Previously we relied on a commercial “BGP Monitoring as a Service”
> offering, but with the advent of RIPE NCC’s “RIS Live” streaming
> API [1] we saw greater potential for a self-hosted approach
> designed specifically for custom integrations with various
> business processes. We decided to write our own tool “BGPalerter”
> and share the source code with the Internet community.
>
> BGPalerter allows operators to specify in great detail how to
> distribute meaningful information from the firehose from various
> BGP data sources (we call them “connectors”), through data
> processors (called “monitors”), finally outputted through
> “reports” into whatever mechanism is appropriate (Slack, IRC,
> email, or a call to your ticketing system’s API). 
>
> The source code is available on Github, under a liberal open
> source license to foster community collaboration:
>
>     https://github.com/nttgin/BGPalerter 
>
> If you wish to contribute to the project, please use Github’s
> “issues” or “pull request” features. Any help is welcome! We’d
> love suggestions for new features, updates to the documentation,
> help with setting up a CI regression testing pipeline, or
> packaging for common platforms.
>
> Kind regards,
>
> Job & Massimo
> NTT Ltd
>
> [1]: https://ris-live.ripe.net/
>

Re: new BGP hijack & visibility tool “BGPalerter”

[Ryan Hamel]

Job,

I appreciate the effort and the intent behind this project, but why should
the community contribute to an open source project on GitHub that is mainly
powered by a closed source binary?

Ryan

On Wed, Aug 14, 2019, 10:55 AM Job Snijders  wrote:

> Dear NANOG,
>
> Recently NTT investigated how to best monitor the visibility of our own
> and our subsidiaries’ IP resources in the BGP Default-Free Zone. We were
> specifically looking how to get near real-time alerts funneled into an
> actionable pipeline for our NOC & Operations department when BGP hijacks
> happen.
>
> Previously we relied on a commercial “BGP Monitoring as a Service”
> offering, but with the advent of RIPE NCC’s “RIS Live” streaming API [1] we
> saw greater potential for a self-hosted approach designed specifically for
> custom integrations with various business processes. We decided to write
> our own tool “BGPalerter” and share the source code with the Internet
> community.
>
> BGPalerter allows operators to specify in great detail how to distribute
> meaningful information from the firehose from various BGP data sources (we
> call them “connectors”), through data processors (called “monitors”),
> finally outputted through “reports” into whatever mechanism is appropriate
> (Slack, IRC, email, or a call to your ticketing system’s API).
>
> The source code is available on Github, under a liberal open source
> license to foster community collaboration:
>
> https://github.com/nttgin/BGPalerter
>
> If you wish to contribute to the project, please use Github’s “issues” or
> “pull request” features. Any help is welcome! We’d love suggestions for new
> features, updates to the documentation, help with setting up a CI
> regression testing pipeline, or packaging for common platforms.
>
> Kind regards,
>
> Job & Massimo
> NTT Ltd
>
> [1]: https://ris-live.ripe.net/
>

Re: new BGP hijack & visibility tool “BGPalerter”

[Kushal R. via NANOG]

This is great. Will be testing this later in the day. We like a lot of others 
were using BGPMon.

— Kushal R. Executive Management | Host4Geeks
Email: kusha...@h4g.co Skype: kush.raha Phone (Text/WhatsApp): +1-310-405-0010 
[tel:+1-310-405-0010] (Global) / +91-8830547876 [tel:+91-8830547876] (India)
On Wed, Aug 14, 2019 at 10:19pm, Eric Lindsjö < e...@emj.se [e...@emj.se] > 
wrote: On 8/14/19 4:54 PM, Job Snijders wrote:
> Dear NANOG,
>
> Recently NTT investigated how to best monitor the visibility of our
> own and our subsidiaries’ IP resources in the BGP Default-Free Zone.
> We were specifically looking how to get near real-time alerts funneled
> into an actionable pipeline for our NOC & Operations department when
> BGP hijacks happen.
>
> Previously we relied on a commercial “BGP Monitoring as a Service”
> offering, but with the advent of RIPE NCC’s “RIS Live” streaming API
> [1] we saw greater potential for a self-hosted approach designed
> specifically for custom integrations with various business processes.
> We decided to write our own tool “BGPalerter” and share the source
> code with the Internet community.
>
> BGPalerter allows operators to specify in great detail how to
> distribute meaningful information from the firehose from various BGP
> data sources (we call them “connectors”), through data processors
> (called “monitors”), finally outputted through “reports” into whatever
> mechanism is appropriate (Slack, IRC, email, or a call to your
> ticketing system’s API).
>
> The source code is available on Github, under a liberal open source
> license to foster community collaboration:
>
> https://github.com/nttgin/BGPalerter
>
> If you wish to contribute to the project, please use Github’s “issues”
> or “pull request” features. Any help is welcome! We’d love suggestions
> for new features, updates to the documentation, help with setting up a
> CI regression testing pipeline, or packaging for common platforms.
>
> Kind regards,
>
> Job & Massimo
> NTT Ltd
>
> [1]: https://ris-live.ripe.net/

Excellent, now I don't have to write it myself. Looking forward to
testing. Thanks for sharing the fruits of your labor with the community.


Kind regards,
Eric

Re: new BGP hijack & visibility tool “BGPalerter”

[Eric Lindsjö]

On 8/14/19 4:54 PM, Job Snijders wrote:

Dear NANOG,

Recently NTT investigated how to best monitor the visibility of our 
own and our subsidiaries’ IP resources in the BGP Default-Free Zone. 
We were specifically looking how to get near real-time alerts funneled 
into an actionable pipeline for our NOC & Operations department when 
BGP hijacks happen.


Previously we relied on a commercial “BGP Monitoring as a Service” 
offering, but with the advent of RIPE NCC’s “RIS Live” streaming API 
[1] we saw greater potential for a self-hosted approach designed 
specifically for custom integrations with various business processes. 
We decided to write our own tool “BGPalerter” and share the source 
code with the Internet community.


BGPalerter allows operators to specify in great detail how to 
distribute meaningful information from the firehose from various BGP 
data sources (we call them “connectors”), through data processors 
(called “monitors”), finally outputted through “reports” into whatever 
mechanism is appropriate (Slack, IRC, email, or a call to your 
ticketing system’s API).


The source code is available on Github, under a liberal open source 
license to foster community collaboration:


https://github.com/nttgin/BGPalerter

If you wish to contribute to the project, please use Github’s “issues” 
or “pull request” features. Any help is welcome! We’d love suggestions 
for new features, updates to the documentation, help with setting up a 
CI regression testing pipeline, or packaging for common platforms.


Kind regards,

Job & Massimo
NTT Ltd

[1]: https://ris-live.ripe.net/


Excellent, now I don't have to write it myself. Looking forward to 
testing. Thanks for sharing the fruits of your labor with the community.



Kind regards,
Eric

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[Rubens Kuhl]

On Wed, Aug 14, 2019 at 1:09 PM John Curran  wrote:

> On 14 Aug 2019, at 11:15 AM, Valdis Klētnieks 
> wrote:
> >
> > On Wed, 14 Aug 2019 02:42:09 -, John Curran said:
> >
> >> You might want want to ask them why they are now a problem when they
> weren’t
> >> before (Also worth noting that many of these ISP's own contracts with
> their
> >> customers have rather similar indemnification clauses.)
> >
> > Actually, it's probably ARIN that should be doing the asking, and seeing
> if
> > they can change the wording and/or rephrase the issue to allay concerns.
> >
> > It sounds to me like ARIN's *intent* was "if you get sued by your
> customers because
> > you screw the pooch on deployment, it's your screw-up to clean up and
> not our
> > problem". Or at least I *hope* that was the intent (see next paragraph)
>
> That is indeed the intent - please deploy routing validation using best
> practices, so that you & your customers don’t suffer any adverse impact
> when ARIN's repository is not available.
>
>
Or, move all your number resources to a subsidiary in the AP region, pay
membership fees to APNIC instead of ARIN, and use their trust anchor
instead of ARIN's.
BTW, since all 5 RIRs have certificates signing the whole IP address space,
it really makes no difference.


Rubens

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[John Curran]

On 14 Aug 2019, at 11:15 AM, Valdis Klētnieks  wrote:
> 
> On Wed, 14 Aug 2019 02:42:09 -, John Curran said:
> 
>> You might want want to ask them why they are now a problem when they weren’t
>> before (Also worth noting that many of these ISP's own contracts with their
>> customers have rather similar indemnification clauses.)
> 
> Actually, it's probably ARIN that should be doing the asking, and seeing if
> they can change the wording and/or rephrase the issue to allay concerns.
> 
> It sounds to me like ARIN's *intent* was "if you get sued by your customers 
> because
> you screw the pooch on deployment, it's your screw-up to clean up and not our
> problem". Or at least I *hope* that was the intent (see next paragraph)

That is indeed the intent - please deploy routing validation using best 
practices, so that you & your customers don’t suffer any adverse impact when 
ARIN's repository is not available.

> But I suspect a lot of companies are reading it as: "If a spammer sues you 
> for using
> a block list that prevents them from spamming your customers, you can't end up
> owing money to the block list maintainers.  But if you rely on the ARIN TAL, 
> and get
> sued by an address hijacker, you could end up owing money to ARIN”.

It’s is not “you owe money to ARIN’, but it could be “you need to defend both 
yourself and ARIN from your customers’ litigation should you get it wrong."

> (Having said that, John, it takes a special sort of CEO to stand out and be 
> seen
> in situations like this, and the world could probably use more CEO's like 
> that…)

 fairly easy to do if one has a thick skin… ;-)

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers




signature.asc
Description: Message signed with OpenPGP

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[Valdis Klētnieks]

On Wed, 14 Aug 2019 02:42:09 -, John Curran said:

> You might want want to ask them why they are now a problem when they weren’t
> before (Also worth noting that many of these ISP's own contracts with their
> customers have rather similar indemnification clauses.)

Actually, it's probably ARIN that should be doing the asking, and seeing if
they can change the wording and/or rephrase the issue to allay concerns.

It sounds to me like ARIN's *intent* was "if you get sued by your customers 
because
you screw the pooch on deployment, it's your screw-up to clean up and not our
problem". Or at least I *hope* that was the intent (see next paragraph)

But I suspect a lot of companies are reading it as: "If a spammer sues you for 
using
a block list that prevents them from spamming your customers, you can't end up
owing money to the block list maintainers.  But if you rely on the ARIN TAL, 
and get
sued by an address hijacker, you could end up owing money to ARIN".

(Having said that, John, it takes a special sort of CEO to stand out and be seen
in situations like this, and the world could probably use more CEO's like 
that...)





pgpqCVyRjaf5u.pgp
Description: PGP signature

new BGP hijack & visibility tool “BGPalerter”

[Job Snijders]

Dear NANOG,

Recently NTT investigated how to best monitor the visibility of our own and
our subsidiaries’ IP resources in the BGP Default-Free Zone. We were
specifically looking how to get near real-time alerts funneled into an
actionable pipeline for our NOC & Operations department when BGP hijacks
happen.

Previously we relied on a commercial “BGP Monitoring as a Service”
offering, but with the advent of RIPE NCC’s “RIS Live” streaming API [1] we
saw greater potential for a self-hosted approach designed specifically for
custom integrations with various business processes. We decided to write
our own tool “BGPalerter” and share the source code with the Internet
community.

BGPalerter allows operators to specify in great detail how to distribute
meaningful information from the firehose from various BGP data sources (we
call them “connectors”), through data processors (called “monitors”),
finally outputted through “reports” into whatever mechanism is appropriate
(Slack, IRC, email, or a call to your ticketing system’s API).

The source code is available on Github, under a liberal open source license
to foster community collaboration:

https://github.com/nttgin/BGPalerter

If you wish to contribute to the project, please use Github’s “issues” or
“pull request” features. Any help is welcome! We’d love suggestions for new
features, updates to the documentation, help with setting up a CI
regression testing pipeline, or packaging for common platforms.

Kind regards,

Job & Massimo
NTT Ltd

[1]: https://ris-live.ripe.net/

Re: Protecting 1Gb Ethernet From Lightning Strikes

[Måns Nilsson]

Subject: Re: Protecting 1Gb Ethernet From Lightning Strikes Date: Wed, Aug 14, 
2019 at 02:01:01PM +0200 Quoting Bjørn Mork (bj...@mork.no):
> Måns Nilsson  writes:
> 
> > /Måns, has 6 pairs 9/125 between garage and house at home. 
> 
> Now you made me worry that my single OM4 pair to the garden shed might
> be insufficient ;-)

I have but one comment: "Friends don't let friends run multimode." 

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE   SA0XLR+46 705 989668
Yow!  I'm having a quadrophonic sensation of two winos alone in a steel mill!


signature.asc
Description: PGP signature

Re: Protecting 1Gb Ethernet From Lightning Strikes

[Bjørn Mork]

Måns Nilsson  writes:

> /Måns, has 6 pairs 9/125 between garage and house at home. 

Now you made me worry that my single OM4 pair to the garden shed might
be insufficient ;-)


Bjørn

Re: RPKI adoption

[Job Snijders]

Dear all,

On Wed, Aug 14, 2019 at 10:36:44AM +, John Curran wrote:
> On 14 Aug 2019, at 2:26 AM, Matthew Petach  wrote:
> > ...
> > Now, at the risk of bringing down the ire of the community on my
> > head...ARIN could consider tying the elements together, at least for
> > ARIN members.  Add the RPKI terms into the RSA document.  You need
> > IP number resources, congratulations, once you sign the RSA, you're
> > covered for RPKI purposes as well.
> 
> Matthew - 
> 
>   Yes indeed - this is one of several potential improvements that we’re 
> also investigating. 

I've attempted to produce a humorous world map chart to help clarify
there is a degree of asymmetry our community may need to consider:


http://instituut.net/~job/screenshots/e079d90a-3047-4034-8e7c-9caf6e387f1a.png

The ARIN members (mostly located in the red area) would like all
not-ARIN-members (located in the blue area, the rest of the world) to
use and honor their ROAs published through ARIN's RPKI service.

If not for the purpose of facilitating BGP Origin Validation on as many
as possible of Internet's routers to protect one's IP resources, why
else would anyone publish RPKI ROAs through their RIR?

In other words: ARIN members want something (something very reasonable!)
from "the rest of the world", but in order to accomplish that
'something', unfortunately "the rest" needs to agree to the ARIN RPA.
This has proven to be somewhat of an adoption barrier.

It would be fantastic when "the rest" are not required to do any such
thing and the ARIN RPKI TAL can be distributed without restrictions or
limitations.

I would love to see any solution that removes all potential friction for
"the rest of the world", even if that shifts some additional burden to
ARIN members themselves; because it's ARIN members that want something
from the world, less so the other way around.

On Wed, Aug 14, 2019 at 4:42 AM John Curran  wrote:
> Interestingly enough, those same indemnification clauses are in the
> registration services agreement that they already signed but
> apparently they were not an issue at all when requesting IP address
> space or receiving a transfer.

Your observation (if correct) indeed is very interesting, and perhaps
demonstrates that RPKI business is something between ARIN and ARIN's
members, and less so between ARIN and all other potential relaying
parties on this planet. Or phrased differently: perhaps only ARIN
members should be the ones incurring the cost and burden of reviewing
and accepting ARIN's agreements.

I'd like to express my appreciation to ARIN's staff & ARIN's Board of
Trustees for dedicating their time and resources to research how to
improve in this context.

Kind regards,

Job

ps. Ofcourse this map is an oversimplification of the situation,
apologies for any inaccuracies.

Re: Protecting 1Gb Ethernet From Lightning Strikes

[Måns Nilsson]

Subject: Protecting 1Gb Ethernet From Lightning Strikes Date: Tue, Aug 13, 2019 
at 02:22:12PM -0400 Quoting Javier J (jav...@advancedmachines.us):
> I'm working with a client site that has been hit twice, very close by
> lightening.
> 
> I did lots of electrical work/upgrades/grounding but now I want to focus on
> protecting Ethernet connections between core switching/other devices that
> can't be migrated to fiber optic.

If lightning comes so close that it will break things inside the same
facility because they are connected by structured cabling, two things
typically have failed;

* The building as such is not adequately protected.

* There exist too large potential differences within the electrical
  system inside the building.

For #1, telecoms regulations on site grounding and protection give good,
albeit expensive advice. The most important part is that all cabling
enter the facility with its screens at common potential. The reason
is that most blown equipment comes from in-ground potential difference
between different cables. (I've poured shattered IC's out of a poor ADSL
router after such a strike. ) If that potential difference is cancelled
upon entry in the facility by bonding all grounds the risk is minimised.

For #2, it is mostly solved by fixing #1, but it is proper to fix it by
mesh-connecting grounds on all equipment together. If there is a 10mm^2
(around AWG7) bonding conductor parallel to the 0,14mm^2 (AWG25) drain
wire in the foil screen, which way will the current take?
Do note that star grounds are popular, but they're impossible to maintain
and typically don't work at high frequiencies, which will lessen their
efficiency against fast-rising transients. Mesh grounds are better at
conducting high frequencies and are easier to maintain.

Having several power utility feeds into same facility will of course
exacerbate the problem, which is one of the reasons it is illegal
in Sweden.

If you need to cross between two buildings, copper should be
rejected. Fiber is so much better. And pays for itself immediately upon
first strike survived.

/Måns, has 6 pairs 9/125 between garage and house at home. 
-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE   SA0XLR+46 705 989668
I feel partially hydrogenated!


signature.asc
Description: PGP signature

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[John Curran]

On 14 Aug 2019, at 1:21 AM, Ronald F. Guilmette 
mailto:r...@tristatelogic.com>> wrote:

In message 
<06570278-e1ad-4bb0-a9fc-11a77bed7...@arin.net>,
John Curran mailto:jcur...@arin.net>> wrote:

Even so, we at ARIN are in the midst of a Board-directed review of the RPKI
legal framework to see if any improvements can be made   – I will
provide further updates once it is completed.

This is an excellent presentation John, and I'm real glad to see that you
have done such a nice job on it and touched on all of the important points.

In particular, I'm glad that you clarified that if everyone is just doing
what they ought to be doing, i.e. following best practices, then even if
RPKI central and all of its sister satellites should all be simultaneously
hit by metorites, then in theory at least, nobody should be any worse off
than they already are today.

And yes, I can't argue and won't argue that some folks aren't going to be
bozos and screw up their RPKI deployment, and then some of them -may-
possibly want to blame ARIN for -their- screw ups, but I continue to have
trouble envisioning how this would ever traslate into a lawsuit that
wouldn't simply be laughed out of court in about five seconds if handled
properly.

Alas, it’s not those who fail to properly configure RPKI that are likely to be 
litigating, but rather their impacted customers and those customers' business 
partners who all were unable to communicate due to no fault of their own.

Such a matter will not be thrown out of court, but will be the start of a long 
and very expensive process involving claims, discovery, experts, etc.  (a 
recent legal matter that was promptly resolved in ARIN’s favor pre-litigation 
still resulted in more than 1/3 million USD in costs...)   Absent a specific 
reason for dismissal, it is only in actual trial that the preponderance of 
evidence gets considered – and note that in such a dispute, we’d end up with a 
jury of regular folks hearing fairly technical arguments about certificate 
validation, covering ROA’s, caching, etc.In other words, even if handled 
perfectly, your five second estimate is likely off by a year or more (and hence 
the reason for indemnification - it provides a clear basis for ARIN’s exit from 
the matter, as it makes plain that the liability resulting from use of the RPKI 
repository lies with the ISP.)

Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers

Re: RPKI adoption

[John Curran]

On 14 Aug 2019, at 12:51 AM, Hank Nussbacher  wrote:
> …
> Just like to add kudos to John for being open and responsive on this list and 
> other lists to numerous issues and questions in regards to ARIN.  Not many 
> CEOs are willing or able to respond as you do.  

Hank - 

Thanks! – as I work for you (i.e. this collective community), I see it 
as a reasonable obligation to be reachable/answerable regarding how your 
registry is being run.

/John

John Curran
President and CEO
American Registry for Internet Numbers

p.s.  As a reminder, those interested in more prominent/direct role in 
oversight of ARIN should consider running for the Board of Trustees…  

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[John Curran]

On 14 Aug 2019, at 2:26 AM, Matthew Petach  wrote:
> ...
> Now, at the risk of bringing down the ire 
> of the community on my head...ARIN could
> consider tying the elements together, at 
> least for ARIN members.  Add the RPKI terms 
> into the RSA document.  You need IP number
> resources, congratulations, once you sign the
> RSA, you're covered for RPKI purposes as well.

Matthew - 

Yes indeed - this is one of several potential improvements that we’re 
also investigating. 

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[John Curran]

On 14 Aug 2019, at 1:01 AM, William Herrin  wrote: 
> ...
> >  I would observe that continued use at that point has been held
> > to indicate agreement on your part [ref: Register.com, Inc. v. Verio, Inc., 
> > 356 F.3d 393 (2d Cir. 2004)]
> 
> In which Verio admitted to the court that they knew they were abusing 
> Register's computers but figured Register's contract with ICANN gave them the 
> right. The court would have reached the same decision regardless of 
> Register's notice: You're abusing computers that aren't yours. Stop it.

BIll - 

The particular finding from Register v. Verio that is relevant was that a user 
made aware of applicable terms with each query (even at the end) is sufficient 
for contractual binding after continued use.  

> Specht v. Netscape Communications Corp, on the other hand, found that, 
> "plaintiffs neither received reasonable notice of the existence of the 
> license terms nor manifested unambiguous assent" to the contract Netscape 
> offered for the use of their software at download-time, including assent to 
> settle disputes through arbitration.

Register v. Verio was after Specht v Netscape, and distinguished the situation 
where the user received terms at the end of each response from those cases 
where a user couldn’t reasonably determine that there were any applicable terms 
and conditions. 

> I'll take any bet you care to offer that the latter precedent applies to 
> casual consumer use of ARIN's whois.

That bet is available to you at any time by violating the terms the ARIN’s 
Whois service, so the question to ask yourself is: "do you feel lucky?”

Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers

Re: provider email maintenance standard

[Andrew Dampf]

I ended up writing a flask app that parses provider maintenance emails and
posts slack notifications at the start and end of the window. You can also
extend it to take actions like drain/undrain traffic during windows. Right
now the five supported providers are NTT, PacketFabric, EUNetworks, GTT,
and Zayo. The first three follow the MAINTNOTE standard. The last two were
done via bs4 and good old regex. Upcoming parsers are in the works for
Reliance, CenturyLink, and Tata.

I hope others find this useful and deploy it for their networks. Let me
know what you think and if you'd like to contribute:
https://github.com/wasabi222/janitor

Here are some screencaps: https://imgur.com/a/tMTlMwH

If you know of more providers that follow the MAINTNOTE standard, please
let me know so I can add them to the parser. Thanks!

On Tue, Jun 18, 2019 at 12:38 PM Erik Sundberg 
wrote:

> Back at NANOG in Chicago 2016 someone was working on a standards for
> Maintenance notifications with calendar invites attached. Not sure what
> happened with it.
>
> I think this was it.
> https://archive.nanog.org/meetings/abstract?id=2853
>
>
>
> Erik Sundberg
> Sr. Network Engineer
>
> office 773.661.5532
> mobile   708.710.7419
> noc 866.892.0915
>
> esundb...@nitelusa.com
>
> 888.450.2100
> 350 N Orleans St. #1300N
> Chicago, IL 60654
> nitelusa.com
>
>
> Smarter technology made simple
>
>
> -Original Message-
> From: NANOG  On Behalf Of Jay Hanke
> Sent: Tuesday, June 18, 2019 8:41 AM
> To: Job Snijders 
> Cc: North American Network Operators' Group 
> Subject: Re: provider email maintenance standard
>
> > https://github.com/jda/maintnote-std/blob/master/standard.md
> >
> > NTT / AS 2914’s NOC follows this process to keep customers and partners
> informed about maintenances.
>
> Is there commercial or open source software that already has this
> implemented?
>
> 
>
> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files
> or previous e-mail messages attached to it may contain confidential
> information that is legally privileged. If you are not the intended
> recipient, or a person responsible for delivering it to the intended
> recipient, you are hereby notified that any disclosure, copying,
> distribution or use of any of the information contained in or attached to
> this transmission is STRICTLY PROHIBITED. If you have received this
> transmission in error please notify the sender immediately by replying to
> this e-mail. You must destroy the original transmission and its attachments
> without reading or saving in any manner. Thank you.
>

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[Matthew Petach]

On Tue, Aug 13, 2019 at 5:44 PM John Curran  wrote:

> On 13 Aug 2019, at 9:28 PM, Ronald F. Guilmette 
> wrote:
>
> ...
> The last time I looked, RPKI adoption was sitting at around a grand total
> of 15% worldwide.  Ah yes, here it is...
>
>   https://rpki-monitor.antd.nist.gov/
>
> I've asked many people and many companies why adoption remains so low, and
> why their own companies aren't doing RPKI.  I've gotten the usual
> assortment
> of utterly lame excuses, but the one that I have had the hardest time
> trying to counter is the one where a network engineer says to me "Well,
> ya know, we were GOING to do that, but then ARIN... unlike the other four
> regional authorities... demanded that we sign some silly thing indemnifying
> them in case of something.
>
>
> Interestingly enough, those same indemnification clauses are in the
> registration services agreement that they already signed but apparently
> they were not an issue at all when requesting IP address space or receiving
> a transfer.
> You might want want to ask them why they are now a problem when they
> weren’t before (Also worth noting that many of these ISP's own contracts
> with their customers have rather similar indemnification clauses.)
>

Hi John,

There are things companies will sign
when their backs are up against the wall
that they will balk at signing when it is
for an optional geek-ish extra.

IP addresses are the lifeblood of the
tech industry.  If you don't have an
IP address, you don't exist on the
Internet.  (Apologies to those of us
who still have modems configured
to call and retrieve mail addressed
with UUCP bang paths).

So, companies will grudgingly and with
much hand-wringing sign the RSA
necessary to get IP space.  Without,
they die.  Rather like oxygen; if we
had to sign a license agreement in
order to receive air to breathe, you'd
find most people would sign pretty
horrific terms of service agreements.

Slip those same terms in front of someone
as a requirement for them to buy beer,
and you'll likely discover a whole lot of
people are just fine drinking something
else instead.

So too with the RSA terms versus the
RPKI terms.

As companies, we can't survive without
IP addresses.  We'll sign just about anything
to stay alive.

RPKI is a geek toy.  It's not at all required
for a business to stay alive on the Internet,
so companies feel much safer in saying
"no way will we sign that!".

Now, at the risk of bringing down the ire
of the community on my head...ARIN could
consider tying the elements together, at
least for ARIN members.  Add the RPKI terms
into the RSA document.  You need IP number
resources, congratulations, once you sign the
RSA, you're covered for RPKI purposes as well.

That doesn't solve the issue for out-of-region
folks who don't have an RSA with ARIN; but
that's no worse than you are today; and by
bundling the RPKI terms in with the rest of the
RSA, you at  least get everyone in the ARIN
region that wants^Wneeds to maintain their
IP number resources in order to stay in business
on the Internet covered in terms of being able to
use the RPKI data.

If you've got them by the short and curlies
already, might as well bundle everything in
while they've got the pen in their hand.  ^_^;

Even so, we at ARIN are in the midst of a Board-directed review of the RPKI
> legal framework to see if any improvements can be made <
> https://www.arin.net/vault/participate/meetings/reports/ARIN_43/PDF/PPM/curran_rpki.pdf>
>  – I will provide further updates once it is completed.
>

Best of luck!  I know we'll all be watching carefully to
see how it goes.:)

Matt


> Thanks!
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
>