Hi Nanog list,
Would be interesting to hear your opinion on this:
https://isbgpsafeyet.com/
We have cases when residential customers ask support "why is your service isn't safe?" pointing to that article. It's difficult to answer correctly considering that the asking person usually doesn't know what BGP is and what it's used for, save for understanding it's function, design and possible misuses.
IMO, on one hand it promotes and is aimed to push RPKI deployment, on the other hand is this a proper way for it? How ethical is to claim other market players unsafe, considering that scope of possible impact of not implementing it has completely different scale for a small stub network and big transit provider?
Kind regards,
Andrey
Hi Nanog list,
Would be interesting to hear your opinion on this:
https://isbgpsafeyet.com/
From a practical standpoint, this doesn't actually tell the whole truth
in our case because we do not accept the ARIN TAL. Given that this
system is "ARIN-based", it says we aren't safe.
Swiftly moving on...
We have cases when residential customers ask support "why is your
service isn't safe?" pointing to that article. It's difficult to
answer correctly considering that the asking person usually doesn't
know what BGP is and what it's used for, save for understanding it's
function, design and possible misuses.
IMO, on one hand it promotes and is aimed to push RPKI deployment, on
the other hand is this a proper way for it? How ethical is to claim
other market players unsafe, considering that scope of possible impact
of not implementing it has completely different scale for a small stub
network and big transit provider?
On count two, my experience with doing the RPKI deployathon in Melbourne
during this past APRICOT led to some random news web site talking about
how "I would be shedding all invalid routes blah blah", which while not
untrue, had locals all the way in South Africa asking if the Internet
was going to collapse.
So while I think these initiatives are useful, considering that
information has been democratized to such an extent that it is now a
commodity, we might do well to consider the fallout for folk that do not
know (or care) about how the Internet works, but know that their lives
depend on it, and what that means for our individual SNR's.
Mark.
( Speaking 100% for myself. )
I think it was tremendously irresponsible, especially in the context of current events, to take a complex technical issue like this and frame it to the general public as a ‘safety’ issue.
It’s created articles like this : https://www.wired.com/story/cloudflare-bgp-routing-safe-yet/ , which are terrible because they imply that RPKI is just some simple thing that anyone not doing is just lazy or stupid. Very few people will read to the bottom note about vendors implementing RPKI support, or do any other research on the issue and challenges that some companies face to do it. It’s not their job; that’s ours.
I feel like there has been more momentum in getting more people to implement PKI in the last 18-24 months. ( Maybe others with different visibility have different opinions there. ) There are legitimate technical and business reasons why this isn’t just a switch that can be turned on, and everyone in our industry knows that.
In my opinion, Mr. Prince is doing a great disservice by taking this approach, and in the longer term RPKI adoption will likely be slower than it would have been otherwise. I genuinely appreciate much of what Cloudflare does for the sake of ‘internet good’ , but I believe they wildly missed the mark here.
Why do you think that RPKI adoption will be slowed due to this action by CloudFlare?
The issue is that due to the democratization of information, every one
is now an expert.
So if we thought something only appealed to an obvious audience, think
again.
Mark.
Technical people need to make the business case to management for RKPI by laying out what it would cost to implement (equipment, resources, ongoing opex), and what the savings are to the company from protecting themselves against hijacks. By taking this step, I believe RPKI will become viewed by non-technical decision makers as a ‘Cloudflare initiative’ instead of a ‘good of the internet’ initiative, especially by some companies who compete with Cloudflare in the CDN space.
I believe that will change the calculus and make it a more difficult sell for technical people to get resources approved to make it happen.
I'm not sure I'd go that far, but I do see your point.
Nowadays, if you are running a half-decent router vendor, chances are
any upgrades you are doing for normal things (adding capacity, moving
from Gig-E to 10Gbps, or from 10Gbps to 100Gbps) will bring RPKI along
for the ride by default.
We've seen that validators are free, and work very well.
Your ongoing RIR membership will get your access to getting your ROA's
signed, so you don't need to pay extra for that.
So while I can see how an article like this could make life interesting
within your business, I don't think much of it will hinge on "the cost
of implementing RPKI in terms of $$".
My company, for example, only found out we run RPKI because of the April
1, 2019 activation article that we, and Workonline published. And we'd
been testing and running RPKI since 2014 - and only because we had a
total network refresh to get rid of some clunky Cisco XR 12000 routers
(which probably support RPKI if you don't run IOS classic, hehe).
Mark.
We’ve seen that validators are free, and work very well.
Work on a technical level, yes. But there are legal concerns in the ARIN region with that, some of which are spelled out here, by ACTUAL lawyers.
https://pc.nanog.org/static/published/meetings/NANOG75/1900/20190219_Yoo_Rpki_Legal_Barriers_v1.pdf
Not going to dive any further into that subject here, wrong forum, but it’s illustrative of my overall point. Thar Were Dragons still to be slayed on this topic already, and I think CF has just made that harder.
I (and Ben, and a few others) are all too familiar with the ARIN madness
around their TAL.
Simple - we just don't accept it, which means our networks will be
unsafe against North American resources. Highly doubtful my organization
is that interested in how the ARIN region may or may not impact our
interest in deploying RPKI on this side of the planet, when the rest of
the world are less mad about it :-).
This policy was broken in 2014. And it's still broken in 2020.
Ah well... we keep moving.
Mark.
Thank you Mark, Tom and Chris for your responses that confirmed my "mixed feelings" about this tool.
As a side note, I mentioned from https://bgp.he.net/AS13335#_prefixes that AS13335 advertises a bunch or prefixes without RoA and even one invalid prefix, although I don't see it (only invalid one) from other sources. So it looks like an attempt to jump ahead and announce competitive leadership using marketing rather than technology. So for myself with your help I'd qualify it as aggressive push from technical PoV and offensive from marketing PoV. The former definitely has some positive effect which however could or could not be outweighted by the latter.
Kind regards,
Andrey
Tom Beecher писал 2020-04-20 12:24:
Just to point out, with such things, it's important to remain objective
and not lump everything into the same basket because as a society,
summary judgements is what we've evolved into since the Internet took
over, i.e., the details are too overbearing to weed through :-).
Rather, I'm sure many of us can easily deduce that any organization has
multiple competing entities within it all striving to do their bit for
the company. I know several folk at Cloudflare that I am almost sure
(even without asking them) are probably not so amused with the marketing
angle of this web site. But, as with the rest of their colleagues, they
are another cog in the wheel, keeping their heads down and minding their
business.
I'm able to separate them and the good work they do to advance the state
of RPKI deployment. In parallel I can also tune out all the fluff that
emerges from the periphery, which is neither here nor there :-).
Mark.
Technical people need to make the business case to management for RKPI by laying out what it would cost to implement (equipment, resources, ongoing opex), and what the savings are to the company from protecting themselves against hijacks. By taking this step, I believe RPKI will become viewed by non-technical decision makers as a 'Cloudflare initiative' instead of a 'good of the internet' initiative, especially by some companies who compete with Cloudflare in the CDN space.
you say here: "RPKI"
but the cloudflare thing is a little bit more nuanced than that, right?
'RPKI" is really: "Did you sign ROA for your IP Number Resources?"
what you do with the RPKI data is the 'more nuanced' part of the webpage.
1) Do you just sign?
2) do you sign and also do Origin Validation(OV) for your peers?
3) do you just do OV and not sign your own IP Number Resources?
I think CloudFlare (and other folk doing bgp security work) would like
'everyone' to:
1) sign ROA for their IP number resources
2) enable OV on your peerings
3) prefix filter all of your peerings
I believe that will change the calculus and make it a more difficult sell for technical people to get resources approved to make it happen.
I don't think that's the case... but I'm sure we'll be proven wrong 
-chris
Mark Tinka писал 2020-04-20 12:57:
I (and Ben, and a few others) are all too familiar with the ARIN madness
around their TAL.
Simple - we just don't accept it, which means our networks will be
unsafe against North American resources. Highly doubtful my organization
is that interested in how the ARIN region may or may not impact our
interest in deploying RPKI on this side of the planet, when the rest of
the world are less mad about it :-).
So this means that there is no single source of truth for PRKI implementation all around the world and there are different shades, right? As a logical conclusion, the information provided on that page may be considered incorrect in terms of proclaiming particular network safe or not safe, but when it's claimed (sometimes blatantly) we now have to prove to our clients that we are not bad guys.
Kind regards,
Andrey
The page seems very centred around the latter. The shaming is happening around the lack of filtering, not the absence of ROAs. The FAQ talks about “legitimate routes” but there’s not even a few words on how to actually make a route “legitimate".
The push for filtering may be a bit premature given the fact that North America has 7% Canada 3% ROA coverage[1]. There’s not much point in setting up filters if there’s no data to filter on. One could argue that with filtering an incentive arises to create ROAs, but this is not how things have evolved elsewhere in the world.
-Alex
[1] https://nlnetlabs.nl/projects/rpki/rpki-analytics/
There is simple use case that will prove this page is giving false positive
for their "name&shame" strategy.
Any AS owner with default route only (yes it happens a lot) users will get:
"YOUR ISP TERRIBLE, HIS BGP NOT SAFE!".
But he have nothing to validate! His BGP is implemented safely,
its just his upstream is not validating routes.
If i am not wrong, for most routers implementing RPKI means spinning up VM
with RPKI cache that need significant tinkering?
I guess it is a blocker for many, unless some "ready made" solutions offered
by vendors.
Also, if ISP configure his router and it did crashed because he installed
some "no warranty whatsoever" software from cloudflare github, what is next?
I guess this might be not welcome in support contracts.
P.S. Sorry for previous post top-posted. Just by mistake hit "Send" before i finished it
So, if we believe that the players here are working in the best
interest of the internet at large:
how could CloudFlare's page be more helpful? (with respect to
securing the global BGP system)
how could ISPs (and other internet operations) be more helpful?
(with respect to securing the global BGP system)
how could users validate if their ISP options are doing all they
can do for their users? (same global bgp system caveat)
(is this last bit helpful at all to them or to the various options
of ISP for that user?)
Having been trying to get more-better-securer internet for a time
now... happy to hear options
-chris
So, that same ISP who is not validating because it has a default route could push its providers to do validation and then be as safe as other validating themselves ?
Rubens
From a practical standpoint, this doesn't actually tell the whole truth
indeed. route origin validation, while a good thing, does not make
bgp safe from attack. this marketing fantasy is being propagated;
but is BS.
origin validation was designed to reduce the massive number of problems
cause by fat figured configuration errors by operators. it will not
even get all of those; but it will greatly improve things.
but it provides almost zero protection against malicious attack. the
attacker merely has to prepend (in the formal, not cisco display) the
'correct' origin AS to their malicious announcement.
randy