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

Job Snijders <job@ntt.net> Tue, 17 November 2020 14:05 UTC

Return-Path: <job@ntt.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 16B733A11EA; Tue, 17 Nov 2020 06:05:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 LHusrkPVMJo3; Tue, 17 Nov 2020 06:05:24 -0800 (PST)
Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [204.2.238.64]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679983A10C5; Tue, 17 Nov 2020 06:05:24 -0800 (PST)
Received: from bench.sobornost.net (mieli.sobornost.net [45.138.228.4]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 3F88F22012F; Tue, 17 Nov 2020 14:05:20 +0000 (UTC)
Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 332763a6; Tue, 17 Nov 2020 14:05:17 +0000 (UTC)
Date: Tue, 17 Nov 2020 14:05:17 +0000
From: Job Snijders <job@ntt.net>
To: Chris Morrow <morrowc@ops-netman.net>
Cc: Di Ma <madi@rpstir.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>
Message-ID: <X7PYnV3pz9QO5NUY@bench.sobornost.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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87a6vgfb3i.wl-morrowc@ops-netman.net>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/WNC0NRMdb4URRVDeHlAKY1RrP70>
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: Tue, 17 Nov 2020 14:05:26 -0000

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?

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.

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.

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?

summary:

    1) SLURM RFC already covers important aspects of SLURM, no novelty
    2) SLURM format seems less suitable than already-deployed JSON formats
    3) Suggestion to research the already-deployed-formats and
       standardize those, or optimize those formats to improve RPKI
       cache distribution.

Kind regards,

Job