> I feel _this_ is where a lot of our group's false-logic starts. This > (and similar) statement(s) assume that we must deploy a global > replicated state machine, which has a complete and coherent image of a > globally distributed set of resource holders' states, at all RPs at > all times in order for validation to succeed. Moreover, the state of > this global replicated state machine has no semantic for data > authorities to inform or influence the coherence of replicated data > held by RPs (in caches, etc). It is true that this model is mandated > by the current _design_, but I don't see that this is motivated by any > real engineering _requirement_. Why do we need to crawl all repos, > for all resource holders in order to route? What motivates _this_ as > the only way to accomplish routing security? > > In the spirit of sound engineering: since this aspect of BGPSEC is not > derived from a requirement, and it is limiting us from reaching other > required goals (see above), it ought to be reconsidered/thrown out. > afaik, RPKI+BGPSEC (note the BGPSEC part, not just RPKI) is something > of an outlier in the field of Internet-scale systems, in that it > requires everyone to have this full globally consistent cryptographic > state maintained reliably at all RPs. I point this out just to > underscore the notion that we should all be circumspect in our > optimistic appraisals of this design's operational viability. > > I feel this design element needs to be challenged, and if it cannot be > supported by requirement it should be removed from the design.
bgpsec+rpki does not have the highly globally synced requirement. your application does. you are tryin to add the requirement. i agree with you that it should not be added. thanks for understanding. randy _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
