Re: [Sidrops] what to do when the CRL is hosed?
IETF Logo Mail Archive

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

Job Snijders <job@ntt.net> Wed, 26 February 2020 17:39 UTC

Return-Path: <job@instituut.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75FF3A0D3A for <sidrops@ietfa.amsl.com>; Wed, 26 Feb 2020 09:39:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Level:
X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTidG0kKS_lZ for <sidrops@ietfa.amsl.com>; Wed, 26 Feb 2020 09:39:40 -0800 (PST)
Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BABB3A0D39 for <sidrops@ietf.org>; Wed, 26 Feb 2020 09:39:39 -0800 (PST)
Received: by mail-wm1-f67.google.com with SMTP id p17so149093wma.1 for <sidrops@ietf.org>; Wed, 26 Feb 2020 09:39:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=FgW+QJKFS8iYtdCkagWUE4oKsImfNpL44HQ0HeIEmbo=; b=X+9nBm7YXzQg/V2RA/lffgdK+1cNEjbJ21zmjhXuS14YMG8Rhn5tZKaGWkfL2zp5ZM 0SNrhfYazAUwKUNLXi3KlVffro08m9Y6SHv9J2WUctP8RszNyY22ABn11nqxIgioARxI j7a434Mbhc2jGPGnKk7mFsCU7j+tEusP3lXkVy/UVHsJcQIm1K0xtNuqWHUBYZblipFz g/xgol4SBUDP5oTpo31R/jGhCYAwu7VbP2eooUH72LNhlOK2QAr1GuPDWk9ajPP7u57a fl+6keFBRcTvV44PWPhEZ9O5knsGQibJ1FJMmXbWl0Z/UKs/y8hFOOnRMNxJtH/72qjc krAA==
X-Gm-Message-State: APjAAAU+OBQxup6sirixmtDXgIpMrLVicd06iI/sxoNZn+YhaMYPLkcw p6MhrAfMXpbom1T4nBPjQ/hf4A==
X-Google-Smtp-Source: APXvYqxS2YacoTBsvdGMrOR8GMHfbdi6JWi9H+KDgQoMMR6ZdV7opaCb05DwPOEg2vC+0T6tTqWcBg==
X-Received: by 2002:a1c:960c:: with SMTP id y12mr6658372wmd.9.1582738777669; Wed, 26 Feb 2020 09:39:37 -0800 (PST)
Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id b7sm3636212wrs.97.2020.02.26.09.39.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Feb 2020 09:39:36 -0800 (PST)
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 56d24ff9; Wed, 26 Feb 2020 17:39:36 +0000 (UTC)
Date: Wed, 26 Feb 2020 17:39:35 +0000
From: Job Snijders <job@ntt.net>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
Cc: Tim Bruijnzeels <tim@nlnetlabs.nl>, sidrops@ietf.org
Message-ID: <20200226173935.GE72144@vurt.meerval.net>
References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl> <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/j_ROy0fyYtHXaKmB6BRwJ6eFl1k>
Subject: Re: [Sidrops] what to do when the CRL is hosed?
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2020 17:39:42 -0000

On Wed, Feb 26, 2020 at 12:03:33PM -0500, Stephen Kent wrote:
> As for the considerable leeway accorded to RPs in the Manifest document, I
> concur that it allows inconsistent local behavior. If the WG can agree on
> more proscriptive language, that would be good. When we wrote 6486 we were
> unable to agree on such, as we tried to balance robustness vs. responses to
> possible active attacks on repositories or communications between an RP and
> a repository.

Imagine a scenario where a money-in-the-middle (sic) strategically hides
a select few ROAs, example:

MITM shows rsync://rpki.ripe.net/repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/r7TSyWn_GbYPjNWvt4r5ewSNAsk.roa
(80.128.0.0/11 AS 0 - expires July 1st, 2021)

but hides rsync://rpki.ripe.net/repository/DEFAULT/3e/01d411-d915-4277-8fe2-76b0dda2bf3e/1/LkKeUPYrfgzjsOIejLjsHGk44cU.roa
(80.128.0.0/11 AS 3320 - expires July 1st, 2021)

If Origin Validating EBGP edge routers ends up honoring only a *subset*
of VRPs, it may result in catastrophic hard-to-troubleshoot outages. In
this example, the victim end up being unable to reach half of Germany.

I think the entire repository should be considered invalid if a single
file is missing but was referenced in the manifest. One can't produce
rules based upon false or incomplete data, and one can't protect against
hijacks using unsigned data.

expired CRL? repository invalid
any file missing that was referenced in manifest? repository invalid
the above also means, is the CRL missing? repository invalid
in addition to any cert being expired? underlaying objects invalid

Any other behaviour is a security problem, unsafe. Leeway does more
damage than good.

I believe the premise for Origin Validation to work on the Internet it
is that in order to get it deployed, BGP has to 'fail open', but in the
RPKI cache validation process one must 'fail close', which depends on
all validators being 'strict'. If the RPKI component doesn't fail
closed, it produces false filters, which goes against our desire for BGP
to be able to 'fail open'.

Kind regards,

Job

v2.29.0 | Report a Bug | By Email | System Status