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
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
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
