On 5/28/2012 9:42 PM, David Conrad wrote:
On May 28, 2012, at 1:59 PM, Paul Vixie wrote:
third, rsync's dependencies on routing (as in the RPKI+ROA case) are not circular (which i think was david conrad's point but i'll drag it to here.) Nope. My point was that anything that uses the Internet to fetch the data (including rsync) has a circular dependency on routing. It's just a question of timing.
when you say it's a question of timing, i agree, but then i think you won't agree again. in batch mode i can express a policy that's true from that moment forward until removed. in real time mode i have to be able to express a policy which is both valid and reachable at the moment of validation. that's a question of timing but the word "just" as in "just a question of timing" trivializes a galaxy-sized problem space.
ROVER expects that we will query for policy at the instant of need. Might want to review https://ripe64.ripe.net/presentations/57-ROVER_RIPE_Apr_2012.pdf, particularly the slide entitled "Avoid a Cyclic Dependency".
i read it. this is also what draft-gersch-grow-revdns-bpg says. this makes for a "fail open" design -- the only thing the system can reliably tell you is "reject". this precludes islands of, or a mode of, "fail closed". while i don't consider a mode of "fail closed" to be practically likely, i'd like to preserve the fig leaf of theoretical possibility. (and the more likely possibility that islands of "fail closed" could be sewn in.)
As far as I can tell, ROVER is simply Yet Another RPKI Access Method like rsync and bittorrent with its own positives and negatives.
i can tell more than that. rover is a system that only works at all when everything everywhere is working well, and when changes always come in perfect time-order, where that order is nowhere defined, and is in any event uncontrollable. rsync's punt of the ordering problem is batch mode with policy start times rather than policy valid instants. to my mind anyone who doesn't punt the ordering problem has to instead solve it. rover does neither. paul