TC Implementation meeting minutes

[matzf]

The Technical Committee (TC) Implementation is a body of the SCION Association who oversees and steers the open-source SCION implementation project.
The TC Implementation is the @scionproto/scion-core-team.

This meta-issue records meeting minutes for the TC Implementation.

[matzf]

13. March 2023

@oncilla, @lukedirtwalker, @FR4NK-W, @marcfrei, @matzf

Proposal review

• doc: update timestamp spec #4300
  Proposal discussion still ongoing, no decision taken.
• Overlapping ISDs #4293
  No time to discuss in detail; perhaps should involve the TC Standardisation in the discussion.
• cppki: require segment lifetime fully covered by certificate chain #4286
  All in favor, details to be decided, cppki: require segment lifetime fully covered by certificate chain #4286 (comment)
• slayers: add packet validation #4278
  Accept
• Refactor addr.HostAddr types #4149
  Discussed superficially, agreement that we should work on this topic but no decision on specific proposal.
• doc: epic-sapv #4110
  Reject (doc: epic-sapv #4110 (comment))
  Consensus that there are no specific requirements to include this system with scionproto/scion and including it would be a significant burden.
  We want to keep the scionproto/scion implementation focussed on "core" SCION for now. We should document this somewhere.
• doc: CASA #4109
  Reject (doc: CASA #4109 (comment))
  Similar discussion as above.
• router: enforce configured MTU #3738
  Accept, final call for comments (router: enforce configured MTU #3738 (comment))
• AS Master key derivations should use salt value with a random part #2168
  Reject. Using the PBKDF doesn't really make sense anyway as we always use random bytes. This whole thing should be reconsidered as part of the forwarding key roll over.

Other topics

• Configuration setup with various separate files is a mess and should eventually be (re-) designed. No strong preconceived ideas on what this should look like. @oncilla mentions caddy as an example of a well thought out system allowing on-the-fly changes to parts of the configuration without restarts.

[matzf]

1 June 2023
@oncilla, @lukedirtwalker, @FR4NK-W, @marcfrei, @matzf

Roadmap planning and releases

Roadmaps, Project planning

The idea is to make planned development activity publicly visible, to communicate planned work to users and help coordinate developers.
We want to keep the process lightweight:

1. gather input from community on planned work, desired features etc. in a github issue or discussion
2. the TC compiles a high level roadmap and publishes this

The plans should be communicated in a way that encourages contributions. We need to avoid giving the idea "my topic is not in the roadmap so my contribution is not welcome", and also not "my topic is in the roadmap so it will be done without me doing anything".

Releases

We want to have (tagged) releases, to get

• version number to refer to
• way to communicate compatibilities and deprecation schedules etc.
• binary installation, as a easier way to start using the software

The audience for the releases is everybody in the open-source SCION ecosystem:

• operators of SCION infrastructure, operators of SCION end-hosts use the releases as source for binaries to install
• users of libraries
• maintainers of forks/dependent projects
  Even though not all audiences may have the same ideal release cadence, it makes most sense for us to just find a compromise. Due to the single repo setup, maintaining independent release cycles would be too complicated.

Not committing on either feature based or time based releases. We'll just start with something and see what works.
The roadmaps include planned releases, but without committing to timing or feature sets.

@matzf will initiate the planning process described above, and setup the infrastructure for binary releases.

Proposal / PR review

• doc: design doc for end host without dispatcher #4280, end host, router: dispatch UDP in router, remove dispatcher socket #4344
  Compatibility concerns: not all routers & services of an AS can be upgraded simultaneously, so services need to be able to function while the underlay port rewriting is only partially available.

  Two possible approaches:

  • keep the dispatcher and its supporting infrastructure in place. snet can use either dispatcher or direct UDP underlay
  • remove dispatcher support from snet etc. and replace the dispatcher with a simple UDP packet forwarder service on the end host as a compatibility shim.

  Deprecation of this compatibility layer should be announced, in order to make sure that the port-rewriting feature will eventually be enabled in deployments.

• doc: design document for the border router redesign #4339
  Can be merged.

Other topics

• Control plane implementation has some warts and rough edges that can only be fixed with an incompatible update. These issues should be collected in a github discussion so that we can work out a way to address all of it in one go. Examples are:
  • gRPC/HTTP2 over QUIC ugliness
  • SVC resolution
  • wrong namespace for proto definitions

[matzf]

2 October 2023
@oncilla, @lukedirtwalker, @FR4NK-W, @marcfrei, @matzf

Roadmap planning and releases

Discussed roadmap document which will be published soon.

Proposal / PR review

• doc: design doc for end host without dispatcher #4280, end host, router: dispatch UDP in router, remove dispatcher socket #4344

  @JordiSubira has continued to work on this topic and the latest version of the PR takes the compatibility requirements into account.
  @matzf, @oncilla and @FR4NK-W will all do a high-level review pass over this PR.

Other topics

• @marcfrei raised that there is a lack of coordination between developers, in particular for topics that are related to the SCION implementation but may not be in scope for the scionproto/scion repository. Concretely, there are multiple people working on application programming libraries for languages other than golang, but this work is invisible to most of us, and may be in fact duplicate. To address this, we'll:
  • Organize a regular, short call for contributors. For the start, we'll try the format of a ~30 minute call scheduled fortnightly, but only do it if there is demand. On the days before the call, we'll ask (in the #dev chat) if there are topics to be discussed, otherwise cancel it.
  • Offer adopting related projects into "contrib" repositories in the scionproto organization, to make this work more broadly visible. We'll have to figure out how exactly this would look like once we've identified topics that would be a good fit.

[matzf]

30 November 2023
@oncilla, @lukedirtwalker, @FR4NK-W, @marcfrei, @jiceatscion, @matzf

Proposal / PR review

• Proposal: Cross-Segment Hop Fields #4439
  Public discussion ongoing, no decision needed now.
• HTTP3 based SCION control plane #4434
  Prototype was built at hackathon. Needs more work, no decision needed now.
• proposal: re-think SCMP error propagation in snet library #4389
  Will be important, but no decision needed now.
• proposal: Resolving the SVC resolution issue #4388
  Needs more investigation, no decision needed now.
• Overlapping ISDs #4293
  Low priority, not further discussed.

End host stack projects overview

Following up on a discussion in the previous week's Contributor Call; There are multiple development projects that concern the SCION end host stack. Created a document aiming to give an overview on how these parts will fit together.
Brief presentation by @matzf and discussion; no vetos, so created pull request for more detailed review and public discussion

• doc: end host stack projects overview  #4451.

Packaging; testing on different platforms

Looking for options to test cross-compiled packages on arm (for WIP #4448).

[jiceatscion]

10 June, 2024
@oncilla, @lukedirtwalker, @FR4NK-W, @marcfrei, @jiceatscion, @matzf

Administrative matters

• Due to Matthias leaving, the committee needs a new chair. The departing chair proposes that the job be available to any committee member. No objection, but no taker either. JC accepts the position. No objection.

• Due to Matthias leaving the committee would benefit from a new member with long SCION experience. Several present suggest asking if Jordi Subirà would be interested. Unanimous approval in favor of inviting Jordi. Assuming he is willing, the board's approval would be required (but is probable).

• The project could use more code change approvers. Currently only committee members can approve. Consensus is that we could give approval powers to non-committee members. All present agree on the following process:

  • A future approver, is invited to co-review PRs, without actual power to approve.
  • If current approvers find the reviews helpful, the reviewer is given approval powers.
  • This may at some point be followed by an invitation to join the committee.

  Several members propose to start this process with Tilman Zäschke. Motion approved.

• François noticed that the "technical committee - implementation" does not, per it's charter, report to the Board. Due to a typo in the charter. This would need to be checked and fixed.

Communications

• JC provides a summary of the board of advisors meeting.

Roadmap

• Many items on the roadmap are shifting by 4 months.
• Matthias and JC propose to not add new major roadmap items for now, since the previous roadmap was optimistic and (per the conclusions of the BoA) innovations should not be pursued yet. Motion approved.
• Gateway enhancements can be de-prioritized (the OS gateway code isn't used much).
• Configurable beaconing policy is needed badly by SCIERA. A discussion follows regarding how best to implement that. No clear decision emerges.
• Dispatcher-less: quite a few small cleanup items. Enough to constitute a task on the roadmap to account for time spent.
• ConnectRpc is part of the roadmap item "stabilize the CS API". Dominik anticipates in to be in next release w/ a feature flag. Dominik's estimates the work to be 80% complete. One clever member remarks that it means it is close to half done.

Proposals reviews

• Replacing SVC resolution: not started. Lack of time.
• Support for overlapping ISDs: will be abandoned. Lack of demand. It probably means that the requirement that AS numbers be globally unique isn't useful. A discussion ensues but no definitive conclusion. The topic will need more work before it can be closed.
• gRPC/QUICK: approved and making progress (connectRpc).
• Cross-segment hop fields: abandoned. Lack of time.
• NAT support: Marc and Til are working on a design proposal.

[jiceatscion]

Minutes of the Dec 17 2024 Meeting

@oncilla, @lukedirtwalker, @FR4NK-W, @marcfrei, @jiceatscion, @mlegner, @JordiSubira, @nicorusti

Communications

• Nicola provides an update on association activities since the last meeting: slides
• JC presents the updated roadmap: spreadsheet
• Snapshot of today's state:
  

Roadmap Discussions

• JC points out that since the last meeting, only one major item has been completed; the dispatcher removal. Of the three major themes, only two currently have an item in-progress: router high performance IO and http3 CS API (currently stalled).
• Dominik agrees to hand-off the merging of his http3 CS API code into the main tree to whomever is willing to do the legwork. JC to figure out who that might be.
• François offers to own the end-host auto-configuration item.
• end-host autoconfig planning:
  • The various pieces are scattered between ETH netsec and Magdeburg ovgu repos. Both groups need to be involved.
  • It is used by JPAN. May be the go pan API could do the same.
  • Anapaya is interested in the topic too (esp. fetching TRCs). However, will not productize anything that relies on topology.json. Dominik to provide feedback on bootstraper in public repository.
• Hummingbird: There might be some movement on this. Eventually it should be in OS and commercial implementations. One member may contribute it to the open source but in the long term.
• Enabling experimental features safely: is one item on the roadmap but no specific design. JC encourages people to suggest/demand refactorings to make room for new features, will prioritize such efforts.
• DrKey:
  • Mark asks: DrKey in the prod network - is it in there, or not there? Not merged into scionproto.
  • Dominik: If OS implements it, then Anapaya will incorporate it in their products.
  • Jordi: some key management part is missing: how to exchange master keys within an AS, and how to do this over a secure channel.
  • Hummingbird independent from DrKey, auth is an external system.

Action items [inferred from discussion]

• JC to coordinate with Dominik and find helpers to merge http3 CS API code to scionproto
• François to coordinate efforts of netsec/Anapaya/Magdeburg to integrate autoconfig.

Acion items still pending from previous TC meeting

• Invite Til to do more code reviews with intent of giving him approval powers.

[JordiSubira]

Hello JC, Thank you for the report. Just a quick clarification, the DRKey management part which is missing is about the "local" (within the same AS) master secret/Lvl0 key distribution (this is especially important for SCMP, which involves BRs). DRKey exchange between ASes is already there and DRKey exchanges are fully functional. The other missing part is a secure communication channel from intra-AS request, which currently we don't have and renders DRKey-values "secrecy" unfeasible, but it's still doable. Perhaps you meant this, but it's only to avoid confusion. Best, Jordi.

…

On Wed, 18 Dec 2024 at 14:47, jiceatscion ***@***.***> wrote: Minutes of the Dec 17 2024 Meeting ***@***.*** <https://github.com/oncilla>, @lukedirtwalker <https://github.com/lukedirtwalker>, @FR4NK-W <https://github.com/FR4NK-W>, @marcfrei <https://github.com/marcfrei>, @jiceatscion <https://github.com/jiceatscion>, @mlegner <https://github.com/mlegner>, @JordiSubira <https://github.com/JordiSubira>, @nicorusti <https://github.com/nicorusti>* Communications - Nicola provides an update on association activities since the last meeting: slides <https://docs.google.com/presentation/d/14n9s8S7VgTJKu96jGUXf2xYoOEsvRFE0/edit?usp=sharing&ouid=111776545524640342597&rtpof=true&sd=true> - JC presents the updated roadmap: spreadsheet <https://docs.google.com/spreadsheets/d/1GD3K6FXEVbVg3Hu2zRRHlwuDdeJl-UW3-Xc6j7OYqho/edit?usp=sharing> - Snapshot of today's state: image.png (view on web) <https://github.com/user-attachments/assets/65ec67ea-2187-4bac-86de-e240b86157f7> Roadmap Discussions - JC points out that since the last meeting, only one major item has been completed; the dispatcher removal. Of the three major themes, only two currently have an item in-progress: router high performance IO and http3 CS API (currently stalled). - Dominik agrees to hand-off the merging of his http3 CS API code into the main tree to whomever is willing to do the legwork. JC to figure out who that might be. - François offers to own the end-host auto-configuration item. - end-host autoconfig planning: - The various pieces are scattered between ETH netsec and Magdeburg ovgu repos. Both groups need to be involved. - It is used by JPAN. May be the go pan API could do the same. - Anapaya is interested in the topic too (esp. fetching TRCs). However, will not productize anything that relies on topology.json. Dominik to provide feedback on bootstraper <https://github.com/netsec-ethz/bootstrapper> in public repository. - Hummingbird: Not a roadmap priority item but is happening. Mystenlabs focusing on hummingbird independent from scionproto or Anapaya src base. Eventually it should be in both implementations. MystenLabs could contribute to the open source but nothing planned concretely yet. - Enabling experimental features safely: is one item on the roadmap but no specific design. JC encourages people to suggest/demand refactorings to make room for new features, will prioritize such efforts. - DrKey: - Mark asks: DrKey in the prod network - is it in there, or not there? Not merged into scionproto. - Dominik: If OS implements it, then Anapaya will incorporate it in their products. - Jordi: some key management part is missing (how to exchange DrKey values). - Hummingbird independent from DrKey, auth is an external system. Action items [inferred from discussion] - JC to coordinate with Dominik and find helpers to merge http3 CS API code to scionproto - François to coordinate efforts of netsec/Anapaya/Magdeburg to integrate autoconfig. Acion items still pending from previous TC meeting - Invite Til to do more code reviews with intent of giving him approval powers. — Reply to this email directly, view it on GitHub <#4327 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACZKT2NOEE2BB4PKGBFUGE32GF4GHAVCNFSM6AAAAABT2X43ZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJRGM3DQNZYHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jiceatscion]

Hello JC, Thank you for the report. Just a quick clarification, the DRKey management part which is missing is about the "local" (within the same AS) master secret/Lvl0 key distribution (this is especially important for SCMP, which involves BRs). DRKey exchange between ASes is already there and DRKey exchanges are fully functional. The other missing part is a secure communication channel from intra-AS request, which currently we don't have and renders DRKey-values "secrecy" unfeasible, but it's still doable. Perhaps you meant this, but it's only to avoid confusion. Best, Jordi.

Thanks for the clarification. I did not mean really anything because my understanding of DRkey is close to zero. I updated the minutes, albeit in a rather laconic way. Let me know if that's not enough.