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

Di Ma <madi@rpstir.net> Wed, 18 November 2020 06:48 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 A162B3A0BB2; Tue, 17 Nov 2020 22:48:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wma5Vzw-t8W5; Tue, 17 Nov 2020 22:48:48 -0800 (PST)
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 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; MF=madi@rpstir.net; NM=1; PH=DS; RN=8; RT=8; SR=0; TI=SMTPD_---.IyCGFKu_1605682113;
Received: from 172.20.10.2(mailfrom:madi@rpstir.net fp:SMTPD_---.IyCGFKu_1605682113) by smtp.aliyun-inc.com(10.147.41.158); 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.20.0.2.21\))
From: Di Ma <madi@rpstir.net>
In-Reply-To: <X7PYnV3pz9QO5NUY@bench.sobornost.net>
Date: Wed, 18 Nov 2020 14:48:33 +0800
Cc: Chris Morrow <morrowc@ops-netman.net>, "sidrops-ads@ietf.org" <sidrops-ads@ietf.org>, Guyunan <guyunan@huawei.com>, SIDR Operations WG <sidrops@ietf.org>, SIDROps Chairs <sidrops-chairs@ietf.org>, Melchior Aelmans <melchior@aelmans.eu>, Christopher Morrow <christopher.morrow@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D77FB6ED-2288-4E55-8329-27EC52C8BB37@rpstir.net>
References: <87imbybjne.wl-morrowc@ops-netman.net> <CALxNLBhjU409LB8pU3Dr287hyKDSW8bHbJiLNPjf4yOSnzc2kg@mail.gmail.com> <C01B0098369B2D4391851938DA6700B717C1D699@DGGEML532-MBX.china.huawei.com> <C4FE2995-87D4-4FF5-9F3D-91D5BE44ED33@rpstir.net> <CAL9jLaZAC9soiJKy856dWexjAmh5=brBnnUOrUjeSHLR_CKJTQ@mail.gmail.com> <3B7B607B-C100-4805-94BE-DC2F597A3CD2@rpstir.net> <87a6vgfb3i.wl-morrowc@ops-netman.net> <X7PYnV3pz9QO5NUY@bench.sobornost.net>
To: Job Snijders <job@ntt.net>
X-Mailer: Apple Mail (2.3654.20.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/xk6lj7CzgZVbE4nSGwdRgMwv1Eo>
Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th)
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: Wed, 18 Nov 2020 06:48:51 -0000

Job,

> 2020年11月17日 22:05,Job Snijders <job@ntt.net> 写道:
> 
> 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.  

Di