10. Router-Cache Setup
10. Router-Cache Setup
A cache has the public authentication data for each router it is configured to support.
A router may be configured to peer with a selection of caches, and a cache may be configured to support a selection of routers. Each must have the name of, and authentication data for, each peer. In addition, in a router, this list has a non-unique preference value for each server. This preference merely denotes proximity, not trust, preferred belief, et cetera. The client router attempts to establish a session with each potential serving cache in preference order and then starts to load data from the most preferred cache to which it can connect and authenticate. The router's list of caches has the following elements:
Preference: An unsigned integer denoting the router's preference to connect to that cache; the lower the value, the more preferred.
Name: The IP address or fully qualified domain name of the cache.
Cache Credential(s): Any credential (such as a public key) needed to authenticate the cache's identity to the router.
Router Credential(s): Any credential (such as a private key or certificate) needed to authenticate the router's identity to the cache.
Due to the distributed nature of the RPKI, caches simply cannot be rigorously synchronous. A client may hold data from multiple caches but MUST keep the data marked as to source, as later updates MUST affect the correct data.
Just as there may be more than one covering ROA from a single cache, there may be multiple covering ROAs from multiple caches. The results are as described in [RFC6811].
If data from multiple caches are held, implementations MUST NOT distinguish between data sources when performing validation of BGP announcements.
When a more-preferred cache becomes available, if resources allow, it would be prudent for the client to start fetching from that cache.
The client SHOULD attempt to maintain at least one set of data, regardless of whether it has chosen a different cache or established a new connection to the previous cache.
A client MAY drop the data from a particular cache when it is fully in sync with one or more other caches.
See Section 6 for details on what to do when the client is not able to refresh from a particular cache.
If a client loses connectivity to a cache it is using or otherwise decides to switch to a new cache, it SHOULD retain the data from the previous cache until it has a full set of data from one or more other caches. Note that this may already be true at the point of connection loss if the client has connections to more than one cache.