-
Notifications
You must be signed in to change notification settings - Fork 162
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
Proposal: SVC BR #1801
Comments
So after arriving to this issue regarding 'No ACL support' comment in the repo, this issue is related because the ACL feature needs to push rules to neighboring BRs. |
For SCMP packets, there's no need to look at/modify the L4, or require one-hop-path extensions etc. |
At the moment, this is used by path probes. (see scionproto#1801) Co-authored-by: shitz <hitz@anapaya.net>
At the moment, this is used by path probes. (see #1801) Co-authored-by: shitz <hitz@anapaya.net>
Closing this, the router no longer runs a control-plane and we're going in the direction of removing SCION Service (SVC) addresses rather than adding more. |
This proposal would allow neighboring BRs to communicate with each other without specific address knowledge.
The SVC_BR is a special SVC address, where multicast is not allowed and anycast behaves like unicast, targeting a specific BR Control instance, to allow multiple instances registered with the same dispatcher.
To support multiple BR control plane instances registered with the same dispatcher, the BR data plane would replace the port, which for any other SVC address would be 0, with its control plane port (UDP checksum re-calculation required), so the dispatcher can use the port information to find the correct BR control instance to deliver the packet to.
These packets would use a OneHopPath extension, which in itself provides some degree of source authentication when BRs are directly connected to each other, but it is not enough in switched networks. For switched networks, authentication is desired, for example using DRkey, to verify the real source of the control packets. Connection oriented transport protocols do not fit given that we need to support multicast.
The BR control plane would have to interact with the certificate server to generate the neighbor AS DRkey to authenticate packets with OneHopPath extensions.
EXTRA NOTES
As an alternative to introducing SVC BR, we could leave the current behavior of BR control not able to directly communicate with neighboring AS BRs and instead use the Beacon Server (BS) as a sort of proxy that could verify packets with OneHopPath extensions, given that the BS already has DRkey support.
The text was updated successfully, but these errors were encountered: