Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

snet: add extension header support to DataplanePath and PacketInfo #4628

Open
marcodermatt opened this issue Sep 20, 2024 · 6 comments
Open
Labels
i/proposal A new idea requiring additional input and discussion

Comments

@marcodermatt
Copy link
Contributor

For the implementation of the FABRID protocol in scionlab (netsec-ethz#168) it was necessary to access Hop-by-Hop and End-to-End extension headers during serialization and decoding of the packet.

We added a new SetExtensions function to the DataplanePath interface, which is called in packet.go. For existing DataplanePaths (onehop, scion, etc.) this function just returns nil.

// DataplanePath is an abstract representation of a SCION dataplane path.
type DataplanePath interface {
	// SetPath sets the path in the SCION header. It assumes that all the fields
	// except the path and path type are set correctly.
	SetPath(scion *slayers.SCION) error
	// SetExtensions sets the HBH and E2E extension headers. It is called directly after
	// the SetPath function.
	SetExtensions(s *slayers.SCION, p *PacketInfo) error
}

The complete code changes can be found in this commit (marcodermatt@576373e) which is independent of FABRID.

This would also allow implementing EPIC-HP as an HBH-option (#4099).

@marcodermatt marcodermatt added the i/proposal A new idea requiring additional input and discussion label Sep 20, 2024
jeltevanbommel added a commit to netsec-ethz/scion that referenced this issue Sep 20, 2024
Control plane features:
- Definition of FABRID policies and connection points on which they are
available
- CS loads policies and appends maps for policy indices and connection
points as detachable extensions to PCBs
- Remote CSes cache FABRID maps
- SD fetches detached extensions on request

Data plane features:
- Fabrid and Identifier HBH extensions for sending FABRID traffic
- WithFabrid option for choosing paths based on the fabrid query
- Fabrid dataplane path which sets HBH extensions
- BR fetches DRKey secret values and fabrid config on startup
- BR validates and updates FABRID HVFs

Tools:
- topology: --fabrid flag enables DRKey and fabrid for local topology
- ping: select fabrid policies with --fabridquery flag
- end2end: run integration test with --fabrid to test path validation

Demo:
1. `./scion.sh topology --fabrid` (docker: `./scion.sh topology -d
--endhosts --fabrid`)
2. `./scion.sh run`
3. `./bin/end2end_integration --fabrid` (docker:
`./bin/end2end_integration -d --fabrid`)
4. `./scion.sh stop`

Upstream changes:
- scionproto#4628
jeltevanbommel added a commit to netsec-ethz/scion that referenced this issue Sep 20, 2024
Control plane features:
- Definition of FABRID policies and connection points on which they are
available
- CS loads policies and appends maps for policy indices and connection
points as detachable extensions to PCBs
- Remote CSes cache FABRID maps
- SD fetches detached extensions on request

Data plane features:
- Fabrid and Identifier HBH extensions for sending FABRID traffic
- WithFabrid option for choosing paths based on the fabrid query
- Fabrid dataplane path which sets HBH extensions
- BR fetches DRKey secret values and fabrid config on startup
- BR validates and updates FABRID HVFs

Tools:
- topology: --fabrid flag enables DRKey and fabrid for local topology
- ping: select fabrid policies with --fabridquery flag
- end2end: run integration test with --fabrid to test path validation

Demo:
1. `./scion.sh topology --fabrid` (docker: `./scion.sh topology -d
--endhosts --fabrid`)
2. `./scion.sh run`
3. `./bin/end2end_integration --fabrid` (docker:
`./bin/end2end_integration -d --fabrid`)
4. `./scion.sh stop`

Upstream changes:
- scionproto#4628
@amdfxlucas
Copy link

I think that's a great idea! It would facilitate the development of new experimental SCION features a lot. Such as ID-INT or multicast

@jiceatscion
Copy link
Contributor

Does not seem to add a lot of cost or risk. I have no objection. Opinions? Other opinions?

@amdfxlucas
Copy link

I think that's a great idea! It would facilitate the development of new experimental SCION features a lot. Such as ID-INT or multicast

Found yet another interesting reference/use case SPIO SCION Path Information Option

@oncilla
Copy link
Contributor

oncilla commented Feb 4, 2025

Without having looked at the concrete usage examples. This feels like the wrong API.
Extensions are not really a property that is defined by a path.

While I understand that some extensions require path information, I don't really see that the path should be used to define the extensions that are attached to a SCION packet.

@amdfxlucas
Copy link

isn't this just a naming issue ?! Rename 'DataplanePath' into sth. more aptly like 'PCFSSetter' and we are good ?!

@oncilla
Copy link
Contributor

oncilla commented Feb 21, 2025

In the same spirit, you could argue to just add another field to snet.UDPAddr to set the extensions and "we are good".

What do you gain by tightly coupling the path and extensions in one abstraction?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
i/proposal A new idea requiring additional input and discussion
Projects
None yet
Development

No branches or pull requests

4 participants