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.
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.
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.
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.
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.
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.
[+] [-] tialaramex|7 years ago|reply
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|7 years ago|reply
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.
[+] [-] motohagiography|7 years ago|reply
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|7 years ago|reply
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|7 years ago|reply
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|7 years ago|reply
[+] [-] Alex_Band|7 years ago|reply
[+] [-] bmurray7jhu|7 years ago|reply
[+] [-] bickford|7 years ago|reply
https://arstechnica.com/information-technology/2010/11/how-c...
https://www.theregister.co.uk/2017/12/13/suspicious_bgp_even...
[+] [-] EthanHeilman|7 years ago|reply