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