Hi Andrew,
On 22/07/11 5:00 AM, "Andrew Chi" <a...@bbn.com> wrote: > On 7/20/2011 11:24 PM, Terry Manderson wrote: >> The problem is Randy, that this PKI requires full and complete distribution >> through a sane repository system. Failure to have a full and complete >> repository WILL lead to unintended (ie bad) results. > I left off a few words that might clarify the position. "Failure to have a full and complete repository" should have been "Failure to have a full and complete repository at that publication point" Given the distributed nature of the repository there will be times that some publication points are not available. > I agree that relying parties (RPs) need eventual access to the full > repository system, and it's true that repositories (not just filenames) > are considered unprotected structures. agree. > > But IMO this is why we have RP software that: > (1) caches valid objects from previous downloads, Which is good. > (2) validates through the certificate chain, and good there too. > (3) does *not* simply blacklist an entire subtree when a single manifest > disappears (or more generally, when other parent objects are > inaccessible through the repo system). This is where I disagree. Doing this takes the existing routing system with the default assessment of "unknown" and asserts a statement of "INVALID" in the case that I provided. This is badness and I think is the wrong action to take and against the original mandate of SIDR of 'make before break'. So you must set the publication point aside as you can't verify the consistency of the publication point unless you have a complete manifest and set of files, if you then pass that to the routing side as a 'best fit' the RP is simply guessing on what the intended outcomes should be. You may use a previously sane and known repository point which still validates. I am fine for RPs to do tweaks on the information once they receive it on the routing side (specifically how they implement VALID, INVALID, and UNKNOWN) but the outputs from the RPKI validation of a publication point should be perfectly predicable in all situations of repository dropouts and intermittent corruptions. > > With RP software that does those things, intermittent repository > dropouts and even intermittent corrupted repositories are okay. > Not when they result in routes being marked as INVALID from such events. > What am I missing? My suggestion to fix this through the manifest is probably only one solution. If you have an alternative fix, which takes the burden and guesswork away from the RP, I would be happy to hear it. Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
