[db-wg] ROA and for x.509 certificate (RDAP record)

Dear Hank,

On Tue, Apr 12, 2022 at 06:23:45PM +0300, Hank Nussbacher via db-wg wrote:
> Why isn't creating an ROA proof enough that I control the address range?

The extra step is needed because the ROA could also have been created by
another entity attempting to BYOIP some space into a provider!

Imagine there being two separate accounts (unrelated to each other),
each instructs the cloud provider "10.0.0.0/24 is my prefix, can you
originate it on my behalf, I create a ROA". The cloud provider has to
figure out which of the two accounts is truthful, and which is
attempting to trick the cloud provider into announcing that space and
routing it to the fraudulent account holder's virtual resources.

> Why 2 forms of authentication needed (ROA & X.509)?  What will happen to the
> pollution of the descr tag if others like Azure and GCP decide on something
> similar?

I'm not concerned about pollution, but indeed it doesn't look super
pretty.

> Should the community form a standard rather than let the descr field
> become polluted?

I have good news! Work already is in progress to help with challenges
like the above one! :-)

A concept known as "RSC" (Resource Signed Checklists) might be useful to
restructure cloud onboarding procedures for BYOIP. 

1) request the IP holder to create a ROA. This way the cloud provider
knows they are authorized to originate space.
2) tell the IP holder a secret random string
3) request the IP holder to create a RSC (this probably would happen via
the RIR RPKI dashboard) in which the IP space and the random string are
bound to each other. 
4) the RSC is uploaded/emailed to the cloud provider, who can verify
the signature. This way the cloud provider knows that whoever tried to
initatie the BOYIP process, also has access to a keypair capable of
making attestations.

RSC objects are *not* distributed through the global RPKI repository
system, this is neat because this way the RSC concept does not impose a
burden.

The Internet-Draft is heading towards IETF "Working Group Last Call"
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rsc

Kind regards,

Job