[sidr] FW: RE: Some test results of ROA issuing for sharing
"Yu Fu" <fuyu@cnnic.cn> Fri, 25 September 2015 01:05 UTC
Return-Path: <fuyu@cnnic.cn>
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 377621B341C for <sidr@ietfa.amsl.com>; Thu, 24 Sep 2015 18:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 bxnw9xJhj-HS for <sidr@ietfa.amsl.com>; Thu, 24 Sep 2015 18:05:46 -0700 (PDT)
Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEDA1B3419 for <sidr@ietf.org>; Thu, 24 Sep 2015 18:05:45 -0700 (PDT)
Received: from LIUXD (unknown [218.241.103.57]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0B5gCjinQRWX9XjAA--.41752S3; Fri, 25 Sep 2015 09:05:38 +0800 (CST)
From: Yu Fu <fuyu@cnnic.cn>
To: sidr@ietf.org
Date: Fri, 25 Sep 2015 09:05:47 +0800
Message-ID: <001601d0f72e$50360c20$f0a22460$@cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01D0F771.5E594C20"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdD2ZGDTol2W+IWCSBi72MQ82hVL/AAyTNPg
Content-Language: zh-cn
X-CM-TRANSID: AQAAf0B5gCjinQRWX9XjAA--.41752S3
X-Coremail-Antispam: 1UD129KBjvJXoWxuw43uF48XFyDZFW8Ar48Xrb_yoWxXFy8pr WftF12ka1xJ3W7Zw1vyw1UZryFvrn2gw4q9rZ8t3y8CF9FkF1ktrWSva1ru34kAFZYgrnx Xr4UG3W7JFWFqaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBqb7Iv0xC_KF4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAY j202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG04xIwI0_Jr0_Gr1l5I 8CrVCF0I0E4I0vr24lYx0E2Ix0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE14v26r1j6r4U McvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Avz4vE14v_KwCF04k20x vY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r106r1rMI8I 3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jr0_JrylIxkGc2Ij64vIr41lIx AIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAI cVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4 A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU8j9aPUUUUU==
X-CM-SenderInfo: pix13q5fqqxugofq/
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/cixYLJqDgHPatBP6jI8j8SpH9d8>
Subject: [sidr] FW: RE: 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 01:05:51 -0000
For those who don't follow the rpki@rpki.net , the email below is the background for my last email. BR Yu From: Yu Fu [mailto:fuyu@cnnic.cn] Sent: Thursday, September 24, 2015 9:00 AM To: 'Amreesh Phokeer' Cc: 'rpki@rpki.net' Subject: RE: [sidr] Some test results of ROA issuing for sharing Hi Amreeshm, >You mean ROA1 will get revoked and ROA2 will be created with the same file name? Because technically a ROA file cannot >just be overwritten as the corresponding hash in the manifest file also needs to get updated. I mean that the ROA2 will be created with another file name but the file of ROA1 was removed in the publication point. Our test steps are as follow: 1) We want to authorize AS9800 to originate IP prefix 203.0.113.0/25. We make the following operations: root@ubuntu:~# cat iana_roa0.csv 203.0.113.0/25 9800 25 root@ubuntu:~# rpkic -i iana load_roa_requests iana_roa0.csv root@ubuntu:~# rpkic -i iana show_published_objects rsync://192.168.137.139/rpki/iana/7CDyjhAzKpcXVdCRpA_qCBE3lsk.crl 2015-09-23T07:53:49Z 14AB8317432E730B1CFFA8E3FD8C4603AA365715 rsync://192.168.137.139/rpki/iana/7CDyjhAzKpcXVdCRpA_qCBE3lsk.mft 2015-09-23T07:53:49Z BC24250BCDB075EFF725F983003A59876A7E677E rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer 2015-09-16T14:53:40Z 7ED92D9F558F8A552D9907833F46C80D3E1D9AFF apnic rsync://192.168.137.139/rpki/iana/6PtU5o7FeV1zLnT7BlyJM6MyLq4.roa 2015-09-23T07:44:04Z A7465C9A0C4463374472E5E53FAE03D51DF55CAC 9800 203.0.113.0/25 root@ubuntu:~# The result is that a ROA(ROA1) was created. Its name is 6PtU5o7FeV1zLnT7BlyJM6MyLq4.roa. 2) Now we want to authorize AS9800 to originate both IP prefix 203.0.113.0/25 and 218.241.104.0/25. We make the following operations: root@ubuntu:~# cat iana_roa1.csv 218.241.104.0/25 9800 25 root@ubuntu:~# rpkic -i iana load_roa_requests iana_roa1.csv root@ubuntu:~# rpkic -i iana show_published_objects rsync://192.168.137.139/rpki/iana/7CDyjhAzKpcXVdCRpA_qCBE3lsk.crl 2015-09-23T07:55:27Z ECD4EE51320979B887396D52404BC7E036FFDC72 rsync://192.168.137.139/rpki/iana/7CDyjhAzKpcXVdCRpA_qCBE3lsk.mft 2015-09-23T07:55:27Z 924B1E6B9C4CF45A8E2550CF7305190475C6974D rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer 2015-09-16T14:53:40Z 7ED92D9F558F8A552D9907833F46C80D3E1D9AFF apnic rsync://192.168.137.139/rpki/iana/eT13ruR4xaPoms3ttYkRUQKMVDU.roa 2015-09-23T07:55:27Z E1BE61DD9C0694C786A7DE9F71325D49A3776319 9800 218.241.104.0/25 root@ubuntu:~# The result is that a new ROA(ROA2) was created. Its name is eT13ruR4xaPoms3ttYkRUQKMVDU.roa. And in the publication point, ROA1(6PtU5o7FeV1zLnT7BlyJM6MyLq4.roa) was removed, and ROA2(eT13ruR4xaPoms3ttYkRUQKMVDU.roa) was added. So we reissue the two ROAs(ROA1 and ROA2) at the same time. root@ubuntu:~# cat iana_roa.csv 203.0.113.0/25 9800 25 218.241.104.0/25 9800 25 root@ubuntu:~# rpkic -i iana load_roa_requests iana_roa.csv root@ubuntu:~# rpkic -i iana show_published_objects rsync://192.168.137.139/rpki/iana/7CDyjhAzKpcXVdCRpA_qCBE3lsk.crl 2015-09-23T08:06:58Z 228E9CB643702BE58227B5795B495F1C45A82941 rsync://192.168.137.139/rpki/iana/7CDyjhAzKpcXVdCRpA_qCBE3lsk.mft 2015-09-23T08:06:58Z AB964FCD54884AB8070B514A40E5A9B11A05E6D2 rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer 2015-09-16T14:53:40Z 7ED92D9F558F8A552D9907833F46C80D3E1D9AFF apnic rsync://192.168.137.139/rpki/iana/mngmwaP0Dcr8DAij-YynIoSCfbM.roa 2015-09-23T08:06:58Z 6FF8701254A601EF83FD1D00B3FF4B01BEDD891B 9800 203.0.113.0/25,218.241.104.0/25 root@ubuntu:~# It seems OK. And the new ROA(mngmwaP0Dcr8DAij-YynIoSCfbM.roa) was added into the publication point. I don't know whether my explain has answer your question? BR Yu ------------------------------------------- Yu Fu fuyu@cnnic.cn -----Original Message----- From: Amreesh Phokeer [mailto:amreesh.phokeer@gmail.com] Sent: Wednesday, September 23, 2015 3:03 PM To: Yu Fu Cc: rpki@rpki.net Subject: Re: [sidr] Some test results of ROA issuing for sharing >Hello Yu, >>The test results show that ROA2 will overwrite the original ROA1 unless reissue the ROA1 again companied with ROA2 at >the same time. >You mean ROA1 will get revoked and ROA2 will be created with the same file name? Because technically a ROA file cannot just be overwritten as the corresponding hash in the manifest file also needs to get updated. >On Wed, Sep 23, 2015 at 5:21 AM, Yu Fu <fuyu@cnnic.cn> wrote: >> Hi all, >> >> >> > >We have done some tests for the ROA issuing based on the software of > >RPKI.NET in our lab. We'd like to share our test results in the > >mailing list for discussion. >> >> >> > >The tests are grouped into three cases: >> >>1) Issue the ROAs for different ASNs in the same file for the same IP >>Prefix: >> >>e.g. AS1->IP Prefix1 >> >> AS2->IP Prefix1 >> >>The test results show that it can issue different ROAs for different >>ASNs in the same file. It will create ROAs separately based on the >>different AS numbers for the same IP Prefix. There is no problem for this case. >> >> >> >>2) Reissue the ROAs for the same ASN repeatedly >> >>e.g. We have issued ROA1 for AS1-> IP Prefix1 five minutes ago >> >> We are issuing ROA2 for AS1->IP Prefix2 now >> >>The test results show that ROA2 will overwrite the original ROA1 >> unless reissue the ROA1 again companied with ROA2 at the same time. >> >> >> >>3) Issue different ROAs for the same AS in a file >> >>e.g. AS1->IP Prefix1 >> >> AS1->IP Prefix2 >> >> The test results show that it will merge these two ROAS into one ROA >> for issuing. There is no problem for this case. >> >> >> >> As the second case is a problem for the ROA issuing, we think it is a >> bug for the software of the RPKI.net or improve the RPKI protocol to >> avoid this problem. >> >>Opinions? Comments are welcome. >> >> >> >> Cheers >> > Yu >> >> ------------------------------------------- >> >>Yu Fu >> >>fuyu@cnnic.cn >> >> >> >> >> _______________________________________________ >>sidr mailing list >> sidr@ietf.org >>https://www.ietf.org/mailman/listinfo/sidr >>