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

Tim Bruijnzeels <> Wed, 13 September 2017 14:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15E87133039; Wed, 13 Sep 2017 07:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pxa7e6E5oJ4V; Wed, 13 Sep 2017 07:29:43 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30C7E124239; Wed, 13 Sep 2017 07:29:43 -0700 (PDT)
Received: from ([]) by with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <>) id 1ds8fa-000B4D-RZ; Wed, 13 Sep 2017 16:29:40 +0200
Received: from ([] by with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <>) id 1ds8fa-0004IQ-Nt; Wed, 13 Sep 2017 16:29:38 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Tim Bruijnzeels <>
In-Reply-To: <>
Date: Wed, 13 Sep 2017 16:29:38 +0200
Cc: The IESG <>,,, Chris Morrow <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Terry Manderson <>
X-Mailer: Apple Mail (2.3273)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: -------
X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719b17f30877c0a7e092e10f4f7a8503b39
Archived-At: <>
Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Sep 2017 14:29:45 -0000


My apologies for the delay - I am just back from a late summer holiday.

> On 31 Aug 2017, at 05:29, Terry Manderson <> wrote:
> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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?

As mentioned in the response to Ben Campbell’s discuss, this is theoretically possible.

It was agreed, in my understanding, that deployment would be discussed in sidrops separate from this document, and the choice whether a mix OID deployment is acceptable should be addressed in that discussion.

> 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?

No, the first bullet point under item #7 in section covers TA certificate. If ‘x=1’, this is the first certificate in the tree and its resources are accepted as they appear.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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?

The RIPE NCC RPKI Validator has supported this algorithm since version 2.17 - 3 July 2014 - as a global configuration setting.

In our case the code changes for this were trivial - in supporting the ‘inherit’ case we were already keeping track of resources per certificate in the tree - adding logic to accept the intersection of resources and warn for over-claims instead of reject was therefore very simple. Changing the behaviour to look at the OID of the certificate under inspection instead will be trivial. The difficulty is in accepting the new OIDs in the first place - again trivial from the code perspective but from a deployment perspective demands that users upgrade their software after we release a version with support for it.