Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th)

Di Ma <> Wed, 18 November 2020 06:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A162B3A0BB2; Tue, 17 Nov 2020 22:48:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wma5Vzw-t8W5; Tue, 17 Nov 2020 22:48:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61B833A0BA4; Tue, 17 Nov 2020 22:48:41 -0800 (PST)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.1863876|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.519537-0.025402-0.455061; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047194;; NM=1; PH=DS; RN=8; RT=8; SR=0; TI=SMTPD_---.IyCGFKu_1605682113;
Received: from fp:SMTPD_---.IyCGFKu_1605682113) by; Wed, 18 Nov 2020 14:48:34 +0800
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Di Ma <>
In-Reply-To: <>
Date: Wed, 18 Nov 2020 14:48:33 +0800
Cc: Chris Morrow <>, "" <>, Guyunan <>, SIDR Operations WG <>, SIDROps Chairs <>, Melchior Aelmans <>, Christopher Morrow <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Job Snijders <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Nov 2020 06:48:51 -0000


> 2020年11月17日 22:05,Job Snijders <> 写道:
> On Tue, Nov 17, 2020 at 11:59:13AM +0000, Chris Morrow wrote:
>> Can job speak up if their concerns are NOT met at this time?
>> If they don't speak up in an hour I think we can consider this adopted
>> and ask the authors to submit the appropriately re-named draft :)
> Eh.... a new IETF rule? :-)
> I am not a fan of adopting this draft, I think the working this working
> group's sparse resources should be allocated towards other work. In the
> operational field, people have been transporting SLURM files for years
> over HTTPS, SSH, whatever is suitable. It seems awkward to describe that
> a SLURM file can be transported over HTTPS... it seems ...  obvious?

Happy to know people have been transporting SLURM files, which makes it necessary to standardize RUSH for inter-operation.

I think this argument of yours is a kinda support for adoption of RUSH not the other way around.

> The security section of RFC 8416 already establishes "Additionally, each
> RP using SLURM MUST ensure the authenticity and integrity of any SLURM
> file that it uses." The described use-cases erode potential security,
> specifically:
>    "A small site or enterprise network MAY also use RUSH by
>    synchronizing with a third-party RPKI cache provider over external
>    networks."
> Who are those small networks? Are the authors attempting to speak for a
> silent majority? As far as I know small networks have just as much
> access to tools to validate RPKI data as big networks. What even *is* a
> 'small' network? Seems pedantic to a-priori diminish/downgrade a small
> network's access to secure routing by suggesting they should use an
> inferior substitute instead of the real thing, when everyone knows you
> can run a RPKI validator on a raspberry pi or smaller.

We don’t make decision for operators but offer them a choice that they can outsource valiation if they have no problem with this fashion.

> Furthermore I do not believe that the SLURM format is optimal to
> distribute Validated RPKI cache data. It is inefficient from a size
> perspective. The SLURM format makes a lot of sense for describing 'Local
> RPKI exceptions', but the datastructure seems less suitable as the RPKI
> grows in size.

I don’t agree in terms of SIZE.

The beauty of SLURM file is that it naturally supports incremental update.

> Many operators *already today* are using different formats, so why not
> either look to standardize the format that actually is in use in the
> wild, or optimize towards something that is better than what is already
> used in the wild?

I am pleased to know those operators have *already today* used some other formats that works for their networking condition.

If they want a standardized format, it is fine and good.  But this won’t necessarily stop RUSH from being a WG item.