[Sidrops] Benjamin Kaduk's Discuss on draft-ietf-sidrops-lta-use-cases-06: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 02 May 2019 01:41 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: sidrops@ietf.org
Delivered-To: sidrops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A93DE120149; Wed, 1 May 2019 18:41:04 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sidrops-lta-use-cases@ietf.org, Chris Morrow <morrowc@ops-netman.net>, sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <155676126468.2640.12123560027176038171.idtracker@ietfa.amsl.com>
Date: Wed, 01 May 2019 18:41:04 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Giwg7nmGaAqiZjnvlI7wVKCnmd4>
Subject: [Sidrops] Benjamin Kaduk's Discuss on draft-ietf-sidrops-lta-use-cases-06: (with DISCUSS and COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
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, 02 May 2019 01:41:05 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-sidrops-lta-use-cases-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have strong misgivings about publishing this document in its current form. The review comment on its predecessor in sidr, "it is written like af able, not an RFC" really sticks with me, and while the style plays a role in my misgivings, I think there are some substantive concerns in play as well. I agree with Roman that there is strong qualitative overlap with situations like TLS MiTM, akin to a violation of the end-to-end principle. I also agree with Mirja that "re-routing to acceptable content" is questionable, and smacks of endorsing censorship. (And yes, I know that one person's censorship is another's parental controls.) My main concern, though, seems to be that this document presents a narrow slice of a broad issue, and does not lay clear the technical facts of the broader situation. Specifically, it lays out some examples where some parties may believe that it is desired to inject additional local information into a local view of the RPKI (or, roughly equivalently, to suppress such information). There are important details about what the two "local"s mean, who is authorized to impose such additional information, etc., but I think it is possible to write a useful document that does not reach a clearn answer on any of those questions. To be useful, though, we need to consider the consequences of having the capability to perform such local injection. There is new attack surface that must be protected from network attack, and a need for permissions/consent (contractual or otherwise) for the systems that are affected by the local view of the RPKI to trust the party/parties that are injecting the local view. Furthermore, there is a sizeable chance that the technical solutions to resolve these use cases will be technically unconstrained, allowing for the "local view" to fully override any and all of the RPKI, so the risk of granting such consent is potentially quite sizeable. I'm also a little concerned about the level of review that this document received; the responsible AD had to send it back to the WG once due to lack of evidence for consensus (https://mailarchive.ietf.org/arch/msg/sidrops/5IBDpQZdsqJeYrxIsSI37c8QxRw), and I did not see a great deal of additional feedback after that. (Perhaps I was looking in the wrong place?) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Abstract The phrasing "needs to" is very strong and implies that there is an absolute judgment that can be made as to the validity of the operation, when my impression is that the topic remains rather controversial. The wording "will want to" used in the Introduction seems to be more accurate. (The word "critical" in "critical circumstances", present in both Abstract and Introduction, is also prone to criticisms of hyperbolism.) Section 1 This document attempts to lay out a few of those use cases. It is not intended to be authoritative, complete, or to become a standard. It is informative laying out a few critical examples to help frame the issues. I appreciate that this document does not intend to be authoritative or complete. But to say that it is "help[ing] frame the issues" borders on irresponsible -- it presents *a* framing in which these use cases are cast favorably, but (per the Discuss point) does not include in that framing some significant points that cause the use cases to be cast less favorably. Section 4 Carol, a resource holder (Local Internet Registry (LIR), Provider Independent address space (PI) holder, ...), operates outside of the country in which her Regional Internet Registry (RIR) is based. Is "legal jurisdiction" more on topic than "country", for the purposes of this example? Someone convinces the RIR's local court to force the RIR to remove or modify some or all of Carol's certificates, ROAs, etc. or the resources they represent, and the operational community wants to retain the ability to route to Carol's network(s). [...] It seems unlikely to me that this is a matter on which the operational community would achieve full consensus. Perhaps "a subset of" is appropriate? Alice is responsible for the trusted routing for a large organization, commercial or geo-political, in which management requests routing engineering to redirect their competitors' prefixes to socially acceptable data. [...] Both "competitors' prefixes" and "socially acceptable" have been mentioned already as potentially problematic phrasing, IIRC, but I will mention them again. (Also, I don't really understand what "geo-political organization" is intended to mean, but maybe that's just as well.) Section 5 One wants to reproduce only as much of the Global RPKI as needed. Replicating more than is needed would amplify tracking and maintenance. The text would probably benefit from a bit more about what is being tracked and by whom. (I assume it is not users being tracked by a surveilance state, though I can't quite exclude that possibility given just the text at hand.) One can not reissue down from the root trust anchor at the IANA or from the RIRs' certificates because one does not have the private keys required. So one has to create a new trust anchor which, for ease of use, will contain the new/modified certificates and ROAs as well as the unmodified remainder of the Global RPKI. I'm not really sure what sense "trust anchor" is being used in, here. It does not seem to match up with the one described in Section 2.4 of RFC 6480, for example. Because Alice, Bob, and Carol want to be able to archive, reproduce, and send to other operators the data necessary to reproduce their modified view of the global RPKI, there will need to be a formally defined set of data which is input to a well-defined process to take an existing Global RPKI tree and produce the desired modified re- anchored tree. This feels very incompletely described. (Yes, I know, "not intended to be complete". But there's a level of incompleteness that seems to not be worth publishing, and we may be close to it.) I also don't have a great sense of whether there's supposed to be a single "re-anchored tree" or a forest of trees, and whether the full global RPKI tree is a subtree of this re-anchored tree, or a replacement/copied version is present therein. Simplified Local Internet Number Resource Management with the RPKI (SLURM), [RFC8416], addresses many, but not all, of these issues and approaches. This document was originally a gating requirements document for SLURM and other approaches. The phrasing of this last sentence feels very unusual to me for an archival document. Section 6 "patching of trust" seems like a phrase without a clear meaning. Though, a large part of that is probably because "trust" itself is so hard to nail down... Modification 'recipes' may lack authentication. E.g., if modifications to the tree are passed around a la SLURM files, see [RFC8416], what was object security becomes, at best, transport security, or authentication by other trust domains such as PGP. Expounding on this with a couple more sentences would probably be worth the effort.
- [Sidrops] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk via Datatracker