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

From: Di Ma <[email-masked]>
Date: Wed, 20 May 2020 13:31:54 +0800

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

---

From: George Michaelson <[email-masked]>
Date: Mon, 25 May 2020 10:18:08 +1000

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 <[email-masked]> wrote:
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Di Ma <[email-masked]>
Date: Mon, 25 May 2020 10:32:31 +0800

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 <[email-masked]> 写道：
>

---

From: Di Ma <[email-masked]>
Date: Fri, 29 May 2020 14:52:37 +0800

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 <[email-masked]> 写道：
> 
> George,
>

---

From: Randy Bush <[email-masked]>
Date: Sun, 31 May 2020 01:59:05 -0700

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

---

From: Di Ma <[email-masked]>
Date: Mon, 1 Jun 2020 11:40:38 +0800

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 <[email-masked]> 写道：
> 
> di
>