On Wed, Dec 11, 2019 at 11:35 AM Matt Corallo <nanog@as397444.net> wrote:
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.
I don't think that's what I was saying, at all, actually. I was saying: "I assume you must have some system to create IRR data, that system knows: '1.0.1.0/24 ASFOO MAINT-FOOBAR' is ok." that system could now add '1.0.1.0/24 ASFOO' to the RPKI. Where does that say: "make it sign unauthenticated data" ?
On Dec 11, 2019, at 10:17, 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?
-chris