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

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

On Mon, Feb 22, 2021 at 2:44 PM Douglas Fischer
<fischerdouglas () gmail com> wrote:
> What if PeeringDB would be the CA for the Facilities?
> Supposedly this solves the CA problem of the "Colo Folks".

I think pushing your security identification out (as the notional
equinix) to a third party where you can't revoke/change/etc
is asking for dangerous things to happen.

The 'strength' of the RPKI (vs the web-pki) is that there are a
defined number of ways into the system.
You have ip space (IP Number Assets)? you get CA-cert and can create ROA.

there are surely a host of corner cases with 'use the rpki to sign not
INR things!!!', but at least:
  "Are you sure that's the right foo.bar? not f00.bar? or fOO.bar?"
  "yes, they have a CA cert signed by the RIR, with INRs they can
toggle ROA for.. if that CA cert signed the checklist then 'ok'"

again, that draft is a... draft still and I"m sure we'll have a bunch
of chatter/discussion/changes before done, but it smells like it might
help.

> Would PeeringDB be interested in that?
>
>
> Em seg., 22 de fev. de 2021 às 16:04, Christopher Morrow <morrowc.lists () gmail com> escreveu:
> > On Mon, Feb 22, 2021 at 1:39 PM Randy Bush <randy () psg com> wrote:
> > > > are you asking about something like this:
> > > >   https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/
> > > >
> > > > Which COULD be used to, as an AS holder:
> > > >   "sign something to be sent between you and the colo and your intended peer"
> > > >
> > > > that you could sign (with your rpki stuffs) and your peer could also
> > > > sign with their 'rpki stuffs', and which the colo provider could
> > > > automatically validate and action upon final signature(s) received.
> > >
> > > chris,
> > >
> > > 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.
> >
> > -chris
> >
> > > aside: of course a few rirs thought that *their* names should be in
> > > their certs as exeptions.  i remember the laughter.
> > >
> > > randy
> > >
> > > ---
> > > randy () psg com
> > > `gpg --locate-external-keys --auto-key-locate wkd randy () psg com`
> > > signatures are back, thanks to dmarc header mangling
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação