deploying RPKI based Origin Validation

Thu Jul 26 19:09:16 UTC 2018

> On 19 Jul 2018, at 23:04, Mark Tinka <mark.tinka at seacom.mu> wrote:
> 
> 
> 
> On 19/Jul/18 21:47, Michel Py wrote:
> 
>> I understand that; if there is an easier way to do RPKI, people are going to use it instead of the right way. However, I think that the blacklist targets a different kind of customer : the end user. We want the enterprise to certify their prefixes with RPKI and put pressure on their upstreams to deploy it, the more noise we make the better. What I want is my upstreams to give me a clean routing tables without invalids, but it does not happen so in the meantime I'm trying to do what I can with my limited resources.
> 
> The script that Job wrote is neat, but I'm sure neither he nor I would
> run it in production in lieu of the actual RPKI infrastructure.
> 
> Even though you're my competitor, I'd caution against this. But, your
> network, your rules.
> 
> 
>> The picture from the enterprise is quite different. There is a lot of stuff out there that does not get upgraded, that is not even under a maintenance contract to get the new software, or that is on EOL/EOS hardware.
> 
> So don't re-invent this wheel; that is what Delegated RPKI is for.
> Several RPKI tools out there support CA functionality, as much as they
> support the RP side as well.

To add to the genetic diversity, NLnet Labs recently committed to building a full RPKI Toolset, including a (Delegated) Certificate Authority, a Publication Server and Relying Party software. As an RP implementation was the easiest way to get going, we now have some running code – in Rust – here:

https://github.com/NLnetLabs/routinator

Ou mission is to offer a toolset that on par with our other projects such as NSD and Unbound, in terms of quality, feature set and update frequency. We’re looking forward to your feedback; in the mean time we’re getting started with the CA and Publication Server. 

Cheers,

Alex