On Wed, May 5, 2021 at 10:38 AM Randy Bush <randy@xxxxxxx> wrote:
> Pivoting for a second, are you intending to support the case in which
> a provider has adopted RPKI but has no intention of signing these
> files?
unfortunately, this will be common for a while. methods for signing
with keys from the rpki are baroque at the moment, with two documents
draft-ietf-sidrops-rpki-rta-00
draft-spaghetti-sidrops-rpki-rsc-03
proposing means.
Noted.
> If so, then web PKI integrity (i.e., being able to trust that the data
> at the https geofeed URL is controlled by the same entity that
> controls the routing data) is still required to prevent forgery.
the draft does require tls for the temporary remarks: based url. it
will be fixed to do so for the geofeed: url.
the web pki is not associated with ip address space control/ownership.
web pki is based on control of domain name space. the two are quite
unrelated.
I still don't understand how this is relevant. I'm not asserting otherwise, and never have been. Let me try again: what are you suggesting would be basing its trust of geofeed IP ranges on the web PKI? Aren't the valid ranges for an AS specified in the RPKI-protected routing data feed (where RPKI is available)?
Kyle
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
