Re: [sidr] [rpki] Some test results of ROA issuing for sharing
Rob Austein <sra@hactrn.net> Fri, 25 September 2015 06:30 UTC
Return-Path: <sra@hactrn.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8471B36AE for <sidr@ietfa.amsl.com>; Thu, 24 Sep 2015 23:30:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 7hqSjN9xsPxA for <sidr@ietfa.amsl.com>; Thu, 24 Sep 2015 23:30:00 -0700 (PDT)
Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF731B3156 for <sidr@ietf.org>; Thu, 24 Sep 2015 23:29:59 -0700 (PDT)
Received: from minas-ithil.hactrn.net (c-24-34-34-101.hsd1.ma.comcast.net [24.34.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 1E95A6C1F; Fri, 25 Sep 2015 06:29:57 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 7B55F1BB7D60; Fri, 25 Sep 2015 02:29:39 -0400 (EDT)
Date: Fri, 25 Sep 2015 02:29:39 -0400
From: Rob Austein <sra@hactrn.net>
To: Yu Fu <fuyu@cnnic.cn>
In-Reply-To: <001501d0f72d$75e3d980$61ab8c80$@cn>
References: <000001d0f664$612dd320$23897960$@cn> <20150924035853.33CE01BAACCB@minas-ithil.hactrn.net> <001501d0f72d$75e3d980$61ab8c80$@cn>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150925062939.7B55F1BB7D60@minas-ithil.hactrn.net>
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/FalLmKX4Oi0n43j8AanbVLzyFeE>
Cc: rpki@rpki.net, sidr@ietf.org
Subject: Re: [sidr] [rpki] Some test results of ROA issuing for sharing
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 25 Sep 2015 06:30:01 -0000
At Fri, 25 Sep 2015 08:59:41 +0800, Yu Fu wrote: > > We have issued ROA1 for AS1-> IP Prefix1 five minutes ago. Then we want to > issue ROA2 for AS1-> IP Prefix2. As you described below, we need to include > ROA1 in the new set when we are issuing the ROA2. But AS1 has not been > authorized to announce IP prefix2. So we are failed to issue the ROA2. And > the ROA1 are also failed for issuing as together with the ROA2. This will be > a mistake for this use case. Not sure I really understand your question. Taking a guess, you're saying that, when you tried adding a ROA that should fail (because it doesn't have the necessary resources), this somehow broke an existing ROA. That would indeed be a bug, but I tried setting up a regression test for that specific scenario and, as expected, was not able to get it to fail. So I suspect there's something else going on. Note: The sidr@ietf.org list is probably not the correct place to be asking about user interface details of a particular implementation.