deploying RPKI based Origin Validation

Fri Jul 13 12:43:11 UTC 2018

On Fri, Jul 13, 2018 at 02:37:32PM +0200, Mark Tinka wrote:
> 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.

Have you considered applying "invalid == reject" on just transit/peering
sessions rather than customer sessions as an intermediate step? I bet
most misconfigurations or hijacks didn't come in via your customers.

> 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...

Cool!

Kind regards,

Job