Re: Starting to Drop Invalids for Customers

[Christopher Morrow <morrowc.lists () gmail com>]

On Wed, Dec 11, 2019 at 11:52 AM Rubens Kuhl <rubensk () gmail com> wrote:
> On Wed, Dec 11, 2019 at 12:16 PM Christopher Morrow <morrowc.lists () gmail com> wrote:
> > On Wed, Dec 11, 2019 at 5:52 AM Rubens Kuhl <rubensk () 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.

I think path-validation is .. BGPSec - rfc8206
right? so clearly some folks agreed on the process/path/etc for
validating paths in bgp.
Will that get deployed? unclear to me... To get it deployed though
we'd need to start at the beginning of the story and get RPKI data
published.

> 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.

oh, someone presented yesterday, cool...  err... I think their
presentation says (or should have said?) something like:
  "today we plan to use IRR data, we'll be adding RPKI data as it's
available and we're comfy with the integration efforts..."
   (that's what this preso said anyway:
     https://docs.google.com/presentation/d/1-SIa98o-QrMALW3maAvu_W_PHTJRAr0Nv-kO1-gNcs8/edit?usp=sharing
  when i presented it 2x)

 I think that's still the project plan...

> 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 ?

<insert will it blend meme>

I think the RPKI adoption and usage in the DFZ and near-to-dfz is
picking up (says the graphs, etc).
I'd love to see it more picked up, but folk don't REALLY have a need
for it 'yet', once more large players start publishing and requiring
though :)
the goal of the slide deck above, and job's efforts and mark's efforts
and jay/nimrod's efforts (and cloudflare/maaaaahtin/jerome/etc .. plus
a host of others) is to make it apparent: "Hey, get your data
straight, publish in RPKI, start validating!"

-chris

> Rubens