Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)

Job Snijders <job@ntt.net> Fri, 08 May 2020 18:01 UTC

Return-Path: <job@instituut.net>
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 80F4C3A0ECC for <sidrops@ietfa.amsl.com>; Fri, 8 May 2020 11:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
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 ujyJ2sNQDLqP for <sidrops@ietfa.amsl.com>; Fri, 8 May 2020 11:01:13 -0700 (PDT)
Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EDD53A0EC2 for <sidrops@ietf.org>; Fri, 8 May 2020 11:01:12 -0700 (PDT)
Received: by mail-wr1-f44.google.com with SMTP id i15so2898926wrx.10 for <sidrops@ietf.org>; Fri, 08 May 2020 11:01:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=InJMDz6mkHC/kT22zDuc9ADV9Nu9wuy8RGUrGlnfJ+I=; b=lDHFK6MeSAhwZONneD6i7Yk2NH/w6Oekjdmf5FNUPdyLiFC1F0Tdc1SH07aApI5la2 s1yZuBtN8ZbPAOmHzo/xAPBZqQJxxDpQdwFkLj3EzQiMAWtIUlqiAQgtu0e4/V9nahiJ fOlhYeGPgAf6SZjetNWA50Wi2gIA/Cay21So0hwdebH0X2aIKHSovzynySRrF6PG8l/z hqbfn+KgOQ9tinEflaRtFXIMI+HS4eLG9oRzm9C7ghks8dLk2EnHhSB9izk0CtaZzFNW N0BKFhJw1BT/S8O+aH0FtT08n9901Lqd7Tnu/ABhHHHk1DC0fqddTbEi5cC7gHebodzL ZTZw==
X-Gm-Message-State: AGi0Pua/tMk0JtN6fRxEg3Ge9fSd4J3GlAcSQV8qPknmAXU0lb6HwLR3 Zlk7MZ8rBYRBxBFYAEfmvxg8YTWnVVg=
X-Google-Smtp-Source: APiQypJ4hhAxa9dTtiY/DnIPdDiFSgpS8BpNJOWF81S34NvUAR2N7GgthbkH1NpAQe4s/MyHr8iN5Q==
X-Received: by 2002:a5d:690a:: with SMTP id t10mr4233759wru.225.1588960841412; Fri, 08 May 2020 11:00:41 -0700 (PDT)
Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id g10sm3857030wrx.4.2020.05.08.11.00.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 May 2020 11:00:40 -0700 (PDT)
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id c8be7ca4; Fri, 8 May 2020 18:00:39 +0000 (UTC)
Date: Fri, 8 May 2020 18:00:39 +0000
From: Job Snijders <job@ntt.net>
To: Di Ma <madi@rpstir.net>, sidrops@ietf.org
Message-ID: <20200508180039.GA18937@vurt.meerval.net>
References: <be9450ba-fe9c-465f-98a2-919772b3b32a.ref@verizon.net> <be9450ba-fe9c-465f-98a2-919772b3b32a@verizon.net> <38D78A3D-BB4A-47B6-9507-14C116BC3FE2@rpstir.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <38D78A3D-BB4A-47B6-9507-14C116BC3FE2@rpstir.net>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/kO3PJcmtRL4UfAI61Js5paAsdPg>
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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, 08 May 2020 18:01:17 -0000

Dear Di Ma,

On Sat, May 09, 2020 at 01:33:29AM +0800, Di Ma wrote:
> Thanks for your efforts for writing MFT update and reflecting the
> feedback from the mailing list.
> 
> I am fine with it except the re-use of previous local cache.
>
> I find it is hard to implement the logic about retrieving objects from
> local cache with RPSTIR2. 

Can you elaborate on why it is hard in RSTPIR2? I am not familiar with
this implementation and can perhaps learn from it, or offer suggestions.

> As I replied to Robert in your discussion with him, in terms of
> synchronization, RPSTIR2 keeps its incumbent local version exactly the
> same with global repositories.

An RP can't know if it is in sync with the global repository. The trust
derives from the pre-obtained RPKI TALs, through the X509 validation
procedure and outputs Validated ROA Payloads.

In this process the data that can be *least* trusted is what came in via
the untrusted network channel (be it rsync or RRDP). Withholding or
corruption by issuing 'withdraws' (RRDP)  or '--delete' (rsync) cannot
be trusted at all. With this in mind, one really really aught to
reconstruct the original publication point's repository, suppplementing
it with locally cached data as much as possible.

> Although RPSTIR2 keeps the historic versions locally, they are stored
> for diagnose and analysis (maybe to trigger SLURM)
> 
> If some RP can retrieve missing objects while others can not, data
> inconsistence will occur among different RPs.

This already always is the case, and will not change. RPs pull from the
CA's publication point from different places on the Internet, at
different times.

> I think we just need to keep RP in alignment with PP and then can
> perform some analysis and diagnose (if necessary) to ascertain errors
> (RFC 8211) to give warning or make use of SLURM (RFC8416) if the RP
> operator is confident enough that he catch the wrong data and knows
> how to remedy locally.

How will the RP stay in alignment with the PP when the RP is under
attack? Intercepting and corrupting rsync connections is trivial and the
RRDP protocol does not offer protections against unauthorised
modification of the data presented to the RP.

> To sum up, I would like to see :
> 
> 1) RPs are encouraged to store historic versions locally especially
> the validated RTR-output

> 2) If the RP finds some missing objects (not in the CRL, still in the
> MFT) , it is suggested to issue warning to operators and SLURM can be
> used by the historic data.

What is the 'timing' of the process you describe under (2)? I cannot
imagine any manual intervention in the validation process to scale for
the purpose of the Internet routing system. Perhaps I'm
misunderstanding.

> I therefore really look forwards to hearing from folks of other RP
> software to comment on this.

It is my intention to provide the working group with an implementation
report of OpenBSD's current rpki-client version in relation to the text
that Stephen Kent provided today as 'rev 4'. I hope to be able to do
that next week. My report will be usable as a template for other
implementation maintainers. Comparing and sharing implementation notes
is fun, stay tuned!

Kind regards,

Job