On Mon, Apr 20, 2020, at 21:54, Amir Herzberg wrote: > 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
