On Wed, Aug 04, 2010 at 02:06:53PM -0400, Rob Austein wrote: > At Wed, 4 Aug 2010 17:44:24 +0000, Jeffrey Haas wrote: > > > > My concern is that if a cache is out of step with the policy server > > that is used to populate that cache. > > This description makes no sense in the context of the current protocol > and implementations. You've introduced an independent element between > the RPKI and the rpki-router protocol server (your "policy server"), > then postulated a failure of that element. How you handle failures in > elements you introduce would be between you and your rabbi. :)
Let me attempt to correct my incorrect verbiage. It's been a while since I've read the -arch document. -arch notes that a provider must maintain a Local Cache. The Local Cache may contain configuration - policy - that directs things like which TAs to use. After processing the RPKI objects, the output is effectively a database of prefixes (and max-lengths) and their origin ASes. A provider may wish to override validated RPKI data for their own purposes. While not explicitly a SIDR-driven requirement, this was discussed multiple times as a requirement during the original RPSEC work. The resulting output (override or no), is a set of AS:prefix/maxlen tuples that reflects the provider's routing policy with regard to origin validation. This policy must now be distributed to routers for implementation. The mechanism for distributing the policy is currently draft-ymbk-rpki-rtr-protocol. Implementation/Deployment models: 1. The Local Cache with resulting routing origin policy and the rpki-router protocol server are in the same box. In this model, the provider will likely have to deploy more than a single instance of this model throughout their network. This will result in each box hitting the RPKI repositories in order to keep their state fresh. Presuming the lack of a mechanism to keep each box in lock-step with their state, this provides a scenario where these servers may become out of synch with each other. This may yield inconsistent routing origin policy within a given network. 2. The Local Cache with resulting routing origin policy is implemented within one box. The rpki-router protocol servers are located in multiple boxes. In this model, the single Local Cache minimizes the impact on the global RPKI repository infrastructure. A mechanism is required to distribute the resulting origin routing policy to the rpki-router servers (let's call it scp for simplicity's sake). The only way for this infrastructure to provide inconsistent routing origin policy within the network would be for the Local Cache to be topologically isolated from the rpki-router servers. This is a detectable condition at the Local Cache presuming a push model where it is noted that the push fails. In both models there is a possibility that the rpki-router server session is up but the server session is out of sync with the RPKI within a given network. This yields inconsistent policy which is usually considered a Bad Thing. If you don't have this perspective, you must be talking to different providers than I am. I believe it is possible to minimally update the rpki-router protocol to allow routers to detect policy skew. -- Jeff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
