Re: [Sidrops] what to do when the CRL is hosed?

[Job Snijders <[e-mail]>]

On Thu, Apr 02, 2020 at 11:46:06AM +0200, Martin Hoffmann wrote:
> George Michaelson wrote:
> > I would remind people that *all* the products in a repository are
> > signed objects. To arrive at a state where a manifest is "wrong"
> > demands two things: it doesn't reflect some real-world situation
> > regarding contents of the repository *and* its signed by keys you can
> > validate back to a trust anchor. If you cannot validate the manifest,
> > then its not "wrong" its forged, or invalid cryptographically.  To me,
> > a  "wrong" manifest checks out cryptographically but somehow is not
> > coherent with the state of the repository.
> 
> I think we are still having this conceptually backwards: It isn’t the
> manifest that is wrong, it is the repository content. Whether it was
> originally intended that way or not, having a manifest at all to me only
> makes sense if it is considered to contain the truth, the whole truth,
> and nothing but the truth.
> 
> I honestly believe that the current state of affairs where basically
> the guidance for RP software developers is to look at the current
> repository content, past repository content, the manifest and the CRL
> and then figure stuff out themselves is rather ... unfortunate and
> doesn’t exactly improve the confidence in the overall system.
> 
> Given the inherent complexities of a distributed repository, it seems
> important to me to make the system as straightforward as possible to
> implement. Declaring the manifest to be the sole list of currently
> published objects is a means to this end.

I agree, straightforwardness is crucial here. rpki-client has now
implemented mitigations as following:

When the manifest is valid (valid in the sense that the signatures check
out, the CRL is not expired, the manifest file format is correct), and
it references .roa files which are either missing from the repository,
or where the .roa file's hash does not match with the hash listed in the
manifest, rpki-client will not output any VRPs that could potentially be
extracted from the remaining .roa files at that level of the tree.

At the MITM layer one roa is hidden from the view:

    job@mieli:~/fake-ripe-repo$ rm repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/LkKeUPYrfgzjsOIejLjsHGk44cU.roa

After this partial witholding attack, the validator under attack will emit this error:

    rpki-client: rpki.ripe.net/repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/1-tcQDnftkRnWbiMhu2cR1-dgmCs.mft: referenced file LkKeUPYrfgzjsOIejLjsHGk44cU.roa: No such file or directory

which results in no VRPs being emitted from any .roa files that
1-tcQDnftkRnWbiMhu2cR1-dgmCs.mft referenced:

    job@anton ~$ grepcidr 80.128.0.0/11 /var/db/rpki-client/openbgpd
    job@anton ~$

The above is the *safe* outcome, because the attacker is now limited to
the ability to flip BGP announcements from 'valid' to 'not-found',
instead of 'invalid' (in case the validator has not been patched).
Scenarios where routes flip to 'invalid' represent hard outages. The
operator's understanding of the RPKI is that when things go wrong in the
RPKI, BGP routes potentially change state to 'not-found'. 

In other words, because LkKeUPYrfgzjsOIejLjsHGk44cU.roa is missing, the
following .roa files are *not* parsed:

    repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/IM3xMiMU1QChuWMOGgnbDwYolrU.roa
    repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/NpI_Uj3OZb6jvwfUTX0-eOk9QV4.roa
    repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/fIeCcC8KpdJQd-olU2APdxNZkyA.roa
    repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/r5vtD4isKhTzGXNGulSnZ7XCS04.roa
    repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/r7TSyWn_GbYPjNWvt4r5ewSNAsk.roa

Even though they are referenced in 1-tcQDnftkRnWbiMhu2cR1-dgmCs.mft
(valid), and the remaining .roa files are valid themselves.

Proceeding to output VRPs derived from say 7TSyWn_GbYPjNWvt4r5ewSNAsk.roa
while LkKeUPYrfgzjsOIejLjsHGk44cU.roa is missing is akin to "garbage in
garbage out". Manifests are truth. A repository can contain /more/ files
than referenced in the manifest files, but not *less*.

Kind regards,

Job