Clarify relationship to RPKI

[nicorusti]

Add a couple of sentences to clarify relationship to RPKI

Date: Tue, 6 Aug 2024 23:44:57 +0000 From: Michael McBride michael.mcbride@futurewei.com To: rfc-ise@rfc-editor.org rfc-ise@rfc-editor.org CC: 'Mike McBride' mmcbride7@gmail.comF. How else can the document be improved?

I’m a believer. It’s a good set of solutions. Using a PKI is a good solution. As is the current RPKI and ROA’s. It might also be helpful, in the scion control plan pki document, to at least acknowledge RPKI. RPKI is widely used now and it could be helpful to understand how scions use of PKI would be similar and different. In the long run it would give operators a more comfortable understanding since most now use RPKI.
We could add a couple of sentences about this. We have some text in the now expired draft-rustignoli-panrg-scion-components:

We have some text in the now expired draft-rustignoli-panrg-scion-components:

   The above-mentioned decoupling also implies that SCION does not
   provide, by design, IP prefix origin validation, which is currently
   provided by RPKI [RFC8210].  As prefix origin validation is outside
   of SCION's scope, IP-to-SCION's coexistence mechanisms (SIAM, SBAS)
   later discussed in Section 3.1 build on top of RPKI for IP origin
   attestation.
   ... 
   These properties would be lost if SCION were to rely on an existing
   PKI (i.e., the web PKI, the RPKI, ...).  For example, if SCION were
   to use the RPKI instead of the CP-PKI, its control plane would lack
   the trust model required to support Isolation Domains.  This is
   because RPKI's trust model follows the same structure as the IP
   allocation hierarchy, where the five RIRs represent the trust roots.

[knmeynell]

Added reference to why RPKI isn't directly supported by SCION. Did not mention SIAM or SBAS as this appears to be experimental and would need to be further explained somewhere.