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

Job Snijders <job@ntt.net> Thu, 22 October 2020 16:17 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 65DD73A07E6; Thu, 22 Oct 2020 09:17:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qydYiLdk8l5f; Thu, 22 Oct 2020 09:17:44 -0700 (PDT)
Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [IPv6:2001:418:3ff:110::40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935673A07BD; Thu, 22 Oct 2020 09:17:44 -0700 (PDT)
Received: from bench.sobornost.net (153-vpn.londen03.uk.bb.gin.ntt.net [165.254.197.153]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 2D0F9220171; Thu, 22 Oct 2020 16:17:42 +0000 (UTC)
Received: from localhost (bench.sobornost.net [local]) by bench.sobornost.net (OpenSMTPD) with ESMTPA id 185158b3; Thu, 22 Oct 2020 16:17:40 +0000 (UTC)
Date: Thu, 22 Oct 2020 16:17:40 +0000
From: Job Snijders <job@ntt.net>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
Cc: Christopher Morrow <christopher.morrow@gmail.com>, 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>, Di Ma <madi@rpstir.net>
Message-ID: <20201022161740.GT58295@bench.sobornost.net>
References: <CAL9jLaZAC9soiJKy856dWexjAmh5=brBnnUOrUjeSHLR_CKJTQ@mail.gmail.com> <8B99CEB3-7CBC-4D12-89BB-8AEE65DE63DA@verizon.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8B99CEB3-7CBC-4D12-89BB-8AEE65DE63DA@verizon.net>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Ep5gVRzFPSnWaslweLmga9RBZ8Q>
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: Thu, 22 Oct 2020 16:17:49 -0000

Hi all,

I am hesitant to support adoption as I feel this opens yet another
not-at-all-validated channel into pandora's box. I don't think this
draft in its current form is ready for adoption.

If this work is to proceed, I'd like RUSH to *strictly* limit itself to
transportation of VRPs within a *single* trust domain. If you are not
willing to give the operator of the RUSH endpoint absolute unrestricted
'enable' access on your BGP routers, they are outside your trust domain
and one should not talk RUSH with them.

The offending paragraph is this one:

    "o AS0 SLURM File Delivery The Regional Internet Registries (RIRs)
    need to publish assertions with origin AS0 ([RFC6491]) for all the
    unallocated and unassigned address space (IPv4 and IPv6) for which
    it is the current administrator.  RUSH is able to deliver those
    assertions to RPKI relying parties if so called AS0 SLURM file are
    generated by the RIR."

Here is an *explicit* example of the detrimental effects of so-called
RIR 'AS 0' policies https://www.ripe.net/ripe/mail/archives/routing-wg/2020-June/004131.html
Do we really want to create big red buttons that can be pressed to nuke
*countries* off the global Internet Routing system? Surely that is not
our intention. I'm a pacifist, I do believe that if we don't develop
machine guns, machine guns can't be used against other human beings.

If RUSH is positioned akin to IBGP, RTR or IGP (OSPF/ISIS) - something
that in the general Internet routing use case is *not* something you'd
set up with a third party (like an RIR), the specification can perhaps
be morphed into something that is useful.

However, if we zoom in on the contents of the draft, it really is just
"SLURM over HTTP" ... and I am not sure whether it is worth
standardizing that a RFC 8416 file can be put on a HTTP server. Will the
next Internet-Draft be that a SLURM file can also be transported over
SSH? This Internet-Draft (to me) doesn't read as a novel specification,
and given the use cases that it includes (which I find problematic) I am
lacking convinction this is the right path forward.

RUSH is not an alternative to signed object security. Object security
based on X.509 (which some painstakingly worked on for a decade!) is a
corner stone of the routing system, we have to be very careful when
specifying things that water it down.

However... there *might* be some work to be done in this area (forgive
me for linking to non-IETF resources, this is not to promote or NIH)
https://github.com/job/draft-sidrops-rpki-vrp-lorri HTMLized version
here
https://htmlpreview.github.io/?https://raw.githubusercontent.com/job/draft-sidrops-rpki-vrp-lorri/master/draft-spaghetti-sidrops-rpki-vrp-lorri-00.html

As it currently stands all RPKI validators are able to emit the VRPs in
a JSON format. This JSON format has become the defacto standard because
each validator blindly copied the other validators. However, the
'commonly used JSON format for VRPs' is not optimal from a data
structure perspective, and it is not standardized (unlike SLURM). There
is no schema, and thus no validation.

In summary:

    * RUSH specifically targets a (IMHO) terrible use case
    * RUSH appears to be "SLURM over HTTP" (doh?)
    * One can argue there is a need to standardize a VRP exchange format
      perhaps based on JSON for archival / intra-domain applications

Kind regards,

Job