
RPKI – The required cryptographic upgrade to BGP routing - jgrahamc
https://blog.cloudflare.com/rpki/
======
tialaramex
One of the things Cloudflare describes is their CT log for the RPKI, Cirrus.

I can see why they did that, CT was a huge benefit for the Web PKI and many of
the things we did to the Web PKI are things they'd like to see happen for RPKI
- more people using it, better technical compliance by issuers, more eyeballs
on the problems, CT probably helped with some of those.

But the Web PKI is a vast sprawling mess. CT was necessary _because_ of that
mess, we know we can't stop it being a mess, so we needed technology that
could cope. The RPKI is neither vast, nor sprawling, nor especially messy.

A big part of what drove improvements to the Web PKI was the effort by people
with the power to get things changed. In the case of the Web PKI that's
Mozilla, the Mozilla community (since Mozilla is a charity) and to a lesser
extent the big commercial vendors, Microsoft, Apple, Google, Oracle. CT was a
_tool_ these players could use as part of that work, but on its own it didn't
get the job done.

But in RPKI there isn't really an equivalent. Companies like Cloudflare don't
have anywhere near the clout to get this done. Even the backbone providers
don't. And if we're to expect the RIRs to fix it, they don't need any help
getting insight on issuers when they themselves are the issuers.

So, Cirrus isn't hurting anything, but I hope its creators had very limited
expectations and expended minimal resources getting it up, because I doubt
it's a major part of the solution to our problems either.

~~~
bren2013
Is Cirrus mentioned in the blog post? I can't find it.

Right now, the way key compromise might be detected in RPKI is that a human
network operator notices a signed object which is obviously suspicious and
posts it on a mailing list. This is the same way that CA compromise was
detected in the Web PKI before CT.

CT was useful well before Chrome used their weight to make it required for all
new certificates because it was no particular burden on a few people (CA or
not) who saw a lot of certificates to add them to CT. This gave the people who
might not see a lot of certificates but want to find something weird a corpus
to dig into.

Same idea applies to RPKI. But yes, setting up Cirrus took very little of my
time.

~~~
tialaramex
You're correct, it's mentioned in the next/ accompanying post
[https://blog.cloudflare.com/rpki-details/](https://blog.cloudflare.com/rpki-
details/)

Some small corrections if I may

1\. I don't know of any issuer key compromises detected with CT. Such
compromises are rare. DigiNotar is an obvious example, but can you think of
any recent ones? Mostly CA incompetence is more subtle that "Oops we left the
root keys on a train" and I'd hope the same is true for RIRs.

2\. Technically CT is still not required. You can choose to obtain
certificates which aren't logged from a CA that will issue them without
logging. Neither Google nor Mozilla require you to log all certificates as a
condition of their root programmes and both recently confirmed they do not
intend to make that a requirement. Chrome will mark your cert as untrustworthy
if it hasn't got an SCT and so it would always make sense to log certificates
for a site Chrome users will access on the public Web, but not every TLS
certificate is for a web site accessed with Chrome.

[ Also, Google actually makes use of the fact that certs can exist without
being logged for some systems. Suppose they're about to launch
amazing.example.com, but even the Amazing name would give away what it is.
They can order the cert for amazing.example.com with no logging and stockpile
it, and when the brass signs off on actually announcing Amazing they log this
cert, almost instantly getting back SCTs, and configure a suitably modern web
server to send the SCTs separately alongside the certificate. Where ordering a
certificate internally might take hours or days, these final steps can be done
in a few minutes and need no special permission. Any subscriber whose CA is
willing to issue unlogged certificates can do this, but just make sure you
have all the steps correct or you'll look really dumb, even Google got this
wrong at least once since they began doing it ]

[edited to fix typo that reversed my meaning]

~~~
bren2013
> I don't know of any issuer key compromises detected with CT. Such
> compromises are rare. DigiNotar is an obvious example, but can you think of
> any recent ones?

Not key compromise, but general mis-issuance:

Facebook detected overreach by a vendor with CT:
[https://www.facebook.com/notes/protect-the-graph/early-
impac...](https://www.facebook.com/notes/protect-the-graph/early-impacts-of-
certificate-transparency/1709731569266987/)

AGL detected certs that were malformed in various ways:
[https://www.imperialviolet.org/2013/08/01/ctpilot.html](https://www.imperialviolet.org/2013/08/01/ctpilot.html)

> Technically CT is still not required.

It produces an interstitial, see: [https://invalid-expected-
sct.badssl.com/](https://invalid-expected-sct.badssl.com/)

------
motohagiography
We've known about BGP hijacking attacks for 20 years and they only seem to be
an issue now. In my day, kids would inject routes using spoofed RIP UDP
packets from dial-up pools that would get redistributed into the global
routing tables. I haven't 'sho ip' anything'ed in more than a decade, but it
appears that 20 years later, you can still just compromise a router and
announce whatever you want.

The threat model has changed, where then you could send some spam or harvest
passwords for shell logins, today we have things like millions of dollars in
piles of electronic cash sitting around relatively unprotected and
untraceable, a hyper-polarized political environment where people believe they
need strong anonymity protections to participate, and the ability to scale the
C&C functions for botnets to where they now resemble private darknets.

All the real action seems to be happening in software defined networks in the
cloud these days, but it all still depends on this legacy internet
infrastructure.

I'm glad CloudFlare is doing this. Someone needed to take the initiative. It
was one of those things where it was everybody's problem, which meant it was
nobody's problem.

~~~
icedchai
It turns out that most upstream providers have route filters, so you can't
just announce whatever you want...

I do remember those days in the 90's, though. I worked at a small ISP, and a
coworker blackholed a few spammers by just announcing their route and sending
all traffic to Null0. This was back in the Cisco 4000 days, when a full
routing table could fit in 32 megs. If I recall, our upstream was Sprintlink
and they didn't do any filtering at the time.

------
sneak
The reason that the existing BGP setup is so barebones (that is, lacking in
any meaningful security beyond simple route filtering) is because introducing
more complexity is failure-prone... and not just from error or
misconfiguration either. Outages, propagation, malice... there are a lot of
ways in which this could break and make things less reliable than they are
now.

My main concern is censorship. This would allow the RiRs, via revocations or
failures-to-renew a cert for a given address space, to knock a network off of
the internet without further human intervention on the part of the peers to
which the censored party is directly connected.

Give them this tooling, and their national governments or militaries will
demand its use when they are sufficiently angered, agitated, or threatened.

Can you really imagine the US military or DoJ not demanding RiRs use such a
tool against e.g. an AS hosting Wikileaks or Snowden files or The Shadow
Brokers?

I’m not sure that the current insecure BGP model is broken _enough_ to warrant
introducing this new cryptographic fail-closed failure mode.

------
ramshanker
So who gets the signing authority in this proposed/upcoming RPKI?

~~~
Alex_Band
The five Regional Internet Registries (ARIN, APNIC, LACNIC, AFRINIC and RIPE
NCC), who are responsible for registering IP addresses and AS Numbers in their
respective regions. They have the authoritative information on who is the
legitimate holder of a resource, so it fits the model.

~~~
sneak
So this means that the national governments/militaries of the countries in
which those entities are located would then have the practical ability to
force a revocation that causes someone’s routes to become invalid? This seems
like a giant legal SPoF for censorship.

~~~
jessaustin
ISTM if these entities were a threat of that sort, they would have already
caused problems? Besides ARIN, none of them are really under the control of
any one nation, are they?

~~~
sneak
Nothing the RiRs do right now immediately affects routing on the internet.
There is a patchwork of systems, some automatic, some manual, that eventually
converge their authority onto the routers that actually do the routing.

This proposal turns that system (which mostly works well) into a a system that
has somewhat centralized algorithmic control. If routers enforce valid signed
records for routing, suddenly the RiRs have an instant, practical power they
did not have before.

~~~
Alex_Band
First of all, BGP routing doesn't work that well at all. There's thousands of
BGP hijacks per year [1]; the ones you read about in the news are just the
most noteworthy. There are tons of smaller and larger outages because of fat
fingering and misconfigurations RPKI can help protect against.

Secondly, the RIRs also have the ability to revoke IP address allocations and
AS numbers, as well as whois database objects and IRR route objects. An RPKI
resource certificate is just a different representation of an RIR resource
registration, it's not going to make the difference you claim.

Then, it would also be fairly stupid of a government to abuse a system that is
designed to protect the internet from hijacking of critical infrastructure for
censorship purposes. The RIRs have done extensive outreach to make this clear
to their respective governments. Still, as soon as a government would try a
stunt like this, the networking community would simply walk away from this
technology in an instant.

Most importantly though, a revoked or expired certificate would result in a
BGP announcement with the status 'unknown', as if the operator doesn't
participate in the system and the route were never signed in the first place.
The route would never become invalid, and thus unreachable.

[1]
[https://www.internetsociety.org/blog/2018/01/14000-incidents...](https://www.internetsociety.org/blog/2018/01/14000-incidents-2017-routing-
security-year-review/)

~~~
sneak
Revoking an IP or AS allocation doesn’t actually immediately stop anyone from
using it in practice, though, until their peers stop treating them as valid
(which is not instantaneous upon RiR fiat).

The networking community would not walk away from abuse in a literal instant,
though. It would take days at a minimum, while censorship _would_ occur
instantly. It may be a single use weapon but it is still a weapon.

I am not sure that BGP is broken enough to warrant the signing of allocations
(or, more specifically, to fail-closed on unsigned/expired allocations).

------
bmurray7jhu
Nothing will change until there is a significant attack on BGP resulting in
widespread network outages.

~~~
bickford
Like these events?

[https://arstechnica.com/information-
technology/2010/11/how-c...](https://arstechnica.com/information-
technology/2010/11/how-china-swallowed-15-of-net-traffic-for-18-minutes/)

[https://www.theregister.co.uk/2017/12/13/suspicious_bgp_even...](https://www.theregister.co.uk/2017/12/13/suspicious_bgp_event_routed_big_traffic_sites_through_russia/)

~~~
bmurray7jhu
Never assume malice when incompetence suffices.

