Re: [sidr] Time frame for changing RPSTIR to the new validation algorithm

Tim Bruijnzeels <> Tue, 09 August 2016 11:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EAA1112D7AA for <>; Tue, 9 Aug 2016 04:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2hie-fbu82j5 for <>; Tue, 9 Aug 2016 04:51:00 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC21C12D5A5 for <>; Tue, 9 Aug 2016 04:50:59 -0700 (PDT)
Received: from ([]) by with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <>) id 1bX5Yd-000A69-MP; Tue, 09 Aug 2016 13:50:56 +0200
Received: from ([] by with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <>) id 1bX5Yd-0000Os-Hd; Tue, 09 Aug 2016 13:50:55 +0200
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset="utf-8"
From: Tim Bruijnzeels <>
In-Reply-To: <>
Date: Tue, 09 Aug 2016 13:50:55 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Declan Ma <>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: ---------
X-RIPE-Spam-Report: Spam Total Points: -9.8 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07198aa1230e333d15c65cd425d833f770c5
Archived-At: <>
Cc: sidr <>
Subject: Re: [sidr] Time frame for changing RPSTIR to the new validation algorithm
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Aug 2016 11:51:02 -0000


I am still working on an update to the document.

It's encouraging to hear that another group is looking at maintaining RPSTIR. When I discussed the 6 months with Rob we felt that this should be doable (he can correct me if I am wrong). In our case we have had a working implementation of the algorithm for quite some time, and those changes by themselves are not hard. With the new OIDs we do need to change some things around - making this dependent on OIDs rather than a local configuration setting, but it's not a big deal.

I think it's reasonable that the ability to update implementations from both RP implementations and CA implementations should factor in to a mandatory to implement time frame for RPs, and later CAs. But I also believe that we should be somewhat ambitious, especially w.r.t. RPs because their implementation is on the critical path. CAs can only start to publish when RPs support this.


> On 08 Aug 2016, at 16:54, Declan Ma <> wrote:
> Folks,
> I recall Tim has suggested a schedule for transition to the new validation algorithm during Berlin meeting. His proposal is to mandate RP support for the new all 6 months after the doc is published as an RFC.
> My team is now responsible for RPSTIR update. 
> I am afraid that the proposal is sorta aggressive. IMHO, six-months after publication of the RFC may be too soon. Although this WG has been through discussions of the validation-reconsidered, but the conclusion was just reached. 
> This is really a fundamental change to both RP and CA, I anticipate we need more time to have RP software code changed and thoroughly tested, to accommodate the new validation procedures. 
> Anyway, we are evaluating the time frame,trying to give absolute dates as soon as possible.
> BTW, OID issue has not been yet with IANA feedbacks. We can’t be sure how long it will take to go through the IESG approval process, incurring uncertainty. I am not reassured whether it is prudent to get started with RPSTIR update right away.   
> I am therefore looking forwards to seeing more discussions and comments in this thread, especially from other RPKI implementers.
> Di
> _______________________________________________
> sidr mailing list