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

Job Snijders <> Thu, 02 April 2020 10:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 197FB3A0F2C for <>; Thu, 2 Apr 2020 03:18:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 65ztqwnmdtPi for <>; Thu, 2 Apr 2020 03:18:39 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::343]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 330123A0F1A for <>; Thu, 2 Apr 2020 03:18:38 -0700 (PDT)
Received: by with SMTP id f6so2993947wmj.3 for <>; Thu, 02 Apr 2020 03:18:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=VufYJJHOtlSgDkR4Qt30/EV6STxRn5B+yH0kzknLRqg=; b=GG3rvD/9cR5c9NeebmOKiR9Eh0ZiCfJfHjIa6dAHF5Nkhkn1lOhF+4IjC5wI/sKK/j 80Zh6J3AjXbpJbMdMRpm9Eqpa0c1Igqwgr5ug5ZsiZgyHE6OyX79frWTEb4g4ZeEHBsp imgPbiDafdGdS2+CXURs0VoIRaB3h1rwcbM6pYzG4B9J3H1AE29qmomp+clytvCn9o/l 9kEnsVOJ+O6uKNPYVKgJpaSf0asOq7qctNQY79qz0CMvnmE3/YwwNoz47BEkhzccX+67 HB1zAXvqe2DPLJk6bhzXoPpPaxdrEH+oblEIlvLAUE9oq5EJHO85buNTaf7qr/WGv4KR 6s8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=VufYJJHOtlSgDkR4Qt30/EV6STxRn5B+yH0kzknLRqg=; b=WOlRZnT49rsfhNskPQCizVM/Iw27He7eW0qyzeSp8W8gyNovxUVN911wiCcESW94IZ AbdjT9vK/Rh89DPxyYBHFwPPP6kIKHhlecLZqRgkaHFWDjgY6qfILhJQya/aQO6JKuAp h0UvU66Sr/vLXZzZispx+tY510cIwZYdErVp2FQ11j8MNH4aYujC3yxHaDUyCwahifk3 7YQOJbUim8dGTZ31Y/DmOeO6mEX+9U4biXMsPAEwJWRhY+5zxgF2COcJaEjDChZhF4Hv Daw6h1AT/tadnu3qr+c5LeU/S1REAVwJKc7n4zSITy+PgyVqzTN9HFCVZQc5C+agaKZF PMAw==
X-Gm-Message-State: AGi0PuY6paWZfKFOPlJVPlyTgCeCroYgzEYkLr4ipLmx4E5itx7t1T8J z1CgWlb8uQURrIgJUJGanA0D0w==
X-Google-Smtp-Source: APiQypI9eAfNAv9FC3iKXcGX1ql8FAmpPUa1AWIChBXLbk4aiWMeLwqZkj6m+POhNlYwMFEcAjjHGg==
X-Received: by 2002:a1c:4c19:: with SMTP id z25mr2697161wmf.53.1585822717047; Thu, 02 Apr 2020 03:18:37 -0700 (PDT)
Received: from ( []) by with ESMTPSA id y4sm6593689wrl.40.2020. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Apr 2020 03:18:36 -0700 (PDT)
Received: from localhost ( [local]) by (OpenSMTPD) with ESMTPA id 7f50b694; Thu, 2 Apr 2020 10:18:35 +0000 (UTC)
Date: Thu, 02 Apr 2020 10:18:34 +0000
From: Job Snijders <>
To: Martin Hoffmann <>
Cc: George Michaelson <>, Christopher Morrow <>, SIDR Operations WG <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <>
Subject: Re: [Sidrops] what to do when the CRL is hosed?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Apr 2020 10:18:41 -0000

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: 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 /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:


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,