Re: [Sidrops] 6486bis: Failed Fetches

Christopher Morrow <> Wed, 30 September 2020 06:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0EC73A1277 for <>; Tue, 29 Sep 2020 23:55:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QYmhMe3v2BmR for <>; Tue, 29 Sep 2020 23:55:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 990403A1225 for <>; Tue, 29 Sep 2020 23:55:54 -0700 (PDT)
Received: by with SMTP id d1so409669qtr.6 for <>; Tue, 29 Sep 2020 23:55:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=zmOIMYX6ldYOfW3B1BVxkF4DNtxzw8H5+Uz0Lq31J6Y=; b=VO481/DrcZv7Gnzftd3W+Uui1cOLiCUUNoVSXUVbh0442au+mLkQEptHbmhcmWD/U5 sLeUlXbNJXs1oI0N87zGudllWGF4JZMIJRQjBCoTOCfy/jl2mNijhWr8dq9U6MvhoE3w c6CS3MUlgqCjH2jud7tt5e2rqOkAZXZr1YMR66O8hI+N/UWXFCPJNuaLPPYgUshg/D+r GoIVZ2D1DQsmUqUHfOn4GTMzh5Y0EDcb2f0V8gOt4YVNPGKLpHd8iu5Qk5nrDa3M0nk2 gzjbiOWolIZvC49+PgF9zO2aGbEwuk6QM0t6tWCWZps5hFgXQ9q7uyCG2RkpS6fYkR0C Bsog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=zmOIMYX6ldYOfW3B1BVxkF4DNtxzw8H5+Uz0Lq31J6Y=; b=Zoisd2ZlHFc1iNtIk3DTx0TG1hm+vDMlj9209W1lRYUwokt4XX8+j0Y9v+bKlt5RRm vzlsDbwDiOgUmRDpKk64FmMSqZoGoBOZCoGojgStaNVxondRrvA8Mg5DZEsqQpivDHTu LfOfQq/0xUnjHmiO4tligUZ3Rt2sLwfxYsEmNfxs5LRgHYZh9FzrvlHd9PIUzYZE8YH1 WVov/IBymeNTiMiY6/T396L+oBBzBLw2qRAypJJZTPGWRhnvJn1RLX/G8gjZXykWKylO qjmWpYy5t+ZEk2jf1QdZhM5nChjMgCg6VlnE2luakqlGwp/evJvXGoSkxf5ad8j1HBJ8 lvlQ==
X-Gm-Message-State: AOAM532yoWFXg6lSCSQywFsMRGlwHKQhKIya3kHEvn3rwEkGDMGnwIak avmyGptatBSMSPKYFI2AA7DMcLwxYKC4cShx3tsMLMK11Os=
X-Google-Smtp-Source: ABdhPJxVXvNdKexWOFG8tQQZtsfEyeJUOP+iFqQbM0kO0t1VuyQ/5FiH/oQ2HC/oDoZwd/Jyc3oDCOcDmIjMQuly/VQ=
X-Received: by 2002:ac8:19a6:: with SMTP id u35mr769783qtj.315.1601448953275; Tue, 29 Sep 2020 23:55:53 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Christopher Morrow <>
Date: Wed, 30 Sep 2020 02:55:42 -0400
Message-ID: <>
To: SIDR Operations WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Sidrops] 6486bis: Failed Fetches
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: Wed, 30 Sep 2020 06:55:57 -0000

 First, thanks! having some tested results on an optional path (for
newly added types) seems cool.
it's at least informed some of the conversation, which seemed to go a
bit outside the original point of order (in my re-re-reading anyway)

I think the salient points in the discussion are really (happy to be
corrected, of course):
  1) the -bis is proposing a simpler handling of publication point collection.
      this simplicity is a bit at odds with some Internet principals
(robustness principal), but
      trades this for very clear behaviors in the RP software.
operations folk (myself, job, mikael though I missed his mail...
      were a bit concerned with the different flavors of 'correct'
that can pop out the RP :( and see that being simpler about
      the flavors/options may make all/MOST RP get the same set of
answers... predictability / consistency are nice.

  2) the CA software and operations have to be very clear now about
what is/not published,
      keeping in mind that mistakes in the CA Publication Point will
have repercussions.
      Perhaps these need to be clearly articulated in the -bis draft?
(more clearly?)
      This will, I think, clearly have impact on both CA / PP software
and on operations of the CA / PP.
      I think this is good, actually as we're (sidrops folks i mean)
attempting to push for:
          o  closer compliance to consistency
          o  more reliance upon the whole system
          o better overall security for the routing system

  3) With the proposed simplicity/strictness comes some potential
problems, at least:
      o problems in a CA / PP mean that CA / PP may not have their
most updated information (routing intent) available
      o continual problems will lead to fallback to 'unknown' in the
routing system
      o adding new object types seems difficult (just my reading so far)
         particularly there's a note about 'people won't upgrade their
RP software'

I think that the simplicity is a goal I would like to see achieved,
specifically because inconsistent results in the RP set is problematic
longer term.
If we can get to more consistency before we roll a bunch more out
we'll be able to course correct better/faster (I think).

I think the idea that people won't upgrade... sure? maybe? Also: "Do
you  like killing kittens? because not managing your business critical
systems a great way to kill kittens." We've been able to push more
people into RPKI and better routing-intent hygiene, I don't see why we
can't keep doing that and get folk to treat part of the routing system
as critical to their business.

We should not shy away from a solution just because we may have to
convince people to upgrade.

I look forward to the discussion tomorrow/thurs.


On Tue, Sep 29, 2020 at 10:55 AM Tim Bruijnzeels <> wrote:
> Hi,
> On 7 Sep 2020, at 13:17, Tim Bruijnzeels <> wrote:
> >
> >>>
> >>> If we do go down this road then I think that we should also look at the manifest object itself, and let it convey which object (types) are critical (and while we are at it, we can specify types instead of using filename extensions). That way future object types could introduced more easily perhaps - this obviously needs more discussion but it could even allow for semantics like: 1) new object please test, don't use, 2) new objects, use if you can, 3) new objects, critical - fail if you don't understand.
> >>
> >> One could combine the new SIA URI and a revised manifest, in which the manifest contains the per-object flag, rather than redefining the basic object format to accommodate the flag. That would reduce the number of RFCs that need to change. Good idea.
> >
> > Upon reflection I realised that even the introduction of an SIA in the issuing CA certificate will lead to issues. RPs would reject the CA certificate, and as a result the whole PP of the parent CA. This means that the SIA cannot be deployed without leaving a significant number of RP installations behind. E.g. if I run a delegated CA under an RIR which wants to adopt ASPA, and I get a new CA certificate with the additional SIA from my parent, then 1000s (RIPE NCC >12k) other CAs will also be rejected.
> I have done some testing on this.
> Section of RFC 6487 seems to say that additional SIA OIDs for CA certificates can be expected and can be ignored. And indeed it seems that all current RP software will accept (and ignore) additional SIAs.
> At least that's the result from adding an extra SIA in a Krill branch and running the end to end tests using the following validator versions:
> fortvalidator 1.4.0
> OctoRPKI v1.1.4 (2019-08-06T16:51:07-0700)
> rcynic version believed to be buildbot-1.0.1544679302
> routinator 0.7.1
> rpkiclient 6.7p1
> rpkivalidator3 3.1-2020.
> I am still not very happy about the overhead that this approach implies:
> Additional publication points which need to be maintained, which may be out of sync. What if MFT A has a certain ROA and MFT B doesn't? This can lead to serious operational impact if an announcement would be valid under one, but not the other.
> It would also require much more fundamental code changes for producing CAs - one cannot just support a new object type. One has to support an additional publication model. Parent CAs have to be willing to include the new SIAs as well affecting the ability to deploy for delegated CAs.
> But, at least it seems that it can be introduced without breaking things immediately for existing deployed validators.
> Tim
> _______________________________________________
> Sidrops mailing list