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

Di Ma <madi@rpstir.net> Mon, 25 May 2020 02:33 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 C75013A07F4 for <sidrops@ietfa.amsl.com>; Sun, 24 May 2020 19:33:23 -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 PjM-_Oz141xf for <sidrops@ietfa.amsl.com>; Sun, 24 May 2020 19:33:21 -0700 (PDT)
Received: from out20-37.mail.aliyun.com (out20-37.mail.aliyun.com [115.124.20.37]) (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 965713A07EE for <sidrops@ietf.org>; Sun, 24 May 2020 19:33:17 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.08055069|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_social|0.045464-0.0161111-0.938425; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03295; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.Hd6n0aE_1590373984;
Received: from 192.168.218.230(mailfrom:madi@rpstir.net fp:SMTPD_---.Hd6n0aE_1590373984) by smtp.aliyun-inc.com(10.147.40.44); Mon, 25 May 2020 10:33:05 +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: <CAKr6gn2xSpNmX6FyFd46xTFv_F5wYOPfg-y62OD2_P1HAw27pQ@mail.gmail.com>
Date: Mon, 25 May 2020 10:32:31 +0800
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D7565F35-4D2A-443B-8568-8C998E6D2521@rpstir.net>
References: <DADF530A-9285-45C3-B2CA-73B9D8F3ABE7@rpstir.net> <CAKr6gn2xSpNmX6FyFd46xTFv_F5wYOPfg-y62OD2_P1HAw27pQ@mail.gmail.com>
To: George Michaelson <ggm@algebras.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/YZw-R_sfY1VgMXUYEkwzpPvrzvU>
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, 25 May 2020 02:33:24 -0000

George,

Thanks for your comments.

I comprehend your concern is about the authenticity of the SLURM file provider.

In RUSH exchange, SLURM file receiver chooses SLURM file sender as its Local Trust Anchor at its discretion.

I agree with your statement that RUSH can work well within IGP as this document says:

"The primary use of RUSH is to distribute RPKI validated cache within an ISP or an ICP composed of a number of ASes.  "

And maybe there is a usecase as described in this document:

"A small site or enterprise network MAY also use RUSH by synchronizing with a third-party RPKI cache provider over networks.”

In short RUSH is intended to make use of SLURM Filters to do subtraction and SLURM Assertions to do addition, in order to keep two cache synchronized.

And the trust in SLURM file sender is configured by  SLURM file receiver out-of-band and can be verified during HTTPS exchange.

I think  RUSH can work well for 'SLURM for AS0 from the RIR’  :-)

Di


> 2020年5月25日 08:18,George Michaelson <ggm@algebras.org> 写道:
> 
> I think its useful to document use of secured transport to fetch data.
> 
> The problem I retain in this, is the lack of strong cryptographic
> validity checks on the semantic intent of the assertions themselves.
> 
> The beauty of RPKI was always the ability to demonstrate the binding
> of authority (delegated) to say what was to be done with some
> resource.
> 
> SLURM doesn't honour that behaviour. Inside your own IGP, its a
> representation of your 'must-haves' including other peoples things,
> but between IGPs, transferred over the external boundary, I worry a
> LOT about "what it means"
> 
> And that goes for 'SLURM for AS0 from the RIR too' btw.
> 
> -G
> 
> On Wed, May 20, 2020 at 3:32 PM Di Ma <madi@rpstir.net> wrote:
>> 
>> Hi, folks
>> 
>> I briefed a method for RPKI inter-cache synchronization called Distributing RPKI Validated Cache in JSON over HTTPS and our implementation with RPSTIR2 in IETF 106 Singapore meeting.
>> 
>> After that we were drafting a document that tries to specify the standardized way to do so, as I promised :-)
>> 
>> We realized that the document should focus on the necessary minimum information for data exchange not the detailed interaction and signaling which I believe can leave to different private implementations.
>> 
>> This document is therefore intended to define a method for transferring RPKI validated cache by making use of SLURM.
>> 
>> Looking forwards to your comments.
>> 
>> https://datatracker.ietf.org/doc/draft-madi-sidrops-rush/
>> 
>> Di
>> 
>> 
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops