Re: [sidr] looking at repository withholding attacks.

[Stephen Kent <[e-mail]>]

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