I remember having this discussion more than 20yrs ago, minus the ARIN bit, couldn’t get every to agree to it it then either :(. We don’t need more rules, we just need to start with basic hygiene. Was a novel idea 
Typically, those who have "default route only" are too small to be heard,
and their "wishes" doesn't go beyond the first line of support.
Not to mention that it does not work at all if upstream is a monopoly,
especially a state monopoly, who wont move a finger for "optional features".
And most important, the most common answer:
All Tier-1 implemented it? No.
Major hosting operators, such as AWS, gcloud, etc? - No.
So...
Randy said,
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, I agree of course, that supporting ROV is far from sufficient to ensure BGP security. However, I disagree that this is `zero protection’ since the effectiveness of the attack may be much reduced when the attacker has to prepend. Note also that if one combines ASPA, the protection would be even better. The simulation results in our SIGCOMM’2016 give some idea of these benefits (imprecise, of course).
I think Randy will agree; but then again, Randy loves to surprise , so … maybe not.
Denys Fedoryshchenko писал 2020-04-20 15:27:
And most important, the most common answer:
All Tier-1 implemented it? No.
Major hosting operators, such as AWS, gcloud, etc? - No.
So...
Absolutely, RPKI has different scale of effectiveness and benefits for big telecoms or clouds vs small ISPs or datacenters. On the other hand, the impact of such "BGP safety" test is completely the opposite. For big guys it is the most effective to implement, but being "not BGP safe yet" - "yeah, who cares!" or in best case add to the plan for the next fiscal year. But for small market players it's vise-versa: effect of filtering is minimal but pressure from "not being safe" may be very real.
Kind regards,
Andrey
Randy said, > 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, I agree of course, that supporting ROV is far from sufficient to
ensure BGP security. However, I disagree that this is `zero protection'
since the effectiveness of the attack may be much reduced when the
attacker has to prepend. Note also that if one combines ASPA, the
protection would be even better. The simulation results in our
SIGCOMM'2016 give some idea of these benefits (imprecise, of course).
Folks, https://gph.is/1iwqrDk 
I think you can best capitalise on Origin Validation when OV is combined with other techniques such as AS_PATH filters (based on Peerlock or ASPA) or in some cases direct peering: https://www.slideshare.net/apnic/improving-the-peering-business-case-with-rpki
In local scope (IP traffic that will only travel a few milliseconds) I expect to see a substantial increase of robustness as more and more networks deploy OV (and peer directly with networks that matter to them!), however the long paths will remain comparatively more vulnerable. Much like any multi-company logistics system spanning the globe.
In the span of just two years we went from "you only need to overcome a single obstacle to insert bad routing information in the system", to a situation where more and more things need to go wrong before rogue announcements are seen universally. This is incredible progress in on a scale most people did not imagine possible. Are we there yet? No, but RPKI OV is a critical prerequisite to further progress.
From the last few days it seems to me we still have work ahead of us: folks need to receive training from their peers so they themselves can make informed decisions about RPKI. We should more openly compare notes about software defects and how to workaround them. We should talk about (privately) how to manoeuvre OV deployment projects along in large corporations, most companies don't have a manual for how to deploy something like RPKI OV
One of the best sources of documentation on RPKI is https://rpki.readthedocs.io/ - the docs are actively maintained to capture all common operational questions that pop-up over time.
Kind regards,
Job
Yes but that makes the hijacked AS path length at least 1 longer which makes it less likely that it can win over the true announcement. It is definitely better than nothing.
Also AS number filtering might be more prevalent than prefix filtering. If I know which origin ASNs I can accept from a peer and filter on that, then RPKI will prevent them from faking protected prefixes.
Regards,
Baldur
It did push me to implement RPKI filtering. Turned out to be quite easy. Took me all of 1-2 hours to do. Just went straight to dropping invalids and tested on one transit and one IX routing server. When that did look just fine, I could proceed with the remaining sessions.
As a bonus at least one of our transits now also implements RPKI filtering. That greatly increases the chance that we will retain a valid route during a prefix hijack attempt.
Regards,
Baldur
The RPKI software is something you need to run on a server somewhere. Not on the router itself.
For our Juniper MX204 routers this was all that I needed to do:
First install https://github.com/NLnetLabs/routinator on a server or VM somewhere. The server IP address would be 10.x.y.z in this example.
set routing-options validation group rpki-validator session 10.x.y.z port 3323 local-address 10.a.b.c
set policy-options community origin-validation-state-invalid members 0x4300:0.0.0.0:2
set policy-options community origin-validation-state-unknown members 0x4300:0.0.0.0:1
set policy-options community origin-validation-state-valid members 0x4300:0.0.0.0:0
set policy-options policy-statement RPKI-CHECK term valid from protocol bgp
set policy-options policy-statement RPKI-CHECK term valid from validation-database valid
set policy-options policy-statement RPKI-CHECK term valid then validation-state valid
set policy-options policy-statement RPKI-CHECK term valid then community add origin-validation-state-valid
set policy-options policy-statement RPKI-CHECK term invalid from protocol bgp
set policy-options policy-statement RPKI-CHECK term invalid from validation-database invalid
set policy-options policy-statement RPKI-CHECK term invalid then validation-state invalid
set policy-options policy-statement RPKI-CHECK term invalid then community add origin-validation-state-invalid
set policy-options policy-statement RPKI-CHECK term unknown from protocol bgp
set policy-options policy-statement RPKI-CHECK term unknown from validation-database unknown
set policy-options policy-statement RPKI-CHECK term unknown then validation-state unknown
set policy-options policy-statement RPKI-CHECK term unknown then community add origin-validation-state-unknown
set policy-options policy-statement REJECT-RPKI-INVALID term RPKI-CHECK from policy RPKI-CHECK
set policy-options policy-statement REJECT-RPKI-INVALID term RPKI-INVALID from community origin-validation-state-invalid
set policy-options policy-statement REJECT-RPKI-INVALID term RPKI-INVALID then reject
set routing-instances internet protocols bgp group nlix import REJECT-RPKI-INVALID
set routing-instances internet protocols bgp group cogent import REJECT-RPKI-INVALID
And just like that we had RPKI invalid filtering on the NLIX routing server and Cogent IP transit sessions. Since all of that is redundant, I took that opportunity to sanity check that we still had the expected amount of routes installed from these sources sans the invalids.
Attribution I did not invent most of the above. It is from the free book Day One Deploying BGP routing security from Juniper.
Regards,
Baldur
Attacker has no incentive to honor existing AS path, attacker can
rewrite it as they wish.
Anyhow I think some people think about RPKI in a way too binary manner
'because it is not secure, it is not useful'. Yes, AS_PATH
authenticity is an open problem, but this doesn't mean RPKI is
useless. Most of our BGP outages are not malicious, RPKI helps a lot
there and RPKI creates a higher quality database for prefix origin
information than what we have had.
tir. 21. apr. 2020 07.38 skrev Saku Ytti <saku@ytti.fi>:
Yes but that makes the hijacked AS path length at least 1 longer which makes it less likely that it can win over the true announcement. It is definitely better than nothing.
Attacker has no incentive to honor existing AS path, attacker can
rewrite it as they wish.
My company is in Europe. Lets say an attacker joins the IX in Seattle a long way from here and a place we definitely are not present at. We do however use Hurricane Electric as transit and they are peering freely at Seattle. Everyone there thus sees our prefix with an as path length of two. The attacker can originate the prefixes himself and that way his fake announcements win at Seattle by having the length 1. With RPKI he needs to use our ASN to originate and have his own ASN in between to facilitate peering. Thus the fake path also has the length of two. The real announcement wins by virtue of being the oldest announcement and the attack fails.
The situation is even worse for the attacker if he needs an IP transit company to pick up the fake announcement. We have Telia, which filters invalids, and if the attacker tries to get his fake prefix picked up by them, his path will end up being one longer than ours, so he can never succeed.
There are of course plenty of situations where the attack still succeeds. I am not claiming this is a magical bullet. Just saying it might do more than some thinks it will. Definitely better than nothing.
Regards
Baldur
I find it fascinating that in this entire thread about the nature of RPKI the shift in the role of the RIR hasn’t come up.
Instead of RIRs coordinating address space use by keeping a public list which is (or should be) checked when a new peering session is added, RPKI shifts RIRs into the hot path of routing updates. Next time the US government decides some bad, bad, very bad country should be cut off from the world with viral sanctions, there’s a new tool available - by simply editing a database, every border router in the world will refuse to talk to $EVIL.
By no means am I suggesting we should stop the RPKI train (and AS397444 happily drops invalids and has ROAs for all prefixes), but there’s a very cost here that doesn’t appear to have gotten much love, let alone mitigation effort. In the context of RIPE having to ask for permission to keep receiving payments from several Iranian LIRs, this isn’t completely inconceivable.
By way of an example, something like a waiting period for RIRs to add new ROAs replacing removed ROAs (which would imply some kind of signed replacement, but you get the point). At least ARIN already has a several-month quieting period after yanking resources for non-payment, why not use that to give operators time to think about whether they mind talking to Iran?
/ducks
Matt
I find it fascinating that in this entire thread about the nature of RPKI the shift in the role of the RIR hasn’t come up.
Instead of RIRs coordinating address space use by keeping a public list which is (or should be) checked when a new peering session is added, RPKI shifts RIRs into the hot path of routing updates.
The RIPE NCC has an IRR that is tightly coupled to the resource holder. With many networks requiring a route object to be published in the IRR for them to accept your announcement, the RPKI scenario that you describe has basically existed for the RIPE Database IRR since forever. This tight coupling doesn’t exist for the RADB and ARIN and as a result it is full of incorrect data, which is one of the reasons RPKI exists in the first place.
Removing a resource from the certificate to achieve the goal you describe will make the route announcement NotFound, which means it will be accepted. Evil RIR would have to replace an existing ROA with one that explicitly makes a route invalid, i.e. issue an AS0 ROA for specific member prefix. This seems like a pretty convoluted way to try and take a network offline.
Next time the US government decides some bad, bad, very bad country should be cut off from the world with viral sanctions, there’s a new tool available - by simply editing a database, every border router in the world will refuse to talk to $EVIL.
ARIN has taken pretty drastic nonrepudiation measures:
https://www.arin.net/resources/manage/rpki/faq/#why-must-i-create-a-key-pair-to-use-rpki
With Delegated RPKI you can take matters into your own hands:
https://rpki.readthedocs.io/en/latest/rpki/implementation-models.html#delegated-rpki
-Alex
Hi,
Removing a resource from the certificate to achieve the goal you describe will make the route announcement NotFound, which means it will be accepted. Evil RIR would have to replace an existing ROA with one that explicitly makes a route invalid, i.e. issue an AS0 ROA for specific member prefix. This seems like a pretty convoluted way to try and take a network offline.
I've seen worse…
Sander
There are in fact five anchors. I am not sure ARIN would be able to stop anyone holding RIPE space provided the resource holder uses RIPE RPKI anchor for publishing his ROAs.
Regards,
Baldur
As long Good RIR continues to publish a valid ROA for the real ASN that evil AS0 ROA would have no effect?
Regards,
Baldur
Correct.
Should this really be a concern, then you can run Delegated RPKI. In that case the RIR can’t tamper with your ROA because it’s not on their systems. Evil RIR could only revoke a prefix from your certificate or your entire certificate, but again, your BGP announcements would fall back to NotFound and would be accepted.
-Alex
This keeps coming up.
If a ROA disappears, RPKI state reverts to NotFound. Unless dropping
"NotFound" is now BCP, I think we'll be okay.
Mark.
Years ago, there was talk about giving it to the IANA.
Mark.
Anyhow I think some people think about RPKI in a way too binary manner
'because it is not secure, it is not useful'. Yes, AS_PATH
authenticity is an open problem, but this doesn't mean RPKI is
useless. Most of our BGP outages are not malicious, RPKI helps a lot
there and RPKI creates a higher quality database for prefix origin
information than what we have had.
essentially agree. my pedantic quibble is that i would like to
differentiate between the RPKI, which is a database, and ROV, which
uses it.
randy
And I think that is a very important distinction to be clear about.
Right now, it's not completely arrest-worthy to use RPKI and ROV
interchangeably, but I think considering that other use-cases might come
from the database itself in the future, being explicit about it and how
it can be used is appropriate pedantry.
Mark.