[RPKI] Krill 0.8.0-rc1 'Festina Lente' Release Candidate

Tim Bruijnzeels tim at nlnetlabs.nl
Fri Oct 9 20:06:21 UTC 2020


Dear mailing list,

We just made a release candidate for Krill: 0.8.0-rc1 'Festina Lente'

As of now we will use release candidates as part of the Krill release process. If no major issues are found we plan to do the real 0.8.0 release on Monday 19 October 2020. We invite all users to help us test the release candidate, but please do NOT upgrade your production environments until the real release is done!


Public Krill Testbed Service
============================

With this release we have also started to operate a Krill testbed service. The testbed offers both a parent CA and Repository. As such you can just run a Krill instance, on a laptop even, without the need to operate real infrastructure for testing.
 
It allows you to register any resources for your Child CA, allowing you to test with your real resources. Because this testbed uses its own TEST Trust Anchor - ROAs created here will not end up being used by real routers. 

You can find the test service here:
https://testbed.rpki.nlnetlabs.nl/


Installing the Release Candidate
================================

= Cargo

You can install this specific version explicitly using cargo:

  cargo install -f --version 0.8.0-rc1 krill

You will need Rust version 1.42, or above. More information about installing Krill using cargo can be found here:
https://rpki.readthedocs.io/en/latest/krill/install-and-run.html#installing-with-cargo

= Debian

Alternatively you can use our best effort debian packages, but you would need to add the appropriate '-proposed' source to your system to include the release candidate build. Please don't do this on your production system! Details can be found here:

  https://packages.nlnetlabs.nl



New or updated features:
========================

- added detailed ROA suggestions
- warn about ROAs which are too permissive
- support AS0 ROAs (see below!)
- allow aggregation of ROAs to lower the number of objects (threshold 100)
- allow archiving old data in order to save space
- added a best effort recovery in case data on disk is incomplete (e.g. resulting from a full disk)
- better reporting on communication with parents and repository
- re-sync with parents and repository on start-up
- crash in case data cannot be written to disk (prevent inconsistent states)


We want to ask you to test and give us feedback, in particular with regards to ROA suggestions and restrictions:


1) Suggest ROAs

We have added an "Analyse my ROAs" option to the UI which will suggest ROA changes for you based on your current set of ROAs and the announcements seen in BGP.

It is important that you keep in mind that the RIS data may be old (up to 8 hours), incomplete (e.g. does not see your private network), and it may include unwanted announcements done by others - malicious, or more likely unintended. So, make sure that you review carefully before accepting.

In a future release we will have options to use your own BGP information as input and/or add your own private exceptions.


2) Too Permissive ROAs

Krill will now warn if you create ROAs that are too permissive. I.e. they allow more announcements than what is seen in BGP (based on RIPE RIS data for now). For example you might have:

   192.168.0.0/20-24 => 65000

But only announce one of the allowed /24 prefixes. This goes against best practices because by doing this you enable potential hijackers to announce the other /24s and prepend with your ASN. Their announcements would then appear to be RPKI valid.

Because of this Krill will warn you. And, if you use the 'Analyse my ROAs' option it will suggest to replace these ROAs with authorizations for the announcements which are seen in RIS.


3) Prevent redundant ROAs

Krill will not allow the creation of redundant ROAs, or ROAs that would make other ROAs redundant. E.g. if you have a ROA for:
  
   192.168.0.0/20-24 => 65000

Then Krill will not allow you to create the following ROA, because it's already included in the previous authorization.

   192.168.0.0/24 => 65000


4) AS0 ROAs
 
ROAs that use AS0 can be used in the RPKI to indicate that the holder of a prefix does NOT want the prefix to be routed on the global internet. In our understanding this precludes that ROAs for a real ASN for those resources should be made. Krill will therefore refuse to make AS0 ROAs for prefixes already covered by a real ASN ROA, and vice versa. Furthermore the presence of an AS0 ROA implies that announcements for covered prefixes are intentionally RPKI invalid. Therefore Krill will not suggest to authorize such announcements.

On the other hand an argument can be made for for having a default deny-everything AS0 ROA for a big prefix, and then allowing only specific smaller prefixes for certain ASNs.

The use of AS0 ROAs can be complicated. An important thing to keep in mind is that even if you don't want certain prefixes to be routed on the global internet, you may want to route them in your own network or in private peering. Having an AS0 ROA could lead to issues then as routers could drop these routes as "invalid".

Generally speaking we don't mean to recommend the use of AS0 ROAs, but we want to make sure that the Krill suggestions for them are sound. So, please let us know what you think!



Open issues before 0.8.0
========================

The UI still needs translations for the updated pages. We will reach out to our translators and include these in the release. Since text changes will not affect the inner workings of Krill we believe we can do these changes without the need for an additional release candidate cycle. If you want to contribute to the translations please contact us!



Test upgrade an existing installation
=====================================

As said we don't propose that you do the actual upgrade until we have the real release.

However, if you want to test that the upgrade will work on your existing data, you can. We have tested the upgrade ourselves using real world data, but extra assurance can never hurt. In order to do so, do the following:

- copy your production 'data' dir, but
   --> exclude the 'keys' subdirectory
   --> this contains your private keys, don't put them on a test system!
   --> also this ensures that your test system can't communicate with your real parent and repository

- run a test upgrade
   --> set the env variable: KRILL_UPGRADE_ONLY=1
   --> create a config file with:

          data_dir = "<your-copy>"

   --> run your test krill with:

          krill -c <test-config-file>



Happy testing!


On behalf of the NLnet Labs RPKI Team,

Tim





More information about the RPKI mailing list