Re: [Sidrops] 6486bis: Failed Fetches

George Michaelson <> Wed, 19 August 2020 22:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE3AD3A0D05 for <>; Wed, 19 Aug 2020 15:15:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rlJWkzZmCJ96 for <>; Wed, 19 Aug 2020 15:15:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 11F1B3A0D0B for <>; Wed, 19 Aug 2020 15:15:28 -0700 (PDT)
Received: by with SMTP id g19so330326ioh.8 for <>; Wed, 19 Aug 2020 15:15:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=p9oS8zZqdXARxHJwbg27xRYL2ihxyUCLenMugVkcqME=; b=qqENcHtXMxGAfYnLyaInXsx1+urJH6haYIuq0z8co/jh7vyQqJXvEY2afDSwEcOvOZ VJCfdHztyDzakESVO6Fa9zVeRLj/g0x3nn58yjL0nOV1ZcPB0mm+4vZlSMVjwEMiujyH bW/5LdTqfuJ2SmiNT6AO4imxvzzjCwZnVh8NAGRff16jpp1qUfPA3vBWaj/7HyOPdERc jlwKyg1u7rQkrZdzhtuichr2gXRZ2em6JDeMbuUFM4teGS0ZDbtU+bazyfHmk9hkZBuh Bl+KU51SxyDvtkWpEEAkFwPjm+6cEVvkWU7XmoN23RHQbgynpKCaNOTjeM7S+zZ3sfwU /EFw==
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:cc:content-transfer-encoding; bh=p9oS8zZqdXARxHJwbg27xRYL2ihxyUCLenMugVkcqME=; b=aJOkgsfvkiuF6MUVAfT3WErKg+9DSCg1FLfcg4d3zXa/YQW+BgMF/EwUUPRDXR7pAb tFnnappZg2r9ldMhD29+qgVY7ayXZzRy/AED0qf9wryIKMEcmvLFy0Rv57dOoruu7yti hNX9ND8tto+/5pUwPmkAjG9366dhVp8NJuHWddl6lBqjDqNO+cQPEnUzCycWIsVn54C5 jASCWZTItgbobapckssANSZlSNDjDgJ3C74yuwfBi+oWvlDROIFOm8ix56XXkE8d/sfL nJY0WNftloJzX0CPfY6le61iLqFNWQOHfDzzfwmnUq2BzEihAw1ZwJqVqs2mgdGk53Gt HOeA==
X-Gm-Message-State: AOAM533i90M1mKaql4ViMrMLdrq/n/3gOP5tnA1Y30j+s0h0N/6XGK2I EuVslSCu84uZYw/TK61OfOHzH4Mztt6xHw6Gy5aG9MD2PIijKA==
X-Google-Smtp-Source: ABdhPJzHxYerfOB7kXC/OErCWqSYbGevrrxwDNxu7yNNzcWc67YSpR2kov+X0dka6oCbj98BGHX1t/Syz0kO0xcsDQY=
X-Received: by 2002:a6b:6204:: with SMTP id f4mr94539iog.56.1597875327642; Wed, 19 Aug 2020 15:15:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: George Michaelson <>
Date: Thu, 20 Aug 2020 08:15:16 +1000
Message-ID: <>
To: Di Ma <>
Cc: Martin Hoffmann <>, Stephen Kent <>, 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, 19 Aug 2020 22:15:31 -0000

Yes. This is what I mean.

The fly in the ointment is the CRL. I think we need to be very sure
about how you source a CRL which invalidates things being used to
validate a bundle. Is it acceptable to use a CRL which was applicable
when the object was constructed? I think this is weaker than requiring
the CRL to be checked for applicability at the time you validate. To
do that, you have to be online and have access to all CRL from all
Repo along the validation path.


On Wed, Aug 19, 2020 at 10:29 PM Di Ma <> wrote:
> George,
> > 2020年8月19日 03:50,George Michaelson <> 写道:
> >
> > FYI we fully intend resubmitting RTA, we were waiting for the second
> > implementation (the work Martin is doing) to have input of merit to
> > spin the new version. It would be plausible to resubmit for the
> > November IETF. Two running code!
> >
> > We designed RTA to be complete outside of a repo, so it can be used
> > privately between B2B partners. Not that its things cannot "be" on the
> > manifest, but that there is no dependency on the repo framework beyond
> > the TA, because the passed data is the chain for validation. This
> > matters to people who want to conduct activity outside of the BGP
> > validation problem, which is an 'all data needed' problem. B2B uses of
> > RTA are not directly about all data. Its different. (provisioning is
> > typically the use case here and the intent is to show the request to
> > route, originate, provision is valid, because control of the resource
> > can be demonstrated. its inherently a one-to-one conversation)
> Do you mean RTA validator has nothing to do with RPKI repository sync, given the RTA use-case just requires the INR holder to provide all the necessary certificates to construct the validation path down to TA?
> It reminds me of the similar model in RFC 6494 where the RPKI is used for IPv6 SeND.
> Di