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

Di Ma <madi@rpstir.net> Fri, 29 May 2020 06:52 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 810793A091F for <sidrops@ietfa.amsl.com>; Thu, 28 May 2020 23:52: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 XgkBaXSaHVlk for <sidrops@ietfa.amsl.com>; Thu, 28 May 2020 23:52:51 -0700 (PDT)
Received: from out20-74.mail.aliyun.com (out20-74.mail.aliyun.com [115.124.20.74]) (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 970BB3A0920 for <sidrops@ietf.org>; Thu, 28 May 2020 23:52:48 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.06769614|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.276629-0.0251491-0.698222; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03307; MF=madi@rpstir.net; NM=1; PH=DS; RN=2; RT=2; SR=0; TI=SMTPD_---.HfF8IiV_1590735158;
Received: from 192.168.218.230(mailfrom:madi@rpstir.net fp:SMTPD_---.HfF8IiV_1590735158) by smtp.aliyun-inc.com(10.147.41.137); Fri, 29 May 2020 14:52:39 +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: <D7565F35-4D2A-443B-8568-8C998E6D2521@rpstir.net>
Date: Fri, 29 May 2020 14:52:37 +0800
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E6B0B011-A8D3-44EA-A84D-B1062FBBAB41@rpstir.net>
References: <DADF530A-9285-45C3-B2CA-73B9D8F3ABE7@rpstir.net> <CAKr6gn2xSpNmX6FyFd46xTFv_F5wYOPfg-y62OD2_P1HAw27pQ@mail.gmail.com> <D7565F35-4D2A-443B-8568-8C998E6D2521@rpstir.net>
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/1OpYIfn9rcwJYycESUD3b_oLkCw>
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: Fri, 29 May 2020 06:52:55 -0000

George,

I would like to add some clarifications after I notice you and Randy’s discussions re (SLURM file for Unallocated and Unassigned RIPE NCC Address Space) in RIPE routing WG mailing list.

I think the key point is the scope of the SLURM file receiver.

RUSH is designed to deliver SLURM file (validated cache) to “subscribers” . That is, the scope of RUSH usage is convergent. 

If A subscribes to X for RUSH, A has got a trust in X in terms of authenticity of SLURM file source and data integrity could be therefore protected by HTTPS.

And X is not responsible for Z if A diffuses the very SLURM file to Z which is not a subscriber to X. 

Let me also take the discussion to ROA 0 via SLURM.

ROA 0 information in fact is not LOCAL but global although the policy proposal for RIPE is to make use of SLURM, which is intended to propagate over networks (maybe via CDN).  I guess this is the reason why it causes concerns for ROA 0-SLURM integrity. 

However, I envisage if RIPE make ROA 0 info only available to a convergent scope by employing subscription mechanism via RUSH/web download. 

Di



> 2020年5月25日 10:32,Di Ma <madi@rpstir.net> 写道:
> 
> 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
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops