For those who don't follow the [email protected] , the email below is the background for my last email.
BR Yu From: Yu Fu [mailto:[email protected]] Sent: Thursday, September 24, 2015 9:00 AM To: 'Amreesh Phokeer' Cc: '[email protected]' 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 [email protected] -----Original Message----- From: Amreesh Phokeer [mailto:[email protected]] Sent: Wednesday, September 23, 2015 3:03 PM To: Yu Fu Cc: [email protected] 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 <[email protected]> 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 >> >>[email protected] >> >> >> >> >> _______________________________________________ >>sidr mailing list >> [email protected] >>https://www.ietf.org/mailman/listinfo/sidr >>
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
