[RPKI-Deployers] New RPKI tool from NLnet Labs: RTRTR

[Chris Morrow]

On Thu, Nov 12, 2020 at 11:30 AM Job Snijders <job at ntt.net> wrote:
>
> On Thu, Nov 12, 2020 at 10:27:53AM -0500, Chris Morrow wrote:
> > On Thu, Nov 12, 2020 at 7:54 AM Job Snijders <job at ntt.net> wrote:
> > > We've been using GoRTR for this type of functionality for some time now
> > > Though, I think using HTTPS to fanout from validator to RTR servers is
> > > simpler and more robust than using RTR as origin fetching mechanism. :-)
> > >
> > > Where they mention "IRR data" worries me a bit, as it absolutely is not
> > > wise to use IRR data as input to the RFC 6811 Origin Validation process.
> > > The semantic meaning of IRR objects is different than RPKI ROAs, making
> > > such objects unsuitable to pump into an 'RPKI-To-Router' application.
> >
> > it sounded, to me, like one goal of this new tool was to digest 'a
> > bunch of data sources' and build route filters to put in your config.
>
> yeah, phrased differently: i am worried this tool makes it too easy to
> load network-outage-causing data into your border routers.
>
> The idea of "using IRR data as if it is VRP data" should under not
> be popularized, it is the opposite of a best current practise.

I would agree that it's pretty hard to get reasonable VRP from just IRR data.
You CAN, however, get a reasonable first-pass for route-filtering /
customer-cone from IRR (it's ugly, but it does kinda work out with
some care)
you can ALSO (if you track the right parts) say:

  "I see these prefixes from these asn(via irr), that prefix would
never be valid from any of
   these asn (because rpki says so) so i can exclude this prefix from the list"

Directly making irr data into VRP sounds bad, yes.
Using the VRP/RPKI data to trim implausible route data from IRR seems safe.