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. Let's not create something totally out of
scope to mimic specs and tools already exist.
If you really want to participate in the RPKI, then you seriously need
to consider supporting software that implements it. If not, use your
ISP's CA tools to sign your IP addresses, and then rely on them to have
clean FIB's when you use them for transit.
RPSL got complicated enough with all its good intentions, and we know
how that turned out. Let's not muddy the RPKI waters.
Mark.
