To relieve routers of the load of performing certificate validation,
cryptographic operations, etc., the RPKI-Router protocol, [RFC6810],
does not provide object-based security to the router. I.e. the
router may not validate the data cryptographically from a well-known
trust anchor. The router trusts the cache to provide correct data
and relies on transport based security for the data received from the
cache. Therefore the authenticity and integrity of the data from the
cache should be well protected, see Section 7 of [RFC6810].
[WEG] fine, though it's unclear if "may" in the above is intended to
be normative. I think it's not, but just pointing it out.
actually, it was a grammar error which i caught right after posting. in
my edit buffer, it is 'can' as in ablility not 'may' as in permission.
As RPKI-based origin validation relies on the availability of RPKI
data, operators SHOULD locate RPKI caches close to routers that
require these data and services in order to minimize the impact of
likely failures in local routing, intermediate devices, long
circuits, etc. One also should consider trust boundaries, routing
bootstrap reachability, etc. E.g. a router should bootstrap from a
chache which is reachable with minimal reliance on other
infrastructure such as DNS or routing protocols.
[WEG] this is better, but I still maintain that in the first sentence,
"close" isn't actually the goal we're trying for.
for some definitions of 'we' :)
How about:
...operators SHOULD consider the relationship between the routers that
require these data and services and the location of the RPKI caches in
the network's topology. Caches SHOULD be located so that they can take
advantage of geographic redundancy and minimize the impact of likely
failures in local routing, ....
i don't even know what geographic redundancy is, alternate earths? if
you mean redundant network topology, i think it is more than that. i
really think physical line length matters. as i said, the longer the
circuit the more likely a boat anchor will whack it. hence close.
And add this at the end to explain why reliance on routing protocols @
bootstrap is risky:
...or routing protocols. Reliance on routing protocol convergence to
reach a cache at bootstrap time can result in significant increases in
total convergence time as the router converges partially, synchronizes
with the RPKI cache, and then must re-converge based on the data from
the cache.
i think i understand what you want made more explicit. today's try
To relieve routers of the load of performing certificate validation,
cryptographic operations, etc., the RPKI-Router protocol, [RFC6810],
does not provide object-based security to the router. I.e. the
router can not validate the data cryptographically from a well-known
trust anchor. The router trusts the cache to provide correct data
and relies on transport based security for the data received from the
cache. Therefore the authenticity and integrity of the data from the
cache should be well protected, see Section 7 of [RFC6810].
As RPKI-based origin validation relies on the availability of RPKI
data, operators SHOULD locate RPKI caches close to routers that
require these data and services in order to minimize the impact of
likely failures in local routing, intermediate devices, long
circuits, etc. One should also consider trust boundaries, routing
bootstrap reachability, etc. E.g. a router should bootstrap from a
chache which is reachable with minimal reliance on other
infrastructure such as DNS or routing protocols.
For example, if a router needs its BGP and/or IGP to converge for the
router to reach a cache, once a cache is reachable, the router will
then have to reevaluate prefixes already learned via BGP. Such
configurations should be avoided if possible.
randy