Subject: [sidr] looking at repository withholding attacks.

From: Terry Manderson <[email-masked]>
Date: Tue, 19 Jul 2011 22:44:24 -0700

All,

So it seems that the RPKI repository as it stands has the notion of a
mandatory entry in the resource certificate pointing to a manifest.

The existence of the manifest is intended, but doesn't seem to be mandated,
that is the absence of a manifest is left to the relying party make a
decision on the use of the objects remaining at the publication point
(Section 6.2: all objects SHOULD be considered suspect but may be used).

So thinking about this further, and using the example from sidr-usecases.
'5.2.  Only Some Children Participate in RPKI'

The resulting ROAs issued are:

      Org A.
      +----------------------------------------------+
      | asID     | address           | maxLength     |
      +----------------------------------------------+
      | 64496    | 10.1.0.0/16       |    20         |
      +----------------------------------------------+

      Org A issues for Org B.
      +----------------------------------------------+
      | asID     | address           | maxLength     |
      +----------------------------------------------+
      | 64511    | 10.1.16.0/20      |    20         |
      +----------------------------------------------+

      Org C.
      +----------------------------------------------+
      | asID     | address           | maxLength     |
      +----------------------------------------------+
      | 65535    | 10.1.32.0/20      |    20         |
      +----------------------------------------------+

I think it's sane to assume that the Org A RPKI objects are placed on the
same repository server at the same publication point.

Lets pretend that either the repository is compromised or a MiTM event
occurs which removes the existence of the manifest at the publication point
and the ROA issued by org A for org B (the second one):

      Org A issues for Org B.
      +----------------------------------------------+
      | asID     | address           | maxLength     |
      +----------------------------------------------+
      | 64511    | 10.1.16.0/20      |    20         |
      +----------------------------------------------+

As I read the existing drafts, a relying party MAY still use the other
objects. Further my reading suggests that the route corresponding to this
object will then be considered invalid (roa-validation and pfx-validate)
meaning that this is a targeted DoS attack on Org B which will succeed for
all relying parties affected. Eg resulting in BGP_PFXV_STATE_INVALID.

Am I correct in this interpretation, and if not. why? What have I missed?

Why is this not a potential attack on org B? Considering also that there are
quite a number of real world 'sub-suballocated' (provider assigned if you
like) prefix originations. (See
http://stats.research.icann.org/bgp/cidr-map/origin-map.bgp.20110605.1800.ht
ml, please excuse the currency of the data, I had a cron issue and I just
noticed it)

I concede that this is an unintended state, but I find the possibility of
this being played out somewhat concerning as it seems possible to still use
remaining objects from a very suspicious repository point. I'm actually
hoping that I have misinterpreted something and such an attack is not
possible.

Cheers
Terry

---

From: Stephen Kent <[email-masked]>
Date: Wed, 20 Jul 2011 13:22:36 -0400

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

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 20 Jul 2011 13:34:53 -0400 (Eastern Daylight Time)

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

---

From: Terry Manderson <[email-masked]>
Date: Wed, 20 Jul 2011 19:31:36 -0700

Steve,

> be clarified during editing, unless the WG feels

I think that would be fair, I'm happy for such an edit.

> direction to each CA to create a publish

I think it is sensible for us to be explicit in the creation of objects
which drive the repository.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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".

> 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.

> does not match, an RP should be suspicious, e.g.,

I would prefer to see a "MUST" in that thinking.

> 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

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Jul 2011 19:42:39 -0700

> 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.

off the bloody wall.  the trust is gained through the cert chain.

randy

---

From: Terry Manderson <[email-masked]>
Date: Wed, 20 Jul 2011 19:53:28 -0700

> off the bloody wall.  the trust is gained through the cert chain.

very well, "if the GB still validates through the cert chain."

Provided of course that you have a valid GB object since without a manifest
a simple `cp 00001.gbr 00001.cer` will fail to validate under the assumption
you make the validation selection regime based on filename extension.

Terry

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Jul 2011 20:00:49 -0700

> Provided of course that you have a valid GB object since without a
> manifest a simple `cp 00001.gbr 00001.cer` will fail to validate under
> the assumption you make the validation selection regime based on
> filename extension

this is so far off into the weeds as to be picturesquely stunning.

let me try with more words.  the rpki is an x.509 based pki.  it is the
certs and validation chain(s) which rule.  if a roa, gbr, ee cert,
... validates to a ta, it is good.  period, end.  finished.

the purpose of the manifest is to try and reduce one known attack on
this type of pki, removal of an object.  end.  period.  fin.

randy

---

From: Terry Manderson <[email-masked]>
Date: Wed, 20 Jul 2011 20:24:51 -0700

>> manifest a simple `cp 00001.gbr 00001.cer` will fail to validate under

oops that should have been `mv 00001.gbr 00001.cer`.

> this is so far off into the weeds as to be picturesquely stunning.

no its not.. Rob has said:

" Attempt validation based on the filename type; if that
fails, the object is toast regardless of whether the filename appears
in the manifest or not. "

That means if I rename an object it will not validate. (irrespective of
being in the manifest or not)

so really, 'rm *mft; for for foobar in * ; do mv $foobar $foobar.gbr ; done'

will wipe out the entire repository and nothing will validate, except the
valid GB record..

Did I interpret Rob incorrectly?

So similarly 'for for foobar in * ; do mv $foobar hahha$foobar ; done'
will mean that the manifest will mismatch, but provides a very clear signal
if we use the MUST word to the RP such that the RP will set aside the entire
publication point and start the human interaction process with a no harm/no
foul result.

> this type of pki, removal of an object.  end.  period.  fin.

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. So its not just the PKI
alone.

Terry

---

From: Andrew Chi <[email-masked]>
Date: Thu, 21 Jul 2011 15:00:03 -0400

On 7/20/2011 11:24 PM, Terry Manderson wrote:
> repository WILL lead to unintended (ie bad) results.

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.

But IMO this is why we have RP software that:
(1) caches valid objects from previous downloads,
(2) validates through the certificate chain, and
(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).

With RP software that does those things, intermittent repository 
dropouts and even intermittent corrupted repositories are okay.

What am I missing?

-Andrew

---

From: Terry Manderson <[email-masked]>
Date: Thu, 21 Jul 2011 19:00:07 -0700

Hi Andrew,

>> 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.
 
> are considered unprotected structures.

agree.

> (1) caches valid objects from previous downloads,

Which is good.

> (2) validates through the certificate chain, and

good there too.

> 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.

> 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