Starting to Drop Invalids for Customers

Wed Dec 11 16:35:20 UTC 2019

Right, but you’re also taking a strong, cryptographically-authenticated system and making it sign non-authenticated data. Please don’t do that. If you want to add the data to RPKI, there should be a way to add the data to RPKI, not sign away control of your number resources to unauthenticated sources.

> On Dec 11, 2019, at 10:17, 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?
> 
> -chris