Re: LOAs for Cross Connects - Something like PeeringDB for XC

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

On Mon, Feb 22, 2021 at 2:06 PM Randy Bush <randy () psg com> wrote:
> > > way back, the rirs were very insistant that their use of rpki authority
> > > was most emphatically not to be considered an identity service.  this
> > > permeated the design; e.g., organization names were specifically
> > > forbidden in certificate CN, Subject Alternative Name, etc.
> >
> > yup, I agree... though the b2b stuff George/Geoff have written up LOOKS like
> > it could be useful for this LOA type discussion. The spaghetti draft appears
> > to also fill this niche...
> >
> > Neither are particularly rooted in the RPKI except that the CA certs are being
> > used as a method to attest that a 'thing' exists, and that something signed
> > that 'thing' as proof of knowledge (I guess, really). Effectively this is:
> >   1) I am 'ca-foo' in a tree that you can trust knows I am 'foo'.
> >   2) I signed this blob (LOA)
> >   3) I asked jane at bar.com to sign as well
> >   4) you can verify me (because rpki tree) and you can verify Jane because she's
> >       also using her RPKI ca cert.
> >
> > this may be a little cumbersome to sort through, especially if all parties here
> > aren't party to the RPKI (did equinix plumb the RPKI into their customer portal
> > and all of the things required to make a x-connect work in this manner?), but I
> > imagine that if this gets wings it could be automated and it could be reliable
> > and all parties (except the colo folks perhaps?) may already have incentives
> > in places to use their RPKI goop for this function.
>
> this would work only if the LOA is being sent to someone with whom my
> contract is signed with a key validating through the same hierarchy, or
> the credential was associated contractually.  i do not think equinix
> is up to this yet.

I agree that 'today' equinix (or the notional other Colo/etc folk) are
unlikely to be
able to make this work. In the future though, if the colo's customers are RPKI
users, and the colo has some (probably) relatively simple code in hand
they could
perform verifications of this sort.

I guess I didn't ask: "Do you want this to work 'now'? or is '2 to 5
yrs acceptable'?" :)

Of course any new thing must be better than the world-of-faxes we live in today
for this solution space, and it has to be adotable by the parties involved.

-chris