[arin-ppml] implementing RPKI prefix validation actually increases risk

[Michel Py]

Hi Bill,

> William Herrin wrote :
> I believe you can set up an in-house trust anchor and use it to sign the routes you distribute
> internally. Then your routers would consider the RBL routes to be RPKI valid.

Indeed, as David mentioned. However, this directly leads to blanketing the entire address space as RPKI valid on the validator, which may have unforeseen effects. There is going to be someone to say that would be abusing SLURM.

> But wouldn't this be a more appropriate discussion for an operations mailing list like NANOG or a Cisco-specific
> mailing list? There's not really anything ARIN can do about how Cisco implements RPKI.

I don't think that this is specific to Cisco, just happens to be the implementation I use. And the point I was trying to make was about why protocols are not being adopted. I have some concern that RPKI may eventually die from a thousand cuts; none of the issues are fatal, but the accumulation of them sure is annoying. Beyond the technical or operational details, making a new protocol easy to adopt is something I consider related to policy. What I am saying here is : RPKI validation is not easy to adopt.


Hi Job,

> Job Snijders wrote :
> It sounds to me that you configured your devices to apply RPKI-ROV and reject RPKI-invalid routes coming in via the
> blackhole BGP sessions, and now are surprised that RPKI-invalid routes are rejected on the blackhole BGP sessions.

The issue is not that the invalid routes are rejected, the issue is that there is no way to make them become the best path. I understand that this is the very purpose of RPKI : make the valid prefix the best choice over an invalid one. However, the other side of that coin is that I think the decision to make _any_ prefix the best path should be mine if I give it enough "weight", and my problem is that RPKI does not provide an override mechanism. Back to the perception issue : it takes away control.

> You could configure your devices to not do RPKI-ROV on the blackhole BGP sessions (essentially granting the
> blackhole BGP server unfiltered access into your network), and continue to do RPKI-ROV on all other EBGP
> sessions (transit, peering, private peering, customer facing).

I'm not following you here; RPKI-ROV is not configured on a per-peer or a per-session basis, what am I missing here ?
As mentioned earlier, a different route-map for different purposes has no effect on the best path decision. No matter what the situation, a valid RPKI prefix will always become the best path, which leads directly to blanketing the entire address space as valid at the RTR level to resolve.

Michel