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 -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
