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

Randy Bush <> Fri, 28 August 2020 14:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D4F0E3A0C54; Fri, 28 Aug 2020 07:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xn3nDIlljput; Fri, 28 Aug 2020 07:56:21 -0700 (PDT)
Received: from ( [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A575E3A0C52; Fri, 28 Aug 2020 07:56:21 -0700 (PDT)
Received: from localhost ([] by with esmtp (Exim 4.90_1) (envelope-from <>) id 1kBfna-0008MU-9A; Fri, 28 Aug 2020 14:56:14 +0000
Date: Fri, 28 Aug 2020 07:56:13 -0700
Message-ID: <>
From: Randy Bush <>
To: Job Snijders <>
Cc: Tim Bruijnzeels <>, Jakob Heitz <>, SIDR Operations WG <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <>
Subject: Re: [Sidrops] Reason for Outage report (was: Re: ARIN RPKI Service Impact - 12 August 2020 - manifest issue - resolved)
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: Fri, 28 Aug 2020 14:56:23 -0000

> If a CA's publication point's RPKI data is invalid

"invalid" is already an overloaded magic word in this space; not
cryptographically validatable up to a TA, and bgp announcement not
finding a matching roa.

can we come up with another term for a failed (for many reasons) fetch
of a PP's data?

> a Relying Party MUST add all IP address resources listed on the
> certificate's issuer

what certificate?

> to a Prefix Filter

what is a prefix filter?

> The Relying party MUST consider any VRPs

an RP cache knows if a PP was not fetchable, but does not have any VRPs
(yet), just ROAs.  a router has VRPs, but has no idea what happened
between the RP cache and the PPs it tried to fetch.

i suspect this whole thing is a capybara hole we just do not want to
explore, especially when we have software out there which is <bleep>.

though i would not mind looking at a concise and simple statement of
what it is you're trying to do here.

but do consider the PPs of a CA whose INRs are delegated from multiple
parents, and which, in turn, delegates to other CA(s).