deploying RPKI based Origin Validation
mark.tinka at seacom.mu
Fri Jul 13 12:37:32 UTC 2018
On 12/Jul/18 19:50, Job Snijders wrote:
> Anyone here working to deploy RPKI based Origin Validation in their
> network and reject invalid announcements? Anything of note to share?
It's great to hear that this is catching up. To be honest, I haven't
kept up with the latest goings-on in this space for almost 1 year now,
so I hadn't heard about anyone implementing OV in an "Invalid = Drop"
Between 2014 - 2016, we (SEACOM, AS37100) deployed and operated (what
was then rpki.net) Dragon Research's RPKI CA and RP tools. I believe the
project has since moved over to GitHub:
Anyway, the operational issue we ran into was due to our aggressive
policy to drop Invalids. The reason this became an issue was networks
that ROA'd just their aggregates, but either forgot to or decided not to
ROA the longer prefixes that were children of the aggregate.
So suddenly, you have a customer who is multi-homed; one connection was
to us, SEACOM, and the other was to another ISP not doing OV. Our policy
meant the customer was receiving far fewer routes from SEACOM vs. the
other provider, which took traffic away from us (and consequently, $$);
not to mention the NOC-related headache.
After 2 years of struggling to get community traction with OV based on
this policy, we decided to maintain the validation, but remove any
actions being ran against the validation result.
OV where Invalids are dropped is something that all (major, and some
regional, at the very least) ISP's need to enable for it to make a real
difference in terms of:
* Encouraging all networks to participate, and
* Reaching the desired outcome, i.e., to mitigate against route leaks
We also discovered a number of bugs that myself, Randy, Rob, Philip,
Fakrul, Matthias, Jay and Andreas, and a few others at Cisco and Juniper
helped fix in code that shipped between 2016 - 2017.
I would really be keen to hear feedback from you or others that have
decided to deploy OV and drop Invalids. I'm more than happy to get back
on to this wagon in the interest of cleaning up the global BGP table.
But it needs mass...
More information about the NANOG