-
Notifications
You must be signed in to change notification settings - Fork 163
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
Comments
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
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
Does not seem to add a lot of cost or risk. I have no objection. Opinions? Other opinions? |
Found yet another interesting reference/use case SPIO SCION Path Information Option |
Without having looked at the concrete usage examples. This feels like the wrong API. 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. |
isn't this just a naming issue ?! Rename 'DataplanePath' into sth. more aptly like 'PCFSSetter' and we are good ?! |
In the same spirit, you could argue to just add another field to What do you gain by tightly coupling the path and extensions in one abstraction? |
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.
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).
The text was updated successfully, but these errors were encountered: