On Dec 19, 2012, at 1:13 PM, Randy Bush wrote: > o there is a useful poster child for the need for O(minutes) rpki (or > perhaps just roa) propagation. as folk have repeatedly said, we > need concrete examples and goals.
I really think these should feed requirements analysis too [1]. I think there are a few other easy examples of this type of use case, but for requirements, maybe we need just one good one? > o unfortunately, there is no internet technology today to completely, > accurately, and securely maintain a globally distributed database > (e.g. at every non-trivial pop) with time constraints on the order > of a minute. it's a research problem. and a *really* interesting > one. 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. Eric [1] http://www.ietf.org/mail-archive/web/sidr/current/msg03671.html _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
