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

Claudio Jeker <cjeker@diehard.n-r-g.com> Wed, 18 November 2020 08:26 UTC

Return-Path: <cjeker@diehard.n-r-g.com>
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 6941F3A1669 for <sidrops@ietfa.amsl.com>; Wed, 18 Nov 2020 00:26:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 P--PP21P6WcL for <sidrops@ietfa.amsl.com>; Wed, 18 Nov 2020 00:26:20 -0800 (PST)
Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B536C3A1668 for <sidrops@ietf.org>; Wed, 18 Nov 2020 00:26:18 -0800 (PST)
Received: (qmail 23564 invoked by uid 1000); 18 Nov 2020 08:19:36 -0000
Date: Wed, 18 Nov 2020 09:19:36 +0100
From: Claudio Jeker <cjeker@diehard.n-r-g.com>
To: Di Ma <madi@rpstir.net>
Cc: Job Snijders <job@ntt.net>, SIDROps Chairs <sidrops-chairs@ietf.org>, "sidrops-ads@ietf.org" <sidrops-ads@ietf.org>, Guyunan <guyunan@huawei.com>, SIDR Operations WG <sidrops@ietf.org>, Chris Morrow <morrowc@ops-netman.net>, Melchior Aelmans <melchior@aelmans.eu>, Christopher Morrow <christopher.morrow@gmail.com>
Message-ID: <20201118081936.GA75316@diehard.n-r-g.com>
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> <D77FB6ED-2288-4E55-8329-27EC52C8BB37@rpstir.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D77FB6ED-2288-4E55-8329-27EC52C8BB37@rpstir.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/LYicc-8v-8w0aKq9GR7RP6gXHtg>
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 08:26:21 -0000

On Wed, Nov 18, 2020 at 02:48:33PM +0800, Di Ma wrote:
> 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.
> 

Why is file transport an inter-op problem. If the file is copied with scp,
sftp, rcp, rsync, https, http, ftp, USB stick, floppy disk, or using any
combination of those methods is up to the operator and there is no need to
write an RFC about this. Especially since RUSH is not on the same level as
RPKI regarding authenticity validation.

> 
> > 
> > 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.

This is a very bad choice. There is no cryptographic signature in RUSH
that ensures that the provided data is actually authentic and unaltered.
There is no way to verify the data. All the trust is put in HTTPS.
A secure transport layer does not ensure that the file served was
not altered. 

I think this WG is responsible in helping operators to take the right
decision and to make sure that the promise of validated resource
authorization is not watered down.  Because of this I agree with Job that
this draft should not be adopted by this WG.

People should better spend the effort in making the rpki validators as
easy to use and deploy as possible.

> > 
> > 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.  

-- 
:wq Claudio