Dear list, We released RC6 today with further improvements:
Improved ASPA support ===================== - Do not create ASPA objects without providers #1050 - Updating an existing provider should update AFI limit choice #1055 In 0.13.0-rc4 and earlier it was possible to issue an ASPA object without providers. At the time that we implemented ASPA support, this could have been an authoritative statement by an ASN that it has no transit providers. Since then the IETF seems to have reached consensus that in such cases an ASPA with AS0 as the sole provider should be issued. See section 4 of the ASPA verification draft: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification#name-aspa-registration-recommend Note: if you have an existing ASPA object without providers, then that object will be removed when you upgrade Krill. Furthermore, we have changed the API a bit allowing operators to use "krillc aspas update" even if there is no pre-existing ASPA object for the given customer ASN. The basic idea is that this CLI command will now be idempotent. Operators can just add / remove providers for a customer ASN and then Krill will work out if an ASPA object should be created, updated, or removed (in case there are no remaining providers). For example: adding an existing provider will be a no-op, unless the provider was authorised for one address famility only and is now authorised for the other as well. Similarly, if there is an existing provider for both IPv4 and IPv6, an operator can remove the provider for one address family, and the authorisation for the other will remain. Improved co-hosted CA support ============================= - Trigger sync for local child CA when resources change #1052 Typically, if the parent updates the child's resource entitlements, then the child will not find out until they happen to synchronise with the parent again. This is still true for remote child CAs - there is no notify mechanism in RFC 6492 (Yes, I would like to work on this in future). But, with this change Krill will now notify *local* child CAs immediately. This means that there will be no delay or need for a manual sync from the local child with its parent. Operators can just update the child's resource entitlements in the parent and it will become effective immediately. Please let us know if you have any questions or comments. On behalf of the NLnet Labs RPKI Team, Tim > On 8 May 2023, at 16:39, Tim Bruijnzeels via RPKI <[email protected]> > wrote: > > Dear list, > > We have been testing a number of release candidates for the coming Krill > 0.13.0 release. > > We released 0.13.0-rc4 last Friday (5 May), and we have updated our own > production environment as well as our testbed environment to this new release > candidate. If no issues are found then we plan to release 0.13.0 on Monday 22 > May (two weeks from today). > > = New User Interface > > This release replaces the old 'Lagosta' User Interface code with a new lean > React based implementation. The UI functionality is unchanged for the most > part, except that it is now possible to include a comment for each configured > ROA. If you use Krill's OpenID Connect integration, we kindly ask you to > check that this new UI implementation works as expected. It works in our own > test setup using Keycloak, but we have not been able to test other provider > implementations. > > = ASPA Support > > Starting with this release ASPA support is no longer treated as experimental, > and is now enabled by default. There is no UI support yet, but we hope to add > this in the not-so-distant future. For now, you can use the command line > interface to manage ASPA objects. You can read more about ASPA support here: > https://krill.docs.nlnetlabs.nl/en/0.13.0-rc1/manage-aspas.html > > > = Interoperability > > Two issues were fixed that affect Krill as a child CA under newly tested > parent CAs: > - Ensure that the CSR uses a trailing slash for id-ad-caRepository (#1030) > - Accept id-cert with path len constraints (#966) > > = Trust Anchor > > Furthermore, a lot of changes were done to allow the use of Krill as an RPKI > Trust Anchor (TA). Although most users will not need this, it may be > beneficial to run your own TA for testing. Documentation can be found here: > https://krill.docs.nlnetlabs.nl/en/0.13.0-rc1/trust-anchor.html > > But, note that for simple test setups it may be easier to use Krill in its > Test setup: > https://krill.docs.nlnetlabs.nl/en/0.13.0-rc1/testbed.html > > > Documentation for this release candidate can be found here: > https://krill.docs.nlnetlabs.nl/en/0.13.0-rc1/ > > Full release notes can be found here: > https://github.com/NLnetLabs/krill/releases/tag/v0.13.0-rc4 > > > Please let us know if you have any questions or comments. > > On behalf of the NLnet Labs RPKI Team, > > Tim > -- > RPKI mailing list > [email protected] > https://lists.nlnetlabs.nl/mailman/listinfo/rpki -- RPKI mailing list [email protected] https://lists.nlnetlabs.nl/mailman/listinfo/rpki
