Appliance Release v0.38¶

This page contains the release notes for the v0.38 Anapaya appliance software release. The appliance software release is applicable for the following Anapaya products:

Anapaya CORE
Anapaya EDGE
Anapaya GATE

We recommend always upgrading to the latest available patch release. Please refer to Upgrade Notes (if any) of each release if there are any special steps to be taken when upgrading. For general information on how to upgrade your appliance, please refer to Appliance Update Guide.

Upgrade Notes¶

Warning

Release v0.38.0 enables SCION RSS by default on all SCION interfaces. If neigboring CORE or EDGE appliances configure their SCION links on interfaces with driver “LINUX” and are not yet updated to v0.38.1, SCION RSS must be disabled explicitly. We recommend upgrading to v0.38.1 or later. For recommendations when and how to enable SCION RSS, refer to Neighbors.

v0.38.1 (2024-12-10)¶

Fixes¶

SCION RSS is now also supported for SCION links configured on an interface with driver “LINUX”.
The flag to set SCION RSS for a link is now disabled again by default. In v0.38.0 we changed the default value to true, however, releases prior to v0.38.1 do not support SCION RSS on a SCION link configured on an interface with driver “LINUX”.

v0.38.0 (2024-11-28)¶

Breaking¶

The appliance now enables SCION RSS by default on all SCION interfaces and the IP-in-SCION tunneling endpoint. If an interface connects to another appliance that has an Anapaya version prior to v0.34 or a non Anapaya version that does not support SCION RSS (e.g. the opensource router), SCION RSS must be disabled explicitly.

Features¶

EDGE to EDGE encryption¶

As previously announced in our blog, this release introduces EDGE to EDGE encryption to protect the IP packets transmitted over the SCION Internet. The encryption is performed using the Encapsulating Security Payload (ESP) protocol with AES-GCM as the encryption algorithm. SCION’s control plane PKI (CP-PKI) is used to establish mutually authenticated QUIC connections between the tunnel endpoints and derive the symmetric encryption keys.

With the payload encryption feature enabled, the IP-in-SCION tunneling endpoint automatically discovers remote endpoints that support payload encryption and establishes IPsec Security Associations (SAs) with them if necessary. An IP-in-SCION tunneling endpoint might establish multiple SAs with the same remote endpoint, e.g., to send and receive traffic over different SCION paths or to enable multi-core processing.

Configuration¶

To be able to use the payload encryption functionality, it must be enabled on the local scion_tunneling configuration:

{
  "scion_tunneling": {
    "endpoint": {
      "encryption": {
        "enabled": true
      }
    }
  }
}

A domain’s configuration section now includes the optional encryption field to enable or disable payload encryption. By default, payload encryption is disabled. To enable it for a domain, add the following configuration:

{
  "scion_tunneling": {
    "domains": [
        {
            "encryption": "ENABLED"
        }
    ]
  }
}

By enabling encryption for a domain, payload encryption is enforced for all IP-in-SCION tunnels in this domain. This means that all sent packets must be transmitted and all received packets must be received over an encrypted tunnel.

See IP-in-SCION Tunneling for the full documentation.

License management system¶

In future releases the Anapaya appliance will require a license to operate. A license can enable/disable certain features depending on the license tier. This release already brings all the necessary APIs to manage licenses on the appliance. However the license enforcement is not yet active, this means even if a license is not present or the license is expired the appliance will continue to operate as before.

We recommend to already get familiar with the license management APIs and already install a license on your appliance, to be ready for the future releases, where the license enforcement will be activated.

See Software License for the full documentation.

Customizable service configuration¶

The appliance configuration now contains a new section to customize the service configuration. This allows operators to provide a custom configuration template for a service.

An example use case is to provide a custom BGP configuration for FRR for advanced configuration options that are not exposed by the appliance configuration natively.

To check how a rendered configuration would look like, without actually installing the template use the new endpoint: POST /config/advanced/service-customization/{service_type}/template/execute

To install the template, put the custom template in the advanced.service_customizations.template field, for the given service type.

Note

This is an advanced feature and should be used with caution. If you use this please also inform the Anapaya customer service about it, so that we can consider adding proper support for your use case.

Improvements¶

Appliance-CLI¶

The appliance CLI info command focuses on the important information for an operator. If the health status of the appliance is not passing, the info command now states how to check the health data of the appliance for more information. We have also added two sub-commands to display detailed information about software versions (appliance-cli info software) and license information (appliance-cli info license).
The appliance-cli sub-commands get, post, put, and delete now have a --fail flag that makes the command exit with exit code 22 if the HTTP status code of the repsonse is greater or equal to 400.
The default cost of the bcrypt algorithm in appliance-cli crypto kdf has been increased from 10 to 12. We recommend that you re-create the hashes according to your threat model.
The interfaces in the appliance-cli info and appliance-cli info scion command are now sorted.
Rename the --timeout flag to --duration in the appliance-cli debug notifications disable to avoid undesired shadowing. Previously, the --timeout flag was shadowed by the global flag for setting HTTP timeouts. As a result, the notifications were always disabled with the default timeout.
The applance-cli can now correctly set the log level for the appliance-controller and appliance-installer services. This also requires a appliance-installer v1.3.3 which will be part of the upcoming v2.14.X system-package.
The appliance-cli will no longer panic if it is executed in a directory that is not accessible to the user.

Varia¶

The VRRP validation now ensures that the VIP addresses are part of a subnet in the configured interface.
The /management/api/listeners section is now required. Previously, the user had the risk of locking themselves out from the API when misconfiguring with an empty management section.
If any of IP-in-SCION tunneling input filter checks fail, the packet is dropped. Each drop is accounted for in the metrics gateway_ippkt_bytes_received_filtered_total and gateway_ippkt_received_filtered_total with the label reason set to the reason for the drop.
Values for reason label of gateway_ippkts_discarded_total metric are refactored. The new values are:
- no_route - packet cannot be routed to any routing chain
- no_traffic_matcher - packet satisfies no defined traffic matcher
- no_session - there’s no alive session to send the packet to

Deprecations¶

For basic authentication passwords, we will require a minimum bcrypt cost of 8 in a future release. We recommend that you update your passwords hashes already to prepare for this future change and ensure a smooth transition. Choose the cost value according to your threat model, however, we recommend to go at least with a value of 12.

To generate a new password hash with the recommened cost, you can use the appliance-cli of this release:
```
appliance-cli crypto kdf hash
```
Put the new hashes into the configuration under the management.api.basic_auth.users section.

Change categories¶

In the following we list the different change categories that are used in the release notes.

Features: Describes new features that have been added. Example: The appliance API can now be protected with OIDC/OAuth2.
Improvements: Describes improvements to existing features. Example: The routing table implementation is now 30% faster.
Fixes: Describes bug fixes, i.e. previously broken behavior that is now fixed. Example: The appliance no longer crashes when adding a new route.