f05c766b07f297da711a5f385ecdbd242a9af0e8 — Aluísio Augusto Silva Gonçalves 3 months ago 49703cc
posts/lri-log-2021w16: New post
1 files changed, 71 insertions(+), 0 deletions(-)

A posts/lri-log-2021w16.md
A posts/lri-log-2021w16.md => posts/lri-log-2021w16.md +71 -0
@@ 0,0 1,71 @@
{"title": "LRI operations report, 2021-W15/2021-W16"
,"date": "2021-04-26 23:50"
,"lang": "en"
,"tags": ["lorkep lri", "dn42", "network", "bgp", "dns", "ipv6", "ssh"]
,"toc": false}

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][oci-ipv6].
The following day, Charybdis was updated to use this native IPv6 support instead of [Hurricane Electric's IPv6 tunnel broker][tunnelbroker] service, which added a good hundred milliseconds of latency to IPv6 packets due to the nearest endpoint being in Miami[^he].

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 `ip6.arpa.` and `in-addr.arpa.`) 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][vault-ssh-certs].

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.

[^he]: It was recently discovered that the closest tunnel endpoint, RTT-wise, is not Miami but New York.

[alternative login flows]: https://smallstep.com/blog/use-ssh-certificates/#an-ideal-ssh-flow
[bird's bgp options]: https://bird.network.cz/?get_doc&v=20&f=bird-6.html#bgp-proto-config
[dn42 registry explorer]: https://explorer.burble.com
[dn42]: https://dn42.dev
[dns root zone api]: https://git.burble.com/burble.dn42/dn42regsrv/src/commit/bd750fccb3e27f78cd63129afa3ce688dbf968f7/API.md#dns-root-zone-api
[dominating set]: https://en.wikipedia.org/wiki/Dominating_set
[icvpn]: https://github.com/freifunk/icvpn-meta/
[neonetwork]: https://neocloud.tw
[oci-ipv6]: https://blogs.oracle.com/cloud-infrastructure/ipv6-on-oracle-cloud-infrastructure
[rfc 4724]: https://www.rfc-editor.org/info/rfc4724
[rfc 5004]: https://www.rfc-editor.org/info/rfc5004
[snowweb]: https://sr.ht/~aasg/snowweb/
[tunnelbroker]: https://tunnelbroker.net/
[vault-ssh-certs]: https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-certificates