Re: [Sidrops] trying to limit RP processing variability

Tim Bruijnzeels <tim@nlnetlabs.nl> Fri, 17 April 2020 08:06 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 F00C43A101D for <sidrops@ietfa.amsl.com>; Fri, 17 Apr 2020 01:06:10 -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 FoK69iG0kd_v for <sidrops@ietfa.amsl.com>; Fri, 17 Apr 2020 01:06:07 -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 1F68C3A10AE for <sidrops@ietf.org>; Fri, 17 Apr 2020 01:05:59 -0700 (PDT)
Received: from yoda.fritz.box (unknown [IPv6:2001:981:4b52:1:b4a7:2c39:255:587f]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 6A8F41E5E4; Fri, 17 Apr 2020 10:05:56 +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=1587110756; bh=5m0xlK28Wv/VTJ2EpO0JUAyVvRlyIBc+R0YcQK5uYeg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=hKRa3VRJuvhPFjwgAH7IrPYQT35O2Z910IJceYHW/OafbNdY0eEEhFN9wGb9qzfY2 h3GHbXZ507vziBe2ba699GNzfEX5qY68nrg+WoZ2gCgttT3CvgcfpLBBMNXloFY2yI R+hcV4JkTmoI64T6n2unyO49wqeZTaoQN95HzrS4=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <CAKr6gn3CHpL_hWuvTh+y5OsPLeS8U8bv46=xEcxDQXdFvvvPog@mail.gmail.com>
Date: Fri, 17 Apr 2020 10:05:55 +0200
Cc: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>, Job Snijders <job@ntt.net>, "sidrops@ietf.org" <sidrops@ietf.org>, Martin Hoffmann <martin@opennetlabs.com>, Claudio Jeker <cjeker@diehard.n-r-g.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B5CFCC00-640B-4C7F-ABFC-7B608E557AB4@nlnetlabs.nl>
References: <a9448e54-320f-300c-d4f9-d01aca2b6ef4.ref@verizon.net> <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net> <20200415150141.016d021d@glaurung.nlnetlabs.nl> <20200415140012.GB30412@vurt.meerval.net> <20200415161415.29c49f4e@glaurung.nlnetlabs.nl> <20200415143321.GM72650@diehard.n-r-g.com> <9d7a9500-2ff8-e9d2-f3a5-89eeaa4a90e8@verizon.net> <20200416154509.GT72650@diehard.n-r-g.com> <8ffd835c-cd11-5af0-81bf-d8935e0e2190@verizon.net> <CAKr6gn3CHpL_hWuvTh+y5OsPLeS8U8bv46=xEcxDQXdFvvvPog@mail.gmail.com>
To: George Michaelson <ggm@algebras.org>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/82eWWPSUP7oI7u3i5Cm-mjb_GyE>
Subject: Re: [Sidrops] trying to limit RP processing variability
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, 17 Apr 2020 08:06:11 -0000


> On 17 Apr 2020, at 00:48, George Michaelson <ggm@algebras.org> wrote:
> 
> If a ROA object can be removed and a manifest proves it has been
> removed, and a CRL confirms it has not been revoked, the unknown
> question is:
> 
> * what was the semantic intent of the ROA?
> 
> If you have a previously acquired state of the ROA which meets the
> manifest checksum/sig and its not in the current CRL *ITS NOT MISSING*
> and you know its semantic intent. All is good. This is what
> maintenance of local cached state of fetching achieves.
> 
> If you do NOT have a previously acquired state of the ROA, you cannot
> know its semantic intent. Job showed me that this means a covering
> aggregate ROA state which is superceded for a specific prefix can be
> invalidly interpreted as applying to the more specific. Any more
> specific. The semantic intent of unknown amounts of ROA covered space
> defined at this level in the CA hierarchy cannot be stated
> categorically because the missing ROA might modify any of them.
> 
> Therefore, the ROA states of this level of the hierarchy and children,
> cannot be known categorically.
> 
> IFF (and the FF is important) you don't have a valid ROA state cached,
> and you can detect from valid CRL and valid Manifest some ROA is
> missing, you cannot know how it modifies the routing intent in the ROA
> otherwise unaffected.

IFF.. I had to look that one up.. it stands for 'if and only if', right?

> 
> I think therefore, you have to stop processing. But the IFF part is,
> if you do not have a valid prior-state fetch of the ROA. Just because
> "its missing" is not sufficient. If the one you have before refetch
> maches what the Manifest says is a signed state, you aren't missing
> anything.

Well, I think I agree and it's what I have been trying to say. If an object is missing on a specific synchronisation job, but you still have an old copy: you know the URL, you know the hash. So if a current MFT refers to it, you can just use it.

A thought I had on this is that RPs may consider treating withdraws (be it rsync or rrdp) with prejudice. One could argue that an RP should only forget an object seen when it has seen a positive statement that it's no longer relevant:

Object becomes relevant:
- CA cert signs MFT listing object by URI and hash
- The object matching the URI and hash is retrieved (rsync or RRDP, it does not matter how)

Object becomes irrelevant:
- CA cert signs a new MFT where the object URI and hash combination is removed; AND
- The object was indeed validly signed under the CA cert
  (otherwise you open a poisoning window, I could list and delist your objects)

So, do not just remove the object because of rsync '--delete' or a withdraw or update (publish with hash) seen in RRDP. Wait for a signed confirmation.

However, I understand that this will introduce quite some complexity that may not work with existing implementations. There may also be other, better ways. For example you could keep a reference counter of MFTs referring to an object by URI and hash, and delete the object only once:
- it was marked for deletion (RRDP) and
- the reference count is zero.

Well at this point I should probably leave it to the people who write the actual validation software to say something sensible - or shout at me if you will. Just trying to contribute, don't mean to tell you how to code :D

Tim


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