[sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT)

Terry Manderson <terry.manderson@icann.org> Thu, 31 August 2017 03:29 UTC

Return-Path: <terry.manderson@icann.org>
X-Original-To: sidr@ietf.org
Delivered-To: sidr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E11124207; Wed, 30 Aug 2017 20:29:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Terry Manderson <terry.manderson@icann.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, aretana@cisco.com, Chris Morrow <morrowc@ops-netman.net>, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.59.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150415018168.16876.13029068813873198020.idtracker@ietfa.amsl.com>
Date: Wed, 30 Aug 2017 20:29:41 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/hS4p3wORHb8BYh6kQcdXAQ9gajk>
Subject: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Aug 2017 03:29:42 -0000

Terry Manderson has entered the following ballot position for
draft-ietf-sidr-rpki-validation-reconsidered-08: 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-sidr-rpki-validation-reconsidered/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for considering the stability of the internet's routing system during
administrative changes to resources.

One thing isn't quite clear to me, so I'm balloting this as a DISCUSS with the
plan that a small amount discussion will resolve it.

With the definition of the new validation OID (a idea that I like BTW), at any
stage of the certificate issuance can the validation OID be switched? That is a
TA has a particular OID and down the tree an issued certificate has a different
OID? If that can't happen (and please make that clear in the document) is there
plan to migrate the set of all issued certificates to the new OID? and
deprecate the old OID?

Logically speaking a trust anchor cannot be thought of as over-claiming. (eg
you trust where the self signed cert came from, and its contents) However the
new validation  constructs suggest that a TA can over-claim, but it seems like
there won't be any warning (as the example in S4.3)  to highlight this possible
eventuality when (in the model where all RIRs issue a TA) a resource is
transferred from one RIR to another for the clients use. Is that interpretation
correct? OR does this new model espouse the belief that all RIRs each issue a
TA that covers 0/0 and ::/0 in perpetuity? In that construct does this mean
that RFC6491 should be updated or made historic?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I get the sense that many of the ramifications for this validation change are
yet to be discovered. It worries me that from the shepherd writeup "The
existing CA/RP code implementations will support this once published." What
experiments have been done to identify any gaps and assumptions?