At Sun, 12 Sep 2010 17:10:50 -0400, Steve Kent wrote: > > Are you saying that there is no deterministic solution that allows > an RP to detect that it has fetched an inconsistent set of > records.
Pretty much. A RP gets what it gets, then puts together the best picture of the world it can from what it was able to fetch. Some of what it was able to fetch may not validate. Figuring out whether validation failures were caused by a race condition, some RPKI analogue of what would be called a "lame server" in the DNS world, failing disk hardware on some server, a network partition, sunspots, or enemy action may be more trouble than it's worth. We got what we got, we validated what we could, and we'll try again later in any case. Here's the key question: what do you intend the RP to do differently based on this determination, why, and how much are you willing to pay (in protocol complexity, convergence time, etc) to achieve this? > That's what i would like to see. If the suggestion is to > check the manifest, I would be disappointed, as I think that makes > it hard to distinguish between attacks and sync problems. Indeed. I just doubt we're likely to do better. > Also, as I noted in my reply to Tim, that approach requires fairly > invasive processing, i.e., looking into a (verified?) manifest. As I think you know, my implementation of the validation process looks at the manifest every time anyway, so this doesn't bother me as much as it appears to bother you. > My suggestion avoids that concern, although perhaps at the cost of > an additional rsync activity. (I'm still interested in learning what > Chris's parameterized rsync call does.) If I understand correctly, Chris's suggestion solves a slightly different problem than the one I think we're having. He's talking about a way of avoiding local race conditions (eg, validator running in parallel with rsync, validator gets confused because it sees partially fetched data before rsync is done fetching); we're talking about remote race conditions. Avoiding local race conditions is relatively easy, Chris's suggestion is one way of doing it. Avoiding remote conditions ranges from hard to impossible for the kinds of protocols we've been talking about. I respect your quest for a synchronization tool to eliminate remote race conditions, I just don't think you're going to find one that will work in any sane fashion with off the shelf implementations of file-oriented protocols like rsync, http, and ftp, and I don't think anybody wants to push deployment back by several years while we go off to design a custom network protocol with the semantics you want. > I don't think we can go progress the repository doc without a better > description of the problem and recommended solution approaches. Agreed, so long as "this is the RP's problem, deal with it" is on the table as one of the solutions we might recommend. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
