OPEN-SOURCE SCION IMPLEMENTATION ROADMAP 2025

Goal and Ambition

The purpose of the open-source SCION implementation is to drive and facilitate the adoption of SCION. It serves as a reference implementation and a common basis for the SCION ecosystem. It is a vendor-independent, low-barrier entry point to SCION, and can serve as an insurance or fallback for SCION adopters.

All of these aspects require an open-source implementation that is complete, i.e. not missing any required components or critical features, and of sufficient quality (in terms of correctness, performance and usability), and with sufficient documentation to be minimally operationally viable.

Scope

The SCION open-source implementation includes

• Infrastructure components for a SCION network, namely the SCION control service and router, and tooling for the SCION control plane PKI
• End host SCION network stack, tools, and application programming libraries to build SCION native applications
• SCION-IP-Gateway

The scope of the project and these components is the “base” SCION protocol, as described in the IETF drafts: draft-dekater-scion-dataplane-04 - SCION Data Plane, draft-dekater-scion-controlplane-07 - SCION Control Plane, draft-dekater-scion-pki-08 - SCION Control Plane PKI.

For the time being expressly not in scope are experimental SCION-extensions such as the bandwidth reservation system Colibri, or the distributed source authentication and authorization system EPIC.^[1]

Software Packaging and Releases

Target Audiences

Different aspects of the SCION open-source implementation is consumed in different ways:

• The infrastructure components (control service, router, etc) and SCION-IP-Gateway are programs that are run by SCION network operators on suitable hardware.
• The end-host network stack are programs that are ultimately to be run on end-user devices.
• Application programming libraries are consumed as source code by third-party application programmers. The resulting programs then run on the huge variety of internet-connected end-user devices.
• SCION vendors and integrators, as well as researchers and tinkerers consume the SCION implementation source code and extend, customize, or replace and package the SCION infrastructure components.
  Currently, most SCION network operators run the SCION infrastructure components from a commercial SCION vendor.

Release artifacts

In view of these different consumers, our software releases aim to enable the different supply chains.
Releases consist of:

• Source Code: git version tag and source code bundles
• SCION infrastructure component programs and end-host network stack programs:

• Program binaries for the most common platforms (Linux x86-64, ARM-64)
• Installation packages for the most common platforms (.deb, .rpm), including the program binaries and lightweight system integration tools (systemd unit files).

• Documentation

Determining exactly which platforms and formats to support for the binary distribution is work in progress and subject to change. The currently supported platforms are as follow:

More specific integrations of the SCION infrastructure components into e.g. network operating systems or other operational environments may later be in project scope.

Release schedule and breaking changes

We are not committing to a fixed release schedule for now.

New versions will be tagged and released after merging significant changes or on-demand.

Planned releases will be announced with one week notice.

The release version numbers are v0.x.y, that is, semantic version numbering with a major version number 0 indicating in-development and unstable status. This should indicate that the interface of the SCION application programming libraries is not stable yet and may change without earlier deprecation notice.
Note that the SCION protocols are more stable than what this versioning scheme implies, but for practical reasons we only track one single version number.

Changes that affect the interoperability between different components, include a compatibility mode for at least one release cycle, both for the inter-domain as well as AS-local control protocols, packet formats etc.

Where appropriate and feasible, incompatible changes to programs, program options, configuration files and operational APIs include a compatibility mode for at least one release cycle.

Development Roadmap (2025)

Focus area

Above, we have proclaimed that the goal for the SCION open-source projects should be to become a complete, operational implementation of SCION. The current operational readiness level of the SCION open-source components is mixed. The control service and the control plane PKI tooling are relatively mature. However, there is a general lack of tooling for operators to use the SCION open-source implementation in production systems. Furthermore, specifically the router and SCION-IP-gateway need improvements in terms of performance.

The primary focus areas for the work on the open-source SCION implementation are thus to improve operational readiness, deployability, and performance.

Planned work

The following lists contain topics that we consider priorities and plan to work on.
Not all tasks will be worked on in parallel and ETAs are aspirational.

Exploration

Topics under exploration for the longer-term evolution of the SCION protocol and implementation.

• Application programming libraries: support different languages
• Application programming libraries: adopt policy-based interface (from netsec-ethz/scion-apps “pan”)
• SCION addressing as IPv6 addresses
• SCION data plane as IPv6 extension
• SCION can be used via standard INET socket API
• SCMP authentication: explore cost of implementing vs. cost of not-implementing, advance discussion in TC Standardisation and SCION community.
• Overlapping ISDs

Coordination

All contributors to the SCION implementation and related projects are encouraged to join the developer chat (#dev:matrix.scion.org Matrix chatroom, scionproto workspace on Slack) to make their work visible and to coordinate.

Furthermore, the TC Implementation organizes a regular call for contributors to coordinate their work and related technical discussions.