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 06:40 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 5314C3A159B for <sidrops@ietfa.amsl.com>; Thu, 27 Aug 2020 23:40:48 -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=ham 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 kSoFK09D4JdS for <sidrops@ietfa.amsl.com>; Thu, 27 Aug 2020 23:40:47 -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 3F9613A0D45 for <sidrops@ietf.org>; Thu, 27 Aug 2020 23:40:47 -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 88CF51B2B8; Fri, 28 Aug 2020 08:40:45 +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=1598596845; bh=JIsMsS3JgDZYTT4fprsiZ/sfpOqSPFMAy811GAavHK0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=lb5J3GbEiWvXxzI8DzrgNmRvlU4Nm+AUJ2VbYZv4/5/wkTWG81JrNq3Ah9sJIOekp ngniPg11IeoXGO4jgJ8spm16iqQxZwT2CzPlUniMzPFyP1++cwjc+vxcxW9RY5Kz1X iwTVcXWkPyzhH9dnsc6hV+R+bYqkxMbHFiaQoYbU=
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: <m2tuwovv0p.wl-randy@psg.com>
Date: Fri, 28 Aug 2020 08:40:45 +0200
Cc: Jakob Heitz <jheitz=40cisco.com@dmarc.ietf.org>, SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C953A9CE-046E-418A-9188-55E457EF0F2F@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>
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/XpR9ZIPxVWe-WqUNnRhsEYd2lmM>
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 06:40:48 -0000

Hi,

> On 27 Aug 2020, at 19:49, Randy Bush <randy@psg.com> wrote:
> 
>> If the ROAs for the more specifics are gone, then the less specific
>> ROA for the larger prefix will invalidate announcements for the more
>> specific prefixes.
> 
> yep; simply stated.  and perhaps the more likely common case.
> 
> a less common case could be if i am doing a provider switch where my
> upstreams do my announcements.  for "make before break" i would have
> roas for both providers.  if the roa for the one which is currently
> announcing is dropped, kaboom.
> 
> similarly a transfer of ip space from one AS to another.

Indeed, 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.

Note that most RP software already implements SLURM - and this kind of post-validation filtering can be done in a very similar way.

It is important to only do this for VALID CA certificates with invalid publication points. This is what I said above, but I just want to be overly clear here.. because 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.

Tim