From ximon at nlnetlabs.nl Fri May 10 09:09:08 2019 From: ximon at nlnetlabs.nl (Ximon Eighteen) Date: Fri, 10 May 2019 11:09:08 +0200 Subject: [RPKI] Gantry: proving the Routinator in the wild Message-ID: <7295dc6a-5722-cc3e-4266-d84145bca043@nlnetlabs.nl> Fellow RPKIers, I'd like to introduce you to Gantry[0]. Gantry is a tool for automating the deployment and integration testing of virtual service routers with supporting components such as the NLnet Labs RPKI tools Routinator[1] and Krill[2]. Gantry is intended initially to answer the question "Does the Routinator work with real routers?". As the NLnet Labs tools evolve so will the need increase to test them against a broader set of real routers and to compare them to similar tools from other providers, and Gantry is intended to support this vision. However, the use cases go beyond that and so the thinking is to make it extensible and to gather feedback from a wider audience such as yourselves. The 0.1-alpha release[3] of Gantry yesterday is integrated with Travis CI to demonstrate how Gantry can automatically deploy Nokia SROS and Juniper VMX virtual service routers to consume VRPs from a Routinator instance and verify that the router VRP set matches that of the Routinator, and then tear everything down when finished. The technology stack is a combination of Docker to run the components, Docker Engine to provision the hosts in the Digital Ocean cloud and Ansible to automate the component configuration and testing. Docker is also used to package the various tools into an easy to use command line tool aka the Gantry CLI. By using router Docker images built by the vrnetlab project[4] we can abstract away the differences in router deployment procedure, and by using Docker Engine the target hosting environment can easily be switched if needed to something other than Digital Ocean. Ansible allows for configuration and testing in parallel of multiple components built upon stock Ansible support for various virtual service routers[6]. We'd love to get your feedback and to get you involved (pull requests welcome!). Please take a look at the GitHub site[0] and the latest Travis CI build result[5], and watch this space for updates! Thanks, Ximon --- [0] https://github.com/NLnetLabs/gantry/ [1] https://www.nlnetlabs.nl/projects/rpki/routinator/ [2] https://www.nlnetlabs.nl/projects/rpki/krill/ [3] https://github.com/NLnetLabs/gantry/releases/tag/v0.1-alpha [4] https://github.com/plajjan/vrnetlab/ [5] https://travis-ci.com/NLnetLabs/gantry/ [6] https://docs.ansible.com/ansible/latest/network/user_guide/index.html#network-advanced From stavros.konstantaras at ams-ix.net Fri May 10 10:37:13 2019 From: stavros.konstantaras at ams-ix.net (Stavros Konstantaras) Date: Fri, 10 May 2019 12:37:13 +0200 Subject: [RPKI] Routinator runs on AMS-IX Message-ID: Dear RPKI community, Via this e-mail I would like to let you know that since yesterday afternoon, Routinator is running officially in our platform. With the recent instabilities of the RIPE?s RPKI validator (ver. 2.25) in our infrastructure, we decided to speed up the deployment of Routinator and have both validators run in parallel. The workflow we applied is the following: Step 1) Get the ROA dataset from both validators (Routinator and RIPE?s validator) Step 2) Compare the two datasets Step 3) In case of inconsistencies, use the biggest dataset to configure both Route Servers Step 4) Send an e-mail to noc at ams-ix.net for the validator who has inconsistencies. Step 5) Use the selected ROA dataset and proceed with configuring the Route Servers The crucial functionality that helped us integrate the Routinator in our platform fast and easily was the ??listen-http? option and the fact that we can retrieve the ROA dataset in JSON format via the http interface. So, our provisioning scripts use the same code and the changes were minimal. We will keep track of the stability of Routinator and we will report to NLnet LABs team possible issues that might arise, in order to have a great tool serving our needs for long time. Special thanks to Martin Hoffmann for all the insight information he provided to us. Best regards, Stavros Konstantaras | NOC Engineer | AMS-IX M +31 (0) 620 89 51 04 | T +31 20 305 8999 ams-ix.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Fri May 10 11:49:26 2019 From: job at ntt.net (Job Snijders) Date: Fri, 10 May 2019 07:49:26 -0400 Subject: [RPKI] Routinator runs on AMS-IX In-Reply-To: References: Message-ID: Thank you for sharing this information with the community! On Fri, May 10, 2019 at 6:43 Stavros Konstantaras < stavros.konstantaras at ams-ix.net> wrote: > Dear RPKI community, > > Via this e-mail I would like to let you know that since yesterday > afternoon, Routinator is running officially in our platform. With the > recent instabilities of the RIPE?s RPKI validator (ver. 2.25) in our > infrastructure, we decided to speed up the deployment of Routinator and > have both validators run in parallel. The workflow we applied is the > following: > > Step 1) Get the ROA dataset from both validators (Routinator and RIPE?s > validator) > Step 2) Compare the two datasets > Step 3) In case of inconsistencies, use the biggest dataset to configure > both Route Servers > Step 4) Send an e-mail to noc at ams-ix.net for the validator who has > inconsistencies. > Step 5) Use the selected ROA dataset and proceed with configuring the > Route Servers > > The crucial functionality that helped us integrate the Routinator in our > platform fast and easily was the ??listen-http? option and the fact that we > can retrieve the ROA dataset in JSON format via the http interface. So, our > provisioning scripts use the same code and the changes were minimal. > > We will keep track of the stability of Routinator and we will report to > NLnet LABs team possible issues that might arise, in order to have a great > tool serving our needs for long time. > > Special thanks to Martin Hoffmann for all the insight information he > provided to us. > > > > Best regards, > > Stavros Konstantaras | NOC Engineer | AMS-IX > M +31 (0) 620 89 51 04 | T +31 20 305 8999 > ams-ix.net > > -- > RPKI mailing list > RPKI at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/rpki > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mats at exmandato.se Tue May 14 13:33:40 2019 From: mats at exmandato.se (mats at exmandato.se) Date: Tue, 14 May 2019 15:33:40 +0200 Subject: [RPKI] Strange errors In-Reply-To: <9D4B0A0B-85EA-4094-96BE-21EA947DC7B5@exmandato.se> References: <9D4B0A0B-85EA-4094-96BE-21EA947DC7B5@exmandato.se> Message-ID: Hi I found the cause From the source (repository.rs) "/// Note that currently we happily accept stale manifests, i.e., manifests /// whose certificate is still valid but the next_update time has passed. /// The RFC says we need to decide what to do, so this is fine. Sorry for the noice /mm > On 14 May 2019, at 15:21, mats at exmandato.se wrote: > > Hi > > What to do with the following errors (lots of them i loggfile) > > > rsync://rpki.cnnic.cn/rpki/A9162E3D0000/434/vKNmUQM0s3Q9LdxCYyt5dBbI3oU.crl: stale CRL. > rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2100/vhT5zP4zduEf4yGQGFeaI0-cvlI.mft: stale manifest > > All of them refers to rpki.cnnic.cn > > > /mm -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From mats at exmandato.se Tue May 14 13:21:41 2019 From: mats at exmandato.se (mats at exmandato.se) Date: Tue, 14 May 2019 15:21:41 +0200 Subject: [RPKI] Strange errors Message-ID: <9D4B0A0B-85EA-4094-96BE-21EA947DC7B5@exmandato.se> Hi What to do with the following errors (lots of them i loggfile) rsync://rpki.cnnic.cn/rpki/A9162E3D0000/434/vKNmUQM0s3Q9LdxCYyt5dBbI3oU.crl: stale CRL. rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2100/vhT5zP4zduEf4yGQGFeaI0-cvlI.mft: stale manifest All of them refers to rpki.cnnic.cn /mm -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From tim at nlnetlabs.nl Tue May 14 13:58:29 2019 From: tim at nlnetlabs.nl (Tim Bruijnzeels) Date: Tue, 14 May 2019 15:58:29 +0200 Subject: [RPKI] Strange errors In-Reply-To: <9D4B0A0B-85EA-4094-96BE-21EA947DC7B5@exmandato.se> References: <9D4B0A0B-85EA-4094-96BE-21EA947DC7B5@exmandato.se> Message-ID: <7EC0951E-1AC2-47D6-B658-F7F7AFF3CD38@nlnetlabs.nl> Hi Mats, This is caused by an issue at CNNIC regarding updating their CRL and Manifest files (and quite possibly they aren't publishing any new ROAs either). I heard that they have already been contacted about this. If they do not fix the issue, then eventually all of CNNIC's objects will become invalid, meaning that announcements for CNNIC space will become RPKI unknown. Note that if you have an 'rpki invalid == reject' policy, this means these announcements will still be accepted, albeit unprotected by RPKI. There is nothing you are supposed to with these errors, unless you want to reach out to them as well. However, if you should see many connection failures and stale messages like this across the board, then they could indicate that there is a local connectivity issue with your routinator. Tim > On 14 May 2019, at 15:21, mats at exmandato.se wrote: > > Hi > > What to do with the following errors (lots of them i loggfile) > > > rsync://rpki.cnnic.cn/rpki/A9162E3D0000/434/vKNmUQM0s3Q9LdxCYyt5dBbI3oU.crl: stale CRL. > rsync://rpki.cnnic.cn/rpki/A9162E3D0000/2100/vhT5zP4zduEf4yGQGFeaI0-cvlI.mft: stale manifest > > All of them refers to rpki.cnnic.cn > > > /mm > -- > RPKI mailing list > RPKI at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/rpki From md at linux.it Wed May 15 14:51:57 2019 From: md at linux.it (Marco d'Itri) Date: Wed, 15 May 2019 16:51:57 +0200 Subject: [RPKI] Bug#929024: ITP: routinator -- An RPKI Validator In-Reply-To: <20190515132953.GA20331@bongo.bofh.it> References: <20190515132953.GA20331@bongo.bofh.it> Message-ID: <20190515145157.GA31874@bongo.bofh.it> FYI: I have started packaging rpki for Debian. This will take some time since rustc 1.34 is not available yet and it will not be before Debian 10 will have been released (also, I will need to package some missing dependencies). Also, it would be nice if you could update the outdated dependencies on daemonize, base64 and ring. On May 15, Marco d'Itri wrote: > Package: wnpp > Severity: wishlist > Owner: Marco d'Itri > > * Package name : routinator > Version : 0.3.3 > Upstream Author : NLnet Labs > * URL : https://nlnetlabs.nl/rpki > * License : BSD > Programming Lang: Rust > Description : An RPKI Validator > > The Routinator 3000 is an RPKI relying party software: network operators > can configure their BGP-speaking routers to use it to cryptographically > validate the routes received from third parties. > > -- > ciao, > Marco -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From martin at nlnetlabs.nl Wed May 15 15:27:13 2019 From: martin at nlnetlabs.nl (Martin Hoffmann) Date: Wed, 15 May 2019 17:27:13 +0200 Subject: [RPKI] Bug#929024: ITP: routinator -- An RPKI Validator In-Reply-To: <20190515145157.GA31874@bongo.bofh.it> References: <20190515132953.GA20331@bongo.bofh.it> <20190515145157.GA31874@bongo.bofh.it> Message-ID: <20190515172713.438a8322@glaurung.nlnetlabs.nl> Hi Marco, Marco d'Itri wrote: > FYI: I have started packaging rpki for Debian. That is really fantastic! Thank you for doing this! > This will take some > time since rustc 1.34 is not available yet and it will not be before > Debian 10 will have been released (also, I will need to package some > missing dependencies). 0.3.3 should still work with Rust 1.30., we only just switched to 1.34 for the upcoming 0.4 release. But it is of course totally understandable if you'd rather wait. > Also, it would be nice if you could update the outdated dependencies > on daemonize, base64 and ring. Will do as part of the 0.4 releases. Ring is currently stuck in 0.13 because Krill needs some restructuring to allow the update. I also have a systemd unit file for the RTR daemon that I am using somewhere. It?s nothing magic and probably even slightly wrong, but it works and I will push it as well. Kind regards, Martin > > On May 15, Marco d'Itri wrote: > > > Package: wnpp > > Severity: wishlist > > Owner: Marco d'Itri > > > > * Package name : routinator > > Version : 0.3.3 > > Upstream Author : NLnet Labs > > * URL : https://nlnetlabs.nl/rpki > > * License : BSD > > Programming Lang: Rust > > Description : An RPKI Validator > > > > The Routinator 3000 is an RPKI relying party software: network > > operators can configure their BGP-speaking routers to use it to > > cryptographically validate the routes received from third parties. > > > > -- > > ciao, > > Marco > > > From md at linux.it Wed May 15 16:00:31 2019 From: md at linux.it (Marco d'Itri) Date: Wed, 15 May 2019 18:00:31 +0200 Subject: [RPKI] Bug#929024: ITP: routinator -- An RPKI Validator In-Reply-To: <20190515172713.438a8322@glaurung.nlnetlabs.nl> References: <20190515132953.GA20331@bongo.bofh.it> <20190515145157.GA31874@bongo.bofh.it> <20190515172713.438a8322@glaurung.nlnetlabs.nl> Message-ID: <20190515160031.GA1827@bongo.bofh.it> On May 15, Martin Hoffmann wrote: > 0.3.3 should still work with Rust 1.30., we only just switched to 1.34 > for the upcoming 0.4 release. But it is of course totally Cool, I will try. > Will do as part of the 0.4 releases. Ring is currently stuck in 0.13 > because Krill needs some restructuring to allow the update. Will Routinator work at all with the current release? The Debian Rust team really hates obsolete dependencies because they cannot be represented in the archive, so either every package stays behind or every package is patched to support the latest release. > I also have a systemd unit file for the RTR daemon that I am using > somewhere. It?s nothing magic and probably even slightly wrong, but > it works and I will push it as well. I plan to work on this as well. BTW, what do you think about adding support for socket activation using the listenfd crate? This way it would be possible to use port 323 without being root. https://github.com/mitsuhiko/rust-listenfd -- ciao, Marco From martin at nlnetlabs.nl Wed May 15 16:15:30 2019 From: martin at nlnetlabs.nl (Martin Hoffmann) Date: Wed, 15 May 2019 18:15:30 +0200 Subject: [RPKI] Bug#929024: ITP: routinator -- An RPKI Validator In-Reply-To: <20190515160031.GA1827@bongo.bofh.it> References: <20190515132953.GA20331@bongo.bofh.it> <20190515145157.GA31874@bongo.bofh.it> <20190515172713.438a8322@glaurung.nlnetlabs.nl> <20190515160031.GA1827@bongo.bofh.it> Message-ID: <20190515181530.7137ddd7@glaurung.nlnetlabs.nl> Marco d'Itri wrote: > On May 15, Martin Hoffmann wrote: > > > 0.3.3 should still work with Rust 1.30., we only just switched to > > 1.34 for the upcoming 0.4 release. But it is of course totally > Cool, I will try. > > > Will do as part of the 0.4 releases. Ring is currently stuck in 0.13 > > because Krill needs some restructuring to allow the update. > Will Routinator work at all with the current release? Ring should be fine. Base64 has changed and we need some modifications. For daemonize I have to look. That one is new to me ... So maybe it is best if we wait for 0.4 and fix all the dependencies. I guess you don?t want to mess around with patches if you don?t have to. > > I also have a systemd unit file for the RTR daemon that I am using > > somewhere. It?s nothing magic and probably even slightly wrong, but > > it works and I will push it as well. > I plan to work on this as well. > > BTW, what do you think about adding support for socket activation > using the listenfd crate? This way it would be possible to use port > 323 without being root. > > https://github.com/mitsuhiko/rust-listenfd I will have a look and try to get that into 0.4 as well. I made https://github.com/NLnetLabs/routinator/issues/114 so I don?t forget. If there is anything more that would be helpful, let me know! Kind regards, Martin From md at linux.it Wed May 15 16:19:38 2019 From: md at linux.it (Marco d'Itri) Date: Wed, 15 May 2019 18:19:38 +0200 Subject: [RPKI] Bug#929024: ITP: routinator -- An RPKI Validator In-Reply-To: <20190515181530.7137ddd7@glaurung.nlnetlabs.nl> References: <20190515132953.GA20331@bongo.bofh.it> <20190515145157.GA31874@bongo.bofh.it> <20190515172713.438a8322@glaurung.nlnetlabs.nl> <20190515160031.GA1827@bongo.bofh.it> <20190515181530.7137ddd7@glaurung.nlnetlabs.nl> Message-ID: <20190515161938.GA4521@bongo.bofh.it> On May 15, Martin Hoffmann wrote: > So maybe it is best if we wait for 0.4 and fix all the dependencies. I > guess you don?t want to mess around with patches if you don?t have to. For Debian (and Ubuntu) packages this is not an option: either the upstream software supports the crate version currently in the archive, which tends to be the latest one, or else it needs to be patched to support it. Which does not look well right now since this is my first exposure to Rust. :-) -- ciao, Marco From md at linux.it Tue May 21 01:37:36 2019 From: md at linux.it (Marco d'Itri) Date: Tue, 21 May 2019 03:37:36 +0200 Subject: [RPKI] [PATCH] install a systemd unit file Message-ID: <20190521013736.24300-1-md@linux.it> --- Cargo.toml | 1 + etc/routinator.service | 34 ++++++++++++++++++++++++++++++++++ 2 files changed, 35 insertions(+) create mode 100644 etc/routinator.service diff --git a/Cargo.toml b/Cargo.toml index c840565..d2b362a 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -58,6 +58,7 @@ assets = [ ["README.md", "usr/share/doc/routinator/", "644"], ["doc/misc.md", "usr/share/doc/routinator/misc.md", "644"], ["doc/routinator.1", "usr/share/man/man1/routinator.1", "644"], + ["etc/routinator.service", "lib/systemd/system/routinator.service", "644"] ] maintainer-scripts = "debian" diff --git a/etc/routinator.service b/etc/routinator.service new file mode 100644 index 0000000..b9d6e27 --- /dev/null +++ b/etc/routinator.service @@ -0,0 +1,34 @@ +[Unit] +Description=Routinator 3000 +Documentation=man:routinator(1) +After=network.target + +[Service] +ExecStart=/usr/bin/routinator --config=/etc/routinator/routinator.conf --syslog rtrd -a +Type=exec +RestartSec=0 +User=routinator +AmbientCapabilities=CAP_NET_BIND_SERVICE +CapabilityBoundingSet=CAP_NET_BIND_SERVICE +LockPersonality=yes +MemoryDenyWriteExecute=yes +NoNewPrivileges=yes +PrivateDevices=yes +PrivateTmp=yes +ProtectControlGroups=yes +ProtectHome=yes +ProtectKernelModules=yes +ProtectKernelTunables=yes +ProtectSystem=strict +ReadWritePaths=/var/lib/routinator/ +RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 +RestrictNamespaces=yes +RestrictRealtime=yes +StateDirectory=routinator +SystemCallArchitectures=native +SystemCallErrorNumber=EPERM +SystemCallFilter=@system-service + +[Install] +WantedBy=multi-user.target + -- 2.20.1