Re: deploying RPKI based Origin Validation

[Alex Band <alex () nlnetlabs nl>]

> On 19 Jul 2018, at 23:04, Mark Tinka <mark.tinka () 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