Starting to Drop Invalids for Customers

Wed Dec 11 16:51:55 UTC 2019

On Wed, Dec 11, 2019 at 12:16 PM Christopher Morrow <morrowc.lists at gmail.com>
wrote:

> On Wed, Dec 11, 2019 at 5:52 AM Rubens Kuhl <rubensk at gmail.com> wrote:
> >
> >
> >>
> >> > Which brings me to my favorite possible RPKI-IRR integration: a ROA
> that says that IRR objects on IRR source x with maintainer Y are
> authoritative for a given number resource. Kinda like SPF for BGP.
> >> >
> >>
> >> Is this required? or a crutch for use until a network can publish all
> >> of their routing data in the RPKI?
> >>
> >
> > It provides an adoption path based on the information already published
> in IRRs by operators for some years. It also covers for the fact that RPKI
> currently is only origin-validation.
>
> I would think that if you(royal you) already are publishing:
>   "these are the routes i'm going to originate (and here are my customer
> lists)"
>
> and you (royal you) are accepting the effort to publish 1 'new' thing
> in the RPKI.
>
> you could just as easily take the 'stuff I'm going to publish in IRR'
> and 'also publish in RPKI'.
> Right? So adoption path aside, because that seems like a weird
> argument (since your automation to make IRR data appear can ALSO just
> send rpki updates), your belief is that: "Hey, this irr object is
> really, really me" is still useful/required/necessary/interesting?
>
>
The history of development of BGP path-validation standards does not give
much hope so far... people never seen to be able to agree on how to do it.
OTOH, people seem comfortable publishing those relations in IRR... and some
using that for prefix-filter building, including AS 15169 that presented
yesterday on an IX conference and said preferring using IRR over RPKI to
automate prefix filtering.

Frankly, I'll take any form of authenticated path-validation that gets
traction in the DFZ, whether it's pretty or not. Pure RPKI for both origin
and path validation looks much better to me, but will it fly ?

Rubens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20191211/5e1b5db2/attachment.html>