Session Router 1.0.2

Session Router 1.0.2

This is the first significant release for Session Router since launching it a month ago. In that time we have made significant improvements to the release, bring new features and capabilities to the Session Router network.

This release still remains optional: service nodes can remain on the 11.5.0 oxen-core release for the time being without requiring Session Router. A future 11.7.0 oxen-core update will make Session router mandatory for all Service Nodes.

We encourage all Session Node operators (but especially those who have already upgraded to the Oxen 10.6 release with Session Router 1.0.0 or 1.0.1) to install this update and report any issues or feedback to us.

At this time we still do not recommend client-side reliance on Session Router; there may still be breaking changes for clients as we continue to building Session Router functionality.

Upgrading

As usual, upgrades for Debian 11+ and Ubuntu 22.04+ are available from our APT repository. Static binaries for Linux/amd64 for users looking to run this via a static are available below.

Relay-affecting changes:

• Session Router now uses IPv6 connectivity for internal, tunneled traffic (i.e. for traffic from a client or application to the relay itself). While IPv4 is still supported, most internal network (i.e. non-exit) connections going forward will be over IPv6, which avoids issues like potential tunnel IP exhaustion. This change should not require any changes on the part of operators: session-router will look for and use both a free /16 IPv4 range and a free /64 range with prefix fd2e:7365:7368::. Previously only the IPv4 range was used.

• Support for some older, no-longer-relevant old Lokinet config options have been removed. In most cases this will not matter, but if an operator manually tried copying an old Lokinet config into the Session Router config location then the options may be invalid.

• Session Router now comes with a separate binary, session-router-config, that handles config file generation and (new) keyfile generation. Previously config generation happened via the main session-router binary, but that is now removed in favour of the dedicated script. This script is considerably more capable than the old generation mechanism and is now used automatically during installation (but can also be used separately, particularly for clients; see below).

• Fixed a bug where a configuration containing [bind] listen=:12345 combined with [network] public-ip/public-port settings could crash the relay during startup.

• Fixed a bug where relays would stay connected indefinitely to other relays that deregister. While maintaining these connections does not cause any issues (aside from a tiny bit of traffic to maintain the connection), they are not needed: they are now dropped after about 20 minutes (to allow time for any clients that might still be going through them on existing paths to migrate away to other paths).

• Fixed an issue where new Session Router installations could end up in a situation where they can't properly get onto the network. (An update with this fix was already released as version 1.0.1) .

Client-specific changes:

• IPv6 internal network connectivity (see above).

  • IPv6 addresses on the tun device now use an address based on the remote pubkey, if not already used. For example, a session established to relay decaf20025ca6389... would use local tun IPv6 address fd2e:7365:7368::deca:f200:25ca:6389 (with the default IPv6 address range). In case of collisions (i.e. two different pubkeys with the same prefix) allocation falls back to unused, sequential allocation, similar to IPv4 allocation.

• Dedicated config generator (see above).

  • In addition to the capabilities that were already present, this script now also has the ability to generate a client config that is tailored for use as a hidden service client (i.e. a client typically installed on a server that is meant to receive incoming connections from other clients rather than making outgoing connections). In contrast to a regular client, this enables more inbound paths, disables DNS, and configures Session Router to use a persistent keyfile.
  • This script can also generate or show the pubkeys from keyfiles.

• Complete overhaul of the DNS subsystem:

  • DNS now support EDNS which is used when available by most DNS subsystems. Among other things, this allows larger answer support for UDP queries.
  • DNS name compression for smaller answer response sizes
  • EDNS cookie support
  • Session Router now supports DNS queries over TCP. DNS is structured to make a request over UDP first, and when the response is too large, the server is meant to return a truncation bit so that the client retries over TCP (which supports much larger requests). Old Lokinet DNS did not support TCP requests at all, and so DNS requests for unusually large records would simply fail or timeout.
  • Various fixes to how Session Router names are handled and returned. Old Lokinet DNS worked most of the time, but was sending non-standard responses (such as including extra, unrequested answers) in various cases that could cause problems with clients depending on how the requesting software dealt with such responses.
  • Changed the default notation of client public keys to "fullpubkey.sesh" instead of "fullpubkey.loki". fullpubkey.loki still resolves, but is now a CNAME (i.e. DNS alias) for fullpubkey.sesh. Existing ONS names still use the .loki TLD. (short .sesh names are currently reserved and may become a new namespace separate from .loki when SNS launches).
  • Fixed ONS (.loki) name lookups, which were broken somewhere along the line in the Session Router rewrite.
  • ONS lookups are now cached for 5 minutes; previously we would frequently repeat the lookup, but that was wasteful and really isn't needed for ONS.
  • Fixes SRV record updates
  • drop Session Router MX record (mail server) support. They were added early on in Lokinet as wishful thinking but never had a practical purpose.
  • Improve libunbound usage for upstream requests

• Updated how client contact (CC) fetching works to resolve issues with it:

  • We now always initiate 4 fetches, with each fetch requesting a different "ideal position" slot, to align with CC publishing storing the CC in the best-4 positions. (Fetching from all 4 is important as it means we are robust to publish location changes caused by relays entering or exiting the network).
  • Add a cooldown after CC fetch failures to reduce excessive network lookup requests.

• Relay Contact fetching for clients is now more robust with a "bucketing diff" approach that reduces bandwidth requirements while still being fairly responsive to network RC changes.

• Overhaul internal clock representation when dealing with network times (such as path expiries) to avoid problems where the local clock value would start deviating if the system went to sleep, or after a system clock adjustment (for example, via time server adjustment). Previously (i.e. in stable Lokinet) such clock drift could and would cause serious connectivity problems.

• Fix some false-positive warnings about failed path build attempts during very early startup, i.e. before Session Router is sufficiently connected to build paths.