Re: [Sidrops] Distributing RPKI Validated Cache in JSON over HTTPS

Di Ma <madi@rpstir.net> Mon, 01 June 2020 03:40 UTC

Return-Path: <madi@rpstir.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 43AA53A0C3F for <sidrops@ietfa.amsl.com>; Sun, 31 May 2020 20:40:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 HYXKTj8bP_qh for <sidrops@ietfa.amsl.com>; Sun, 31 May 2020 20:40:52 -0700 (PDT)
Received: from out20-38.mail.aliyun.com (out20-38.mail.aliyun.com [115.124.20.38]) (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 B9A833A0B30 for <sidrops@ietf.org>; Sun, 31 May 2020 20:40:50 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.0791467|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.0226426-0.00707572-0.970282; FP=0|0|0|0|0|-1|-1|-1; HT=e01a16384; MF=madi@rpstir.net; NM=1; PH=DS; RN=3; RT=3; SR=0; TI=SMTPD_---.HgUsisx_1590982842;
Received: from 192.168.218.230(mailfrom:madi@rpstir.net fp:SMTPD_---.HgUsisx_1590982842) by smtp.aliyun-inc.com(10.147.41.231); Mon, 01 Jun 2020 11:40:42 +0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Di Ma <madi@rpstir.net>
In-Reply-To: <m2wo4s4h0m.wl-randy@psg.com>
Date: Mon, 1 Jun 2020 11:40:38 +0800
Cc: George Michaelson <ggm@algebras.org>, SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2AE9AF6A-504E-458F-9004-128E198B1EA2@rpstir.net>
References: <DADF530A-9285-45C3-B2CA-73B9D8F3ABE7@rpstir.net> <CAKr6gn2xSpNmX6FyFd46xTFv_F5wYOPfg-y62OD2_P1HAw27pQ@mail.gmail.com> <D7565F35-4D2A-443B-8568-8C998E6D2521@rpstir.net> <E6B0B011-A8D3-44EA-A84D-B1062FBBAB41@rpstir.net> <m2wo4s4h0m.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/9iLyanoyAmg0BoEWHUeeZpoMmwk>
Subject: Re: [Sidrops] Distributing RPKI Validated Cache in JSON over HTTPS
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: Mon, 01 Jun 2020 03:40:54 -0000

Randy,

We need to differentiate two uses-cases.

1) Use SLURM file to update validated cache (VRP) over networks within a bailiwick

2) Use SLURM file to broadcast Unallocated and Unassigned RIPE NCC Address Space (ROA0)

As in case 1, I think it is typically sorta inter-cache within an ISP who does not want to see multiple RP instances bringing inconsistency. It just uses one RP to do sync and validation and then uses RUSH to do sync among cache servers in its networks. so the trust can be established easily in this convergent scope of those cache servers.  And share-key for instance can be used as TRUST to employ IPSec to implement authentication of SLURM file transferred between two cache server. 

As in case 2, I think what RPs should trust is who is authoritative for ROA0. Although SLURM file itself has got no protection for data integrity there are workaround. If you are going to download from RIPE NCC you just need to make your browser/client to trust web PKI cert of RIPE. 

In short, I think RUSH is competent for case 1 and could be used for case 2 which needs more discussions in RIPE community :-)

Di 


> 2020年5月31日 16:59,Randy Bush <randy@psg.com> 写道:
> 
> di
> 
> i am a bit undlear here.  could you walk me through an example, starting
> with what i trust?  e.g. am i trusting a dns name?  a tls cert ca?  ...
> 
> thanks.
> 
> randy