Re: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved)

Tim Bruijnzeels <tim@nlnetlabs.nl> Fri, 28 August 2020 12:10 UTC

Return-Path: <tim@nlnetlabs.nl>
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 2C6F23A0978 for <sidrops@ietfa.amsl.com>; Fri, 28 Aug 2020 05:10:46 -0700 (PDT)
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
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 j6padwmW49qL for <sidrops@ietfa.amsl.com>; Fri, 28 Aug 2020 05:10:44 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C463A0930 for <sidrops@ietf.org>; Fri, 28 Aug 2020 05:10:44 -0700 (PDT)
Received: from yoda.fritz.box (unknown [IPv6:2001:981:4b52:1:756d:96d7:8934:5a50]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 5A0421B716; Fri, 28 Aug 2020 14:10:42 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1598616642; bh=XxN+FdOVyLkS0KnKzPO+B9MT5d3ryfAN4cKuxgwYPEQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=MaphoM/xaWeW60EJgJjhhQ92nlasEgxY+TvLxtqtow71irTm9YsdZBfZOc+3WWeWR e9qIgvYmLMw94/tPPkltPeGDBlc/PPZzI2UljTVOb10Oc1ZqKgLZhB7tXfwbhJxqg+ EZe08Tq86wLfswCwJoqw5IhPwhHLjsSgcsettCq0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <m2zh6fugil.wl-randy@psg.com>
Date: Fri, 28 Aug 2020 14:10:42 +0200
Cc: Jakob Heitz <jheitz=40cisco.com@dmarc.ietf.org>, SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D034AED-89C4-4D94-893E-A95C49739B4B@nlnetlabs.nl>
References: <DE33EFAE-FBD2-478F-92A9-1FBD81CCC43F@arin.net> <727F6FBD-F73C-4F58-AE2D-0276B2A183A3@arin.net> <20200826160001.GF95612@bench.sobornost.net> <20200826202442.232829fc@grisu.home.partim.org> <alpine.DEB.2.20.2008271422560.11025@uplift.swm.pp.se> <BYAPR11MB3207632B2057B4AE6F68DE72C0550@BYAPR11MB3207.namprd11.prod.outlook.com> <m2tuwovv0p.wl-randy@psg.com> <C953A9CE-046E-418A-9188-55E457EF0F2F@nlnetlabs.nl> <m2zh6fugil.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/2QWoWbMmbKDMmTKR7tc_JpCNFqA>
Subject: Re: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved)
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: Fri, 28 Aug 2020 12:10:46 -0000

Hi,

> On 28 Aug 2020, at 14:00, Randy Bush <randy@psg.com> wrote:
> 
> excuse, but a bit pre caffeine here
> 
>> I believe that, if the publication point for a Certification Authority
>> in the RPKI is rejected for whatever reason, then all VRPS for
>> prefixes overlapping the resources issued to them in their CA
>> certificate for said publication point should be filtered out.
> 
> complexity and cleverness produce fragility.

Sure, but:
1) it may not be that complicated (SLURM does the same)
2) as you said, if you only reject the objects under one CA and the same resources exist elsewhere this can lead to invalids

> 
> first, you may not know the prefix from the failed pp; it failed.
> second, getting you to think that you do could be a nice attack.

You were looking at all the objects listed on a manifest you found for a valid CA certificate. You know which resources the valid CA certificate holds.

>> It is important to only do this for VALID CA certificates with invalid
>> publication points.
> 
> i am not sure what an invalid pp is.  one where none of the referring
> object(s) are cryptographically validatable to a TA?

I thought the discussion here was that if any of the objects for a mft is invalid, then all objects should be treated as invalid. By publication point I mean the MFT and all objects listed on it,

>> if one would start doing this for invalid over-claiming CA
>> certificates then this would of course open a wide vector for people
>> to DoS legitimate statements about other people's address space.
> 
> good reasone not to do it at all.

As above.. I just wanted to make it abundantly clear.. you start off with a validated CA certificate.


> 
> randy
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops