Steve, On 21/07/11 3:22 AM, "Stephen Kent" <[email protected]> wrote:
> Terry, > > The repository document mandates that each CA > issue a manifest and maintain it in an up-to-date > fashion; that's pretty clear. For example, 4.2.1 > says "If the authority alters any of the items > that it has published in the repository > publication point, then the authority MUST issue > a new manifest before the nextUpdate time." > Section 5.1 says "For a CA publication point in > the RPKI repository system, a CA MUST perform > the following steps to generate a manifest:" Yes, > I admit that it does not say that a CA MUST > generate a manifest, and here is how the CA MUST > do it, but I see that as a nit that could easily > be clarified during editing, unless the WG feels I think that would be fair, I'm happy for such an edit. > otherwise. Section 5.2 says "A new manifest MUST > be issued on or before the nextUpdate time." It > also says "An authority MUST issue a new manifest > in conjunction with the finalization of changes > made to objects in the publication point." Both > of these statements seem like pretty clear > direction to each CA to create a publish > manifests. I think it is sensible for us to be explicit in the creation of objects which drive the repository. > > Section 4.4. says "To determine whether a > manifest is valid, the RP MUST perform the > following checks in addition to those specified > in [ID.sidr-signed-object]." This seems like > pretty clear direction to an RP. Right.. and then is says " If the above procedure indicates that the manifest is invalid, then the manifest MUST be discarded and treated as though no manifest were present." Which then really needs a point to 6.2.. but that's a nit I don't really care about. > > Section 6 of the manifest document also says: " > Š, in the following sections, we describe a > sequence of tests that the RP SHOULD perform to > determine the manifest state of the given > publication point. We then discuss the risks > associated with using signed objects in the > publication point, given the manifest state; we > also provide suitable warning text that SHOULD be > placed in a user-accessible log file. It is the > responsibility of the RP to weigh these risks > against the risk of routing failure that could > occur if valid data is rejected, and to > implement a suitable local policy." I would prefer, given the identified case, that where a situation exists that a manifest is is non-existent or discarded that the entire publication point MUST be considered suspicious and not used for validation of operational objects. I would be fine if the GB object were still validated and used for human contact reasons with sufficient warnings about lack of trust. > > So the manifest document explains what an RP > SHOULD do with respect to using manifests. Later > subsections note that an RP SHOULD view as > "suspect" signed objects that appear at a > publication point when there is no manifest > available, but that does not mean that an RP > ought not retrieve and process those objects. So I'm fine for the RP to retrieve, fine for them to attempt to validate. but any use of those objects seems like a very slippery slope. I can foresee the potential for some transitive state existing where the RP fetches an incomplete repository, however I would still urge that the RP MUST not use an incomplete[1] repository and fall back onto their last known valid local cache [2]. [1] where the manifest is missing, or any objects listed in the manifest are missing. [2] since multiple SIA values are permitted it might make sense to suggest attempting to find a sane publication point from a replicated site (I'm not sure at this stage if serial/rtt semantics are needed in that) but I suspect such a function will be a necessity for entities "up the tree" who need to consider high availability and network visibility of the publication point. > in such cases, the file name extension is the > only top-level demuxing type indicator available In the absence of a manifest - "hint/indicator" I am comfortable with - anything more is a veritable stretch. > to an RP. The text also says that an RP can > (probably ought) to use signed objects that > validate but are not on a manifest, because this > probably indicates an error by the maintainer of > the pub point, to maintain sync between the > manifest and the pub point content. That seems inconsistent with the direction to a CA where Manifests must exist, and must list all files (and hash) at the publication point. I see this as a hard error, not a fuzzy one that can be left to an interpretation without any real supporting information to the RP. > > As for your example: I agree that if the content of a pub point in a > repository > is modified to remove the manifest for that pub > point (or it a MITM attacks achieves the same > effect), and if one or more ROAs for more > specific prefixes are removed, while leaving the > encompassing ROA, then RPs may reach the wrong > conclusion about the route authorization info > expressed by the prefix holder. This is not an > ideal situation. RPs have flexibility in dealing > with this sort of situation. For example, an RP > that had previously acquired all three ROAs, and > a matching manifest, might choose to stick with > that data, in light of the absence of a manifest > for the objects retrieved this time. It seems this falls into a comment expressed several times before by other wg members "don't leave the RP guessing". > > Manifests do two things well: if they are perfect > and the pub point perfectly matches what the > manifest says, an RP gets a very warm fuzzy They get more than that - they know that the repository is presented as intended and perfectly retrieved. > feeling. If a manifest is perfect, and a named > object is missing, or is present but the hash > does not match, an RP should be suspicious, e.g., I would prefer to see a "MUST" in that thinking. > contact the CA to see what's wrong (e.g., using > the GhostBusters record info). But, for most > (all?) of the other cases of a mismatch between a > manifest and pub point content, the manifest > can't tell the RP what is wrong. That to me suggests the relying party ends up in a state of "how was I supposed to know". In a security construct this seems non-optimal. May I suggest the following to the WG: Given that it's reasonable to expect that the CA MUST publish the manifest, and the manifest MUST contain all the object's file and hash at the publication point a RP MUST consider a publication point suspicious which has a anything other than a perfect manifest and set of matching files/hashes. The RP MAY use the remaining objects for debugging purposes only. This will solve and remove the issue I have identified. The _worst case_ is that the all the resources (ROAs) described at the suspicious publication point move to a state of "UNKNOWN". Which is far far better (and softer in potential routing decisions) in my opinion than erroneously classifying a route as INVALID. The plus side to this is it reduces the situations where a RP is left scratching their head in bewilderment. Cheers terry _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
