IETF Logo Mail Archive

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

Tim Bruijnzeels <tim@ripe.net> Tue, 09 August 2016 11:51 UTC

Return-Path: <tim@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA1112D7AA for <sidr@ietfa.amsl.com>; Tue, 9 Aug 2016 04:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hie-fbu82j5 for <sidr@ietfa.amsl.com>; Tue, 9 Aug 2016 04:51:00 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [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 ietfa.amsl.com (Postfix) with ESMTPS id CC21C12D5A5 for <sidr@ietf.org>; Tue, 9 Aug 2016 04:50:59 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <tim@ripe.net>) id 1bX5Yd-000A69-MP; Tue, 09 Aug 2016 13:50:56 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-88.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) 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 <tim@ripe.net>
In-Reply-To: <58E87CF4-2694-474F-BD48-DAB6E2BA78E4@zdns.cn>
Date: Tue, 09 Aug 2016 13:50:55 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2338C59A-F77B-4D7C-8B60-B6D577207F71@ripe.net>
References: <58E87CF4-2694-474F-BD48-DAB6E2BA78E4@zdns.cn>
To: Declan Ma <madi@zdns.cn>
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: <https://mailarchive.ietf.org/arch/msg/sidr/0WlU7adsPB1aowWT9_4sNiYEIEk>
Cc: sidr <sidr@ietf.org>
Subject: Re: [sidr] Time frame for changing RPSTIR to the new validation algorithm
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: Tue, 09 Aug 2016 11:51:02 -0000

Hi,

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.

Regards
Tim


> On 08 Aug 2016, at 16:54, Declan Ma <madi@zdns.cn> 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
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

v2.23.0 | Report a Bug | By Email