Who's running all those tiny RPKI servers?
blog.apnic.net
Who's running all those tiny RPKI servers?
1–10 of 19 posts
Re: Who's running all those tiny RPKI servers?
#2Cool stuff. Though I've never quite understood how RPKI solves route hijacks. The article says it validates that you're allowed to announce a given prefix outright, but I thought the idea behind a BGP hijack was that you just say you have a good route towards a given prefix, and traffic flows through you as a result?
Re: Who's running all those tiny RPKI servers?
#3Cool stuff. Though I've never quite understood how RPKI solves route hijacks. The article says it validates that you're allowed to announce a given prefix outright, but I thought the idea behind a BGP hijack was that you just say you have a good route towards a given prefix, and traffic flows through you as a result?
RPKI mainly makes the administrative side of the route database more formal and rigorous than previous internet routing registry implementations. The processes for using them to improve network security are discussed at https://manrs.org/
They have a neat dashboard at https://observatory.manrs.org/
Re: Who's running all those tiny RPKI servers?
#4Cool stuff. Though I've never quite understood how RPKI solves route hijacks. The article says it validates that you're allowed to announce a given prefix outright, but I thought the idea behind a BGP hijack was that you just say you have a good route towards a given prefix, and traffic flows through you as a result?
The RPKI fix is that any node in a rpki tree is signed by the certificate from the authority above it, all the way up until some root certificate that you trust.
So you cannot have some party hijacking a prefix, it would not be signed by its parent authority.
Re: Who's running all those tiny RPKI servers?
#5Cool stuff. Though I've never quite understood how RPKI solves route hijacks. The article says it validates that you're allowed to announce a given prefix outright, but I thought the idea behind a BGP hijack was that you just say you have a good route towards a given prefix, and traffic flows through you as a result?
There's two kinds of route hijacks. Origin or path based.
RPKI addresses who is allowed to originate a prefix. There are other technical changes that need to be implemented to get path validation, this cloud flare blog has a good write up on the issues/solutions.
Re: Who's running all those tiny RPKI servers?
#6Cool stuff. Though I've never quite understood how RPKI solves route hijacks. The article says it validates that you're allowed to announce a given prefix outright, but I thought the idea behind a BGP hijack was that you just say you have a good route towards a given prefix, and traffic flows through you as a result?
There's two kinds of route hijacks. Origin or path based. RPKI addresses who is allowed to originate a prefix. There are other technical changes that need to be implemented to get path validation, this cloud flare blog has a good write up on the issues/solutions. https://blog.cloudflare.com/bgp-route-leak-venezuela/
There's another quite good blog from Cloudflare about this here too:
Re: Who's running all those tiny RPKI servers?
#7Cool stuff. Though I've never quite understood how RPKI solves route hijacks. The article says it validates that you're allowed to announce a given prefix outright, but I thought the idea behind a BGP hijack was that you just say you have a good route towards a given prefix, and traffic flows through you as a result?
There's two kinds of route hijacks. Origin or path based. RPKI addresses who is allowed to originate a prefix. There are other technical changes that need to be implemented to get path validation, this cloud flare blog has a good write up on the issues/solutions. https://blog.cloudflare.com/bgp-route-leak-venezuela/
RPKI addresses both.
Route Origin Authorizations (ROAs) enforce which ASes are allowed to originate a prefix. ROAs address origin hijacks, and have been around for longer.
Autonomous System Provider Authorizations (ASPAs) enforce which ASes are allowed to be adjacent to each other in an AS_PATH. ASPAs address path hijacks, and were introduced more recently. It used to be that you had to self-host (as in the article) in order to publish ASPAs, but RIRs are now starting to support them on their hosted RPKI offerings. I'm surprised the article didn't mention this as a reason to run your own RPKI.
If the first hop publishes a ROA, and all subsequent hops publish an ASPA, then the full path can be validated.
Re: Who's running all those tiny RPKI servers?
#8Earlier quoted context omitted.
There's two kinds of route hijacks. Origin or path based. RPKI addresses who is allowed to originate a prefix. There are other technical changes that need to be implemented to get path validation, this cloud flare blog has a good write up on the issues/solutions. https://blog.cloudflare.com/bgp-route-leak-venezuela/
RPKI addresses both. Route Origin Authorizations (ROAs) enforce which ASes are allowed to originate a prefix. ROAs address origin hijacks, and have been around for longer. Autonomous System Provider Authorizations (ASPAs) enforce which ASes are allowed to be adjacent to each other in an AS_PATH. ASPAs address path hijacks, and were introduced more recently. It used to be that you had to self-host (as in the article)…
What's the history and status of ASPA? As far as I can see, it's a fairly active draft with the IETF: https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-ver...
It says it's on the standards track, but it's clearly quite new. How well has it been proven out? This page from Hurricane Electric shows https://bgp.he.net/report/rpki_and_aspa
Re: Who's running all those tiny RPKI servers?
#9Earlier quoted context omitted.
RPKI addresses both. Route Origin Authorizations (ROAs) enforce which ASes are allowed to originate a prefix. ROAs address origin hijacks, and have been around for longer. Autonomous System Provider Authorizations (ASPAs) enforce which ASes are allowed to be adjacent to each other in an AS_PATH. ASPAs address path hijacks, and were introduced more recently. It used to be that you had to self-host (as in the article)…
What's the history and status of ASPA? As far as I can see, it's a fairly active draft with the IETF: https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-ver... It says it's on the standards track, but it's clearly quite new. How well has it been proven out? This page from Hurricane Electric shows https://bgp.he.net/report/rpki_and_aspa
It's still very early. RIPE and ARIN have only supported publishing them for a few months. ARIN made very little noise about it during the rollout, and many networks are probably still unaware. Give it a couple years, and I expect we'll see fairly good adoption among those already publishing ROAs. There will still be the never-RPKI holdouts, however.
HE publishes their full ASPA table here, if you're interested in digging in: https://routing.he.net/?cmd=display_aspa_table
Re: Who's running all those tiny RPKI servers?
#10Earlier quoted context omitted.
There's two kinds of route hijacks. Origin or path based. RPKI addresses who is allowed to originate a prefix. There are other technical changes that need to be implemented to get path validation, this cloud flare blog has a good write up on the issues/solutions. https://blog.cloudflare.com/bgp-route-leak-venezuela/
RPKI addresses both. Route Origin Authorizations (ROAs) enforce which ASes are allowed to originate a prefix. ROAs address origin hijacks, and have been around for longer. Autonomous System Provider Authorizations (ASPAs) enforce which ASes are allowed to be adjacent to each other in an AS_PATH. ASPAs address path hijacks, and were introduced more recently. It used to be that you had to self-host (as in the article)…
Note that the first hop has to publish both ROA and ASPA records, as ASPA records describes a set of valid providers.