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

Proposal: SVC BR #1801

Closed
sgmonroy opened this issue Aug 24, 2018 · 3 comments
Closed

Proposal: SVC BR #1801

sgmonroy opened this issue Aug 24, 2018 · 3 comments
Labels
c/dispatcher SCION dispatcher c/router SCION Router i/proposal A new idea requiring additional input and discussion

Comments

@sgmonroy
Copy link
Contributor

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.

@sgmonroy
Copy link
Contributor Author

sgmonroy commented Aug 8, 2019

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.

@kormat
Copy link
Contributor

kormat commented Jan 28, 2020

For SCMP packets, there's no need to look at/modify the L4, or require one-hop-path extensions etc.

oncilla pushed a commit to oncilla/scion that referenced this issue Jun 22, 2020
At the moment, this is used by path probes. (see scionproto#1801)

Co-authored-by: shitz <hitz@anapaya.net>
oncilla added a commit that referenced this issue Jun 22, 2020
At the moment, this is used by path probes. (see #1801)

Co-authored-by: shitz <hitz@anapaya.net>
@scrye scrye added c/router SCION Router and removed c/posix-router labels Nov 23, 2020
@scrye scrye added the i/proposal A new idea requiring additional input and discussion label Jan 5, 2021
@scrye
Copy link
Contributor

scrye commented Jan 5, 2021

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.

@scrye scrye closed this as completed Jan 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c/dispatcher SCION dispatcher c/router SCION Router i/proposal A new idea requiring additional input and discussion
Projects
None yet
Development

No branches or pull requests

4 participants