Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-has-no-identity-01.txt

Ties de Kock <tdekock@ripe.net> Mon, 09 August 2021 07:58 UTC

Return-Path: <tdekock@ripe.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 318B33A07AA for <sidrops@ietfa.amsl.com>; Mon, 9 Aug 2021 00:58:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net
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 UuwaJMXFDncs for <sidrops@ietfa.amsl.com>; Mon, 9 Aug 2021 00:58:31 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 085473A07A5 for <sidrops@ietf.org>; Mon, 9 Aug 2021 00:58:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=weRvQoX7f+QuEs0wZlIGBM/cGP1IX+HGjXR2wO+CeMQ=; b=EZ+6KZ6UBqKyfe1rrmgzcq1R 4uhN0pJCzZhxqst4HpR32IdUHCqTy1jiQWvgI1lXXawse2Ac1MGsfTk3F3be7X/NOmethVg2qvob9 yTaB859NE94Dk4MzlDrfQr/X5A1y2DwtfTs8HpkAk37OXocY6puUkU0WLOn++UQlXru1k+QGrM9mM rmZn/soBsDXyOxWUM2HVfungb9nh+HVCwofBgD078Aj5QJWINMxib8kH70v4vQyPy0a5BVb/raFRC c1++c+7qji+MvAEphhlkfgHP3LNigaNjewyWytxx6LQE6zqdqxUZXzY6h06xTJXKh0kRmkPCtU6go +bBH4+6N3g==;
Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:42326) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mD0B1-000AbX-OB; Mon, 09 Aug 2021 09:58:27 +0200
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1mD0B1-0008Gf-LX; Mon, 09 Aug 2021 09:58:27 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Ties de Kock <tdekock@ripe.net>
In-Reply-To: <m2bl671xbk.wl-randy@psg.com>
Date: Mon, 09 Aug 2021 09:58:27 +0200
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <76BFDB10-2FE5-4FBD-8E16-8104CBE3D86C@ripe.net>
References: <162845509942.28236.7404410032742481217@ietfa.amsl.com> <m2bl671xbk.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1e5d51f837634f2029fddda5063684f02
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/RoSl3lrZLGGZJvORG_JHpYZTW9M>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-has-no-identity-01.txt
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: Mon, 09 Aug 2021 07:58:37 -0000

Hi Randy,

> On 8 Aug 2021, at 22:43, Randy Bush <randy@psg.com> wrote:
> 
> my (always suspect) memory on this one is that, when it was first
> published, there was a lot of discussion exacerbated by some lack of
> clarity.  this was cleaned up when we made clear that we were not
> attacking RTA or RSC, only warning of potential misuse.  so it was
> adopted as a wg document.

First of all: I like the draft and it demonstrates some problem with using the
RPKI for external attestations really well.

> In large organizations, INR management is often compartmentalized
> with no authority over anything beyond dealing with INR registration.
> The INR manager for Bill's Bait and Sushi is unlikely to be
> authorized to conduct bank transactions for BB&S, or even to
> authorize access to BB&S's servers in some colocation facility.

About this paragraph: This may even need to be more specific.

I think that the department performing INR _management_ often may not even have
legal authority to change INR _registration_s. I imagine a department that can
change the data related to the INR registration (“update the ROAs”) but not
manage the INR registration (“garage sale of the IPv4”).

For the latter you (hopefully) need legal signing power.

Kind regards,
Ties