Project Planning

[matzf]

In a recent TC Implementation meeting, we've discussed the idea to develop and publish roadmaps for the development of the open-source SCION implementation.
The idea is to make planned development activity visible, to communicate planned features to users and help coordinate between developers.
It's not meant to be a binding commitment, and contributions outside of this process are still very welcome.

To start, we'll use a very simple process:

• Gather input from community on planned work, desired features etc. in this github issue
• The TC Implementation then compiles a roadmap from this input and publicly announces it

Everybody: please comment to this issue on development topics that you're either planning to work on yourself or that you would be keen to have someone else work on.

[matzf]

Very broadly, a goal of the SCION Association currently is to make the open-source SCION implementation directly operationally usable; the open-source SCION implementation should be (at least minimally) operationally viable on its own, not "only" serve as basis for an actually usable proprietary implementation.

• Router and SCION-IP gateway performance
  Performance improvements required for router / gateway to become minimally viable alternatives to proprietary implementations
• Critical missing features:
  • peering links
  • configurable path and routing policies in gateway
• Stabilize inter-AS communication protocols
  Use appropriate network protocols between control services of different ASes, path control for inter-AS communication
• Extended beaconing and path policy configuration language
  Required for connecting e.g. SCION education network (strictly non-commercial) to production network
• Overlapping ISDs
  Required in future deployments, should be done as long as we can still do protocol-breaking changes
• Router/control service key management
  Forwarding key and DRKey rollover
• Authenticated SCMP control messages
  Partially implemented. Todo are validation and processing of SCMP messages at end host, rate limiting.
  Pending firm decision on whether or not this feature will be included in SCION or not.
• Support SCION-native applications on larger variety of platforms
  Dispatcher-less application stack (allowing multiple independent SCION applications without OS support or central component)
• General usability enhancements
  • Documentation (reference manuals, guides, tutorials)
  • Software packaging / releases
  • Sanitize configuration file tree and formats
  • Tooling

Myself, and in the near future one more software engineer directly employed by the SCION Association, are prioritizing these topics.

[johnstudarus]

Is there any need for CI automation and regression testing? (Maybe that falls under Software packaging/releases). Or continuous validation of the SCION stack working on various bare metal service providers? @alicecuii - perhaps this would be a good project for you? Or if you want to tackle something larger, I'd love to see a message bus ported over to native SCION.

@jBainMartincoit - I'd like you to stay in the loop and see how you can help out with "General usability enhancements
Documentation (reference manuals, guides, tutorials)"

[matzf]

Looking at a recent CI run gives a bit of an overview of the set of checks that we run. This gives us a relative broad coverage already. Of course there can always be more and better tests, but I don't know of a subsystem or topic that is simply lacking tests.

One specific topic related automated testing where we could use help is this: there is a test harness called braccept (for border router acceptance tests). This sets up a SCION border router in a specific configuration, sends individual packets to it and validates that the router behaves as expected. Currently, this is very strict and tolerates no deviations from the open-source "reference implementation". Ideally, we'd want to reuse the same test harness to assess other router implementations, but for this it would need to be redesigned so it can accept and report on different behavior allowed by the of the specification (with all its "SHOULD"s and "MAY"s etc). The data plane specification document is currently being worked on, so it could be a good timing to work on this.
If this sounds like an interesting topic, we could create a github issue describing the requirements, so that you could then start to work out the details.

[JordiSubira]

Currently, I am working on the following items on that list:

• Authenticated SCMP control messages
• • Partially implemented here scmp: add authenticated error messages using SPAO #4255
• • Accepted change in the specification here doc: update timestamp spec #4300
• • (Ongoing) Implement changes in latter point
• Dispatcher-less application stack (allowing multiple independent SCION applications without OS support or central component)
• • (Ongoing) Initial effort here: end host, router: dispatch UDP in router, remove dispatcher socket #4344.

I also have interest in tackling:

• Router/control service key management

I would kindly ask for whoever is interested on this to coordinate together :)

[benthor]

Below is a tentative categorization of the ongoing SCION work at the OVGU NetSys Lab.

Relevant to SCION Association Roadmap

These are topics and projects that we are working on that (might) affect the core protocol in some way and thereby seem most relevant to this roadmap.

• eXpress SCION Router (XSR):
  A SCION border router making use of XDP and P4.
  Possible contributions from XSR to the reference BR (Lars + Robin):
  • Exchangeable data plane to allow using XDP and P4 on Tofino hardware with a Go control plane
  • eBPF implementation of the dataplane
  • AF_XDP sockets for bypassing the kernel network stack
  • MAC validation separated from the rest of the dataplane to allow for more flexible implementation in hardware (e.g. SmartNICs and FPGAs)
• ID-INT development (Lars)
  • ID-INT support in Go BR
  • Host ID-INT
• Support for Peering Links (Thorben / waiting on upstream)
• SCION Certificate Authority and renew service for endhosts (Marten)

Further Ongoing Work - Related to SCION

The following topics probably have less impact on the protocol itself but depend (or are based) on SCION in some way. Many are centered on the end-host and seem less relevant to this roadmap but possibly still of interest.

• Extend SEED with Tofino support (Lars + Robin)
• BitTorrent over SCION improvements and GUI (Marten / student project)
• DNS-over-QUIC support for SCION (Thorben / student project)
• IPFS over SCION, SCION support in libp2p (Marten / student project)
• Hercules ongoing work and improvements (Marten)
• Deadline-aware Multipath Transport Protocol (Tony)
• Scriptable path selector (Thorben)
• Evolutionary Multi-objective optimization for optimal path selection (Tony / student project)
• Bitcoin over SCION - Resilience against partitioning and other routing attacks (Tony / student project)
• Splitting the border router's AES-CMAC validation and forwarding mechanisms to allow more flexible implementation in hardware (Lars)
  • Implement validation in NetFPGA (Björn + Florian)
  • Implement forwarding in P4 on Tofino switch
    • With support for external accelerator and ID-INT (Robin)
    • With support for EPIC (David G.)
• PAN-bindings for C, C++ and Python (Lars)

Future Plans

Some further project ideas we have been throwing around but didn't do any work on yet

• AES-CMAC Linux kernel implementation
• Implement beacon filtering

[matzf]

The SCION Association's TC Implementation has compiled a roadmap document.
Find the full document here: 2023-10 Open-Source SCION Implementation Roadmap

Summary

Goals and Ambition

The open-source implementation of SCION aspires to be complete, i.e. not missing any required components or critical features, and and of sufficient quality (in terms of correctness, performance and usability), and with sufficient documentation to be minimally operationally viable.

Scope

• 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. For the time being expressly not in scope are experimental SCION-extensions such as Colibri, or EPIC.

Releases

When major work topics are complete, we'll publish releases consisting of:

• Source Code: git version tag and source code bundles
• Program binaries and installation packages
• Documentation

Development focus

The focus for the planned work in this period is to improve operational readiness and deployability of the open-source components.

Planned work topics:

Infrastructure components (router, control service, gateway):

• Peering links (Peering links continued #4390)
• Router performance improvements (milestone High performance router)
• Stabilize control plane communication protocols (proposal: Resolving the SVC resolution issue #4388, HTTP3 based SCION control plane #4434)
• Extend control service beaconing policy configuration
• Rolling key change for hop keys in control service and router
• SCION-IP-Gateway performance improvements
• SCION-IP-Gateway configurable path and routing policies
• Documentation
• Software Packaging (dist: build software packages #4425)
• General configuration file structure overhaul
• Compatibility assessment tool for router

End host stack, SCION-native applications:

• Adopt end-host autoconfiguration into official end-host stack
• Dispatcher-less application stack (doc: design doc for end host without dispatcher #4280)

Possible timeline

Possible sequence of work items and rough estimated time of arrival, covering the period of about one year starting from now.

^{Disclaimer: this is based on rough estimates for the effort and many of these topics will require upfront discussion and detailed design work. The timing may depend on the availability of independent collaborators and their voluntary contributions. The included release milestones illustrate that we will release after completing major work topics and should not be mistaken to indicate a commitment to release these version numbers at the indicated dates or feature sets.}

---

We'll update this post with links to issues/milestones to track the progress of individual topics.

This roadmap intends to guide the development work for the coming year or so, but it's not meant to be set in stone. We may amend the roadmap if circumstances change, and everyone is still welcome to contribute to this planning process by commenting or discussing in the chat.