[sidr] looking at repository withholding attacks.

[Terry Manderson <[e-mail]>]

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