On Wed, Aug 04, 2010 at 03:41:17PM -0400, Rob Austein wrote: > > 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. > > What RPSEC did or did not say is not my problem, but I agree that an > operator has policy settings somewhere. At present, they're mostly in > the router itself, thanks to Doctor Knob; the only policy setting in > the RPKI part of the picture at the moment is choice of trust anchor, > which is a basic configuration issue for the validator and something > we almost certainly do not want to extrude into the rpki-rtr protocol.
I think you have chosen to take the word policy and apply it in the route filtering sense rather than my intended RPKI sense. Please insert whatever word you want to use that directs my use of which objects from the RPKI I choose to be permitted for validation purposes. The simplest example of this would be "I choose not to trust Foo-NIC as a trust anchor". Another example would be "I choose to ignore AS64512's objects". My intention was never "drop 10/8 le 24 from BGP" in the style of RPSL. > I will note that, of your two options, ignoring your injection of > policy into the protocol, the first one (co-location of RPKi validator > with rpki-rtr server) is the one we envisioned, although one can > imagine more complex topologies where validators fetch from > pre-aggregated caches generated by other validators, to reduce > external load and promote a weak form of coherence. Note that in a > complex topology the object timestamps will tend to do what you want > automatically, given that we're using rsync as the RPKi data gathering > tool. Also note that all of the fancy topology stuff would happen in > front of RPKI validation, by the time one has gotten past that it's > just the rpki-rtr protocol feeding results to the routers. Let's stick with this example since it's sufficient for my point as long as we're talking about a set of caches in a single domain/AS/administrative region/etc. and have consistent configuration. Ignoring rpki-rtr, there should be a mechanism to determine whether all of the local caches within the domain are consistent with each other. Pathologically, this is each cache rsync'ing with every other cache and finding no changes. More realistically, it'd be agreement that all objects of a certain age are present on all caches. Passing that age into the rpki-rtr protocol is sufficient to establish a measure of confidence in the consistency of caches in the same domain for differing sessions. -- Jeff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
