Skip to content

Published on by Aluísio Augusto Silva Gonçalves. Filed under lorkep lri, dn42, network, bgp, dns, ipv6, ssh.

LRI operations report, 2021-W15/2021-W16

Table of contents

This is the report for 12–25 April 2021 on the state and activities of the Lorkep Long-Range Interconnect, a virtual network and autonomous system operating on dn42. These two weeks saw improvements in interconnectivity both with the Internet and with other virtual networks.

Writing of the 2021-W15 report was delayed due to the development and deployment of SnowWeb, a webserver for Nix flake–based sites that features remotely-triggered rebuilds/redeployment and site-defined HTTP headers (somewhat akin to Apache’s .htaccess).

Oracle Cloud, IPv6, and Charybdis

On 15 April 2021, Oracle announced general availability of IPv6 in the Oracle Cloud Infrastructure. The following day, Charybdis was updated to use this native IPv6 support instead of Hurricane Electric’s IPv6 tunnel broker service, which added a good hundred milliseconds of latency to IPv6 packets due to the nearest endpoint being in Miami1.

With this, Charybdis has become the second dual-stack node in the LRI, and is now part of the LRI’s dominating set of routers along with Behemoth.

.neo on dn42

NeoNetwork’s DNS root was recently imported into the dn42 registry (via ICVPN), and in the process of adding support to the .neo TLD to dns.lorkep.dn42, it was realized that DNSSEC on reverse DNS records (under and was broken due to missing trust anchors.

Thanks to the DNS Root Zone API of the dn42 Registry Explorer, not only does reverse DNS lookup for dn42 addresses now work on dns.lorkep.dn42, but the Unbound trust anchors and stub zones were updated to enable resolution of all TLDs in dn42, ICVPN, and NeoNetwork space.

BGP updates

Some of the dn42 networks had a bad case of excessive updating last week, which prompted some interesting discussions in the IRC channels. Among those were references to RFC 5004, which changes the BGP best route selection algorithm to prefer an existing route to a new one if it ends up in a tie, thus preventing some kinds of route flapping from propagating through a network. It is controlled by Bird’s prefer older option.

Speaking of those, while reviewing Bird’s BGP options after the release of Bird 2.0.8, the graceful restart set of options implementing RFC 4724 has been discovered. Enabling them will allow routes to survive a momentary BGP daemon restart, which usually happens when new NixOS configurations are activated.

Support for both RFCs had been enabled on some of the LRI routers, with a full rollout expected to happen this week as part of an upgrade to Bird 2.0.8.

SSH certificates

To assist in the initial configuration of new network nodes, SSH host certificates are being trialed on Chernava. SSH certificates eliminate the need to constantly update lists of known hosts and authorized keys by relying on a signature from a trusted key instead. While Lorkep workstations running NixOS have their known_hosts file centrally managed and automatically updated, non-NixOS systems are not well equipped to handle the deployment and decommissioning of LRI nodes.

Based on an existing strategy for mutual TLS authentication, SSH host certificates are short-lived and are constantly renewed, though they are set to last long enough to survive failures in the renewal system. The signing key is managed by a newly provisioned Vault cluster and certificates are signed by Vault’s SSH secrets engine.

It is as of now unclear if this experiment will be extended to include client certificates, but if so the usage of an offline certificate authority is more likely, as there is little need (and large drawbacks) to short-lived certificates in this case, unless alternative login flows are used.

Task list for 2021-W17

  • Complete SSH host certificate deployment once renewal is verified to work correctly.
  • Expand the Vault cluster and study how to make it highly available.
  • Upgrade Bird to 2.0.8 and review the new enforce first as and advertise hostname options.

  1. It was recently discovered that the closest tunnel endpoint, RTT-wise, is not Miami but New York.↩︎

View comments to this post or send your own