Re: [Sidrops] feedback on draft-michaelson-rpki-rta

Di Ma <madi@zdns.cn> Fri, 05 February 2021 05:13 UTC

Return-Path: <madi@zdns.cn>
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 AE1913A0CC7 for <sidrops@ietfa.amsl.com>; Thu, 4 Feb 2021 21:13:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 taPWku06djZe for <sidrops@ietfa.amsl.com>; Thu, 4 Feb 2021 21:13:18 -0800 (PST)
Received: from smtpbgeu2.qq.com (smtpbgeu2.qq.com [18.194.254.142]) (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 97F3B3A1BFD for <sidrops@ietf.org>; Thu, 4 Feb 2021 21:13:17 -0800 (PST)
X-QQ-mid: bizesmtp23t1612501988tpodhl2d
Received: from [192.168.218.230] (unknown [202.173.9.210]) by esmtp6.qq.com (ESMTP) with id ; Fri, 05 Feb 2021 13:13:07 +0800 (CST)
X-QQ-SSF: 00400000002000Z0Z000000A0000000
X-QQ-FEAT: sj2Ih1w5Qj8dXP6xgYXqehF+553hYit8bQI6bPuFV84ktD/xQM8Ds1V6TXN8V 174kSpU/VAP25Ohw0Kx1ZqSdvvFQt4SS62XEOLn0rmEe4jWrFOpe0w0lMK/xUBnLzc8lHUs 8l35AI0jr0t8In1hz4veg7Dr/d8YLruKG8WHdmlAaorqfSvDQaOXhXRPEFOnEGnEbQ2pu4f GmGN+xaNC0cjlrTkgRte5aGN/XaTMWuntY4uSMnvRF3IppCEXn7+duk/wg8Alse71hLGeUl qxPy+Gc0eX0U/ArrCW0UoF+MI51ISQJB2z2jUploiqbs8+OnTbyUNd85q4H0XkojCTMnh92 Bl2HO3RG7/f1T5nM26e23857a8UxbyzsqqPyhsFXdK7SGOM9AU=
X-QQ-GoodBg: 2
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
From: Di Ma <madi@zdns.cn>
In-Reply-To: <20210202175608.0e8a58cb@glaurung.nlnetlabs.nl>
Date: Fri, 5 Feb 2021 13:13:03 +0800
Cc: Job Snijders <job=40fastly.com@dmarc.ietf.org>, sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B9856600-5B5C-4C42-BE47-EDD928C18360@zdns.cn>
References: <20201229101412.GA56136@diehard.n-r-g.com> <X+scpsd6kDQ72nLa@bench.sobornost.net> <49a8e314-7b3f-0e8d-6e20-7d055fb1a076@verizon.net> <20201229151639.GD56136@diehard.n-r-g.com> <X+tR06kF3aPZ4+18@bench.sobornost.net> <20201230144836.ytg4u2gobkv4uzqn@benm-laptop> <3BA339C3-EADC-449E-B5B2-7A4880E16EDA@nlnetlabs.nl> <20210112145800.nocjbd4millmbx4i@benm-laptop> <X/31sdsc/ZzGDsjf@bench.sobornost.net> <CAKr6gn3z_N=xGbScwe3xTUxbqWwySwAkncSbm0KKyDZjwVucOA@mail.gmail.com> <YBl2TH9FiBf6iKFt@snel> <20210202175608.0e8a58cb@glaurung.nlnetlabs.nl>
To: Martin Hoffmann <martin@nlnetlabs.nl>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
X-QQ-SENDSIZE: 520
Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign5
X-QQ-Bgrelay: 1
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/loFx6IbNMTuZwaCuZZjgt8_3qhA>
Subject: Re: [Sidrops] feedback on draft-michaelson-rpki-rta
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: Fri, 05 Feb 2021 05:13:25 -0000

Based our experience of evolving and operating RPSITR2, I don’t really think multiple signatures on RTA is good idea as per current RPKI repository architecture. It will bring about complexity to RP’s validation algorithm.

Through a separate system that RPs achieve RTAs could be an option.

Di

> 2021年2月3日 00:56,Martin Hoffmann <martin@nlnetlabs.nl> 写道:
> 
> Job Snijders wrote:
>> 
>> I've consulted with various subject matter experts, and at George's
>> request I again reconsidered. Unfortunately I could not arrive at a
>> different conclusion about the current RTA proposal, it is too
>> complicated for me to support.
> 
> There’s a detail I would like to point out: You can only use the
> existing software more or less unchanged if you distribute RTAs through
> the regular RPKI repository system. I think doing so is a bad idea
> for two reasons.
> 
> For one, an RTA is an exchange between a very small number of
> participants -- typically just two --, but distribution via the RPKI
> repository system results in every single relying party having to
> downloading the object. That strikes me as rather wasteful. At the very
> least relying parties need to download the object and calculate a hash
> over them to determine whether the manifest is valid. Every one needs
> to do that. Yet only really one or two parties actually care.
> 
> Second, distribution through the RPKI repository is actually quite
> cumbersome as it involves a kind of break of gauge: You exchange
> documents in whatever way you choose (likely some kind of HTTP API) but
> then have to stop, fire up an RPKI relying party tool and wait until it
> sees the promised object. Because there uncertainties in timing of RPKI
> publication, you need to be prepared to wait for quite a bit.
> 
> If, conversely, the RTA can be distributed by any other means, i.e., it
> is just a file, it can be transferred as part of your document
> exchange. Bundle it with your document for automated processing or
> upload it manually via a browser. No waiting involved: both parties
> know that the RTA has been transmitted.
> 
> But if you allow that, you can’t use RFC 6488 signed objects anymore --
> or, well, not properly since at the very least you don’t have the a
> signedObject SIA rsync URI anymore. (And yes, the current draft glances
> over this fact.)
> 
> So, if you have to change your code anyway, why not allow it to deal
> with a legitimate, existing use case?
> 
> In addition to allow multiple signatures, the draft also allows the
> signer to include all necessary certificates and CRLs so that for
> validation you wouldn’t even need to access the RPKI repository system
> at all. Needless to say, doing that requires quite a bit of different
> code but, I do believe that this is worth it, as it seriously
> streamlines any process that involves validating RTAs as it can now be
> done in a library pretty much without keeping state.  
> 
>  - Martin
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops