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

Stephen Kent <stkent@verizon.net> Wed, 26 February 2020 22:35 UTC

Return-Path: <stkent@verizon.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 C601C3A09B2 for <sidrops@ietfa.amsl.com>; Wed, 26 Feb 2020 14:35:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
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 ycceIqApptkd for <sidrops@ietfa.amsl.com>; Wed, 26 Feb 2020 14:35:47 -0800 (PST)
Received: from sonic312-21.consmr.mail.bf2.yahoo.com (sonic312-21.consmr.mail.bf2.yahoo.com [74.6.128.83]) (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 5A1CE3A0995 for <sidrops@ietf.org>; Wed, 26 Feb 2020 14:35:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1582756546; bh=A4mP3vBfuG9o7H15Th4vn8CLBPnUrp47qWHD/1LGaBE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=ZcXBmmtjlI3AK3kK/HC92xu+OO7ek1emHIL10bNhzyEZnrHfX6ND5221lfGpJTK8GJqjPwYGjhKxUtOg+B2eTY/vhnJQLd0DQbO+1xMoPGwl3J9ASJbHT4+8M6M37BoyVowdtwOnhhtZsv1e/LqsFeRnK9ErY3JKAeQWa+nwL9YoQXUpfNPxqniRmotZKZe4dKKmj9Zrc5Gywh4rfKSZcva98kmS7lDqMH/EY50vPu700FpCtz7u1USO0zJG1qvp8gOnHDpI7Js5c/28F6qoTNIqxhaeYNxVndApgn0RgOMYpvEcCQ+GxyyGu2PcPIdesOpyTjn4sihj4Ved2Kdukg==
X-YMail-OSG: 5VzkOUUVM1lGGk71AY6zoS_qRsVmBZl7c.VVV8P6TKFLOgQX08HJ1u1vCJ6B6Do tOs0.4_GU1ArPv0slHOVywBrhwcjVflbQA4iWnjUhnj9bSjRL6a3Ov1RB.shMuoVWhEpbaIqVgFr Q8BW1Bx89n9o859IH5vfcnoZXTm4jfdWnaxzhebrXJENldsV.AtfoEE52jvUv0rrW_qASJmm_mQr qrF4aRZ24_GdBzHMv2778ui4vUCJlLR9bDCI6Vu8mykLtPlzeRh7QbLZoRpu4OB7u5DXmNnLVphT 2uitkx1JYHj2B1rX1DkfHGOabhkUPXEVPK2.1CnvQslPf9q6R.d1Fvl54bHeB2TVfXpybqRH1pXx iG4JLHz6G5V7eUSGuhi2buMGTEWT9yMKpERA5pNwMSXwVwXoJz7fYIn0RWzg676JBedi_CUIzQHK Nzv6NhlMJW1SfeZNDs6KrPdXxby5FhaR_H0lq2rWXnXdO6MD8dkp7fHy6ejxhJkvW4mh3kN_ui_S cieYmiB91lBUHYRSCwM7wqAixlw8Nz5RUOH264Vk9HDBCCtSaJPqxiYZCoeIv8MbvAU4WRkUyO73 frc_qkaoOMDo_pzBuJBtxEitXYzF.i5q.QJ3vdduFVNmnLqSt9oMVLNU9GeOZWe2sViLbzSQ5oha 1mWsg9XLB8.QrzT6rkxcs27LX2MlR8EWCbz4qksCxAoPbI4bHWePn.U2S2.ZrKVsnR9nPMHoAwc0 _jm3Dnv38wJPLCJh.Stv2gXDEmXCYuf19yxYN7F1bex_v.3ayarQEq7HPTJg8axVXWaAvIfX9JY5 aV2SWN.7aCXYiXvoug2rz7D0x_SGdA8eiGjrQV2npSSZkOAogyv9jK2ZLikj6ESIsjB38H.pR2So 5ZFVc1PAwgxDRS4MUKknGnUlSLvw829nZAhEAT.Xr.Km6gCIyP3YSRmmjadZrPZ049XMqzu_p5cL 41d.7nOWLA0Agm_1P5OxorTtmKclEmvW.IqXBcuU0vhKlpGONfNVpY5TtQbGDtOdjtS5GuyZcBoQ _7QSfgF93QqHv7eOJ31fV5DL1_4fUvk9i2aWUpDU_7MhLopsHotjSPeuJN37qDFb9nJNAgdiQZVR ItLzSu3BkzQvRgQw2.a65v7t0eZKMOf.lmipyUt3_Eligdm.uS7Vs1B3hk3Xz47zRV5U9eMnkAhn li7bSmhy1zVGc1xBoCfpLEZqnWcw8B6VJaMe_m0p2srOdOFvBJd2dH95Ae8JArOJP0._5vI3juu2 xzS7eMx.ms1XEm6Qg1X_Ae0fKvUM3kusRRX9eEmNEEIMRSCiPkyGrfLa5zpHmmdX.4LaWLjOPkeG RK6tlER2z9kGdkPao2QTAd3KU1NqVzUsMWHOpU9rHRUO3MC7A49QNFb2rMvxinM73n08dR.6z7Vv M6TxSBz7lLDzfjh2.5bqLpRlRjCTb73qKoVCs
Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Wed, 26 Feb 2020 22:35:46 +0000
Received: by smtp426.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 60dcb33843dac545680354f568e4cedc; Wed, 26 Feb 2020 22:35:40 +0000 (UTC)
To: Job Snijders <job@ntt.net>
Cc: Tim Bruijnzeels <tim@nlnetlabs.nl>, sidrops@ietf.org
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> <20200226173935.GE72144@vurt.meerval.net>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <ef02db61-0b30-8523-6d64-8abee8950dd1@verizon.net>
Date: Wed, 26 Feb 2020 17:35:39 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <20200226173935.GE72144@vurt.meerval.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15302 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_241)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/UknWIil1veMca5EBiYdpayFclcs>
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 22:35:55 -0000

Job,
> 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)
I'm confused by your example. The discussion has been focused on CRL 
issues, not suppression of ROAs.
> 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.
Do you mean the pub point for the address space holder, vs. "the 
repository", which suggests a larger set of data, e.g., RIPE operates a 
repository that contains pub points for their members.
> 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'm afraid I have to disagree with your conclusions., in  part because 
of confusing use of terminology.
> 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'.

A goal RPKI operation is to not make routing worse that it would be in  
the absence of the RPKI. Thus it seems appropriate to tolerate some 
types of operational errors, on a temporary basis, and try to follow up 
with CAs or pub point operators to resolve the errors. I acknowledge 
that different responses may be appropriate depending on  the nature of 
the error - a stales CRL is not the same as a bogus ROA.

Steve