On Wed, 20 Jul 2011, Stephen Kent 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.
There's also the following text:
2.1. Manifests
Every repository publication point MUST contain a manifest
--Sandy, speaking only as a personal observation
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
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.
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.
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."
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 in such cases, the file name extension is the only
top-level demuxing type indicator available 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.
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.
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 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., 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.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
