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

[Job Snijders]

On Thu, Nov 12, 2020 at 11:37:24AM -0500, Chris Morrow wrote:
> > 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 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.

... which is what NLnet Labs might be doing at a future point in time.

> Using the VRP/RPKI data to trim implausible route data from IRR seems safe.

Agreed, I led multiple initiatives to use *Validated* ROA Payloads to
clean up stale/conflicting IRR data. The RIPE-713 project was one
implementation of this idea https://www.ripe.net/publications/docs/ripe-731,
and IRRd v4.1.0 has a mode like this as well https://irrd.readthedocs.io/en/stable/admins/rpki.html
But this is not what rtrtr is doing or is going to do from the looks of
it!

In RTRTR the only 'export' interface into the decision making end (the
BGP router) in RTRTR is the RTR protocol. NLNetlabs is setting the stage
to take 'low quality data' and upsample it through the RTR interface
into something it is not.

It seems future version of RTRTR will be able to take not-validated-data
(like IRR), and convert that into the RTR (stands for RPKI-To-Router)
protocol, which on the receiving EBGP router side is interpreted as
validated ROA payload data to be used in the RFC 6811 process. RTRTR is
not an "prefix list cleanup tool" (like ripe-731 or irrd 4.1.0 are).
Seems to me they are setting the stage to somewhat dillute the current
interfaces in the ecosystem. 

RTR is not a general purpose 'provisioning' protocol, the current UI on
COTS routers does not allow it to be used for different data sources of
different quality levels.

Kind regards,

Job