[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?
- [sidr] Terry Manderson's Discuss on draft-ietf-si… Terry Manderson
- Re: [sidr] Terry Manderson's Discuss on draft-iet… Tim Bruijnzeels
- Re: [sidr] Terry Manderson's Discuss on draft-iet… Tim Bruijnzeels
- Re: [sidr] Terry Manderson's Discuss on draft-iet… Alvaro Retana