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

Feature request: allow restricting accessible IPs #13

Open
DavidSchinazi opened this issue Feb 15, 2023 · 4 comments · Fixed by #17 · May be fixed by #19
Open

Feature request: allow restricting accessible IPs #13

DavidSchinazi opened this issue Feb 15, 2023 · 4 comments · Fixed by #17 · May be fixed by #19

Comments

@DavidSchinazi
Copy link
Collaborator

DavidSchinazi commented Feb 15, 2023

From Benjamin Schwartz on the list and also Peter Thatcher on the list:

TURN has a concept of "permissions" (see RFC 5576 Sections 2.3 and 8) which is kind of like a whitelist of remote IPs that are allowed to send through the proxy to the local client. This was designed to prevent a client from using a TURN server to acts as a server (the intention was to only use TURN as a mechanism for p2p connections). If the intention of draft-schinazi-connect-udp-listen-01 is to allow for a local client to act as a server and allow arbitrary remote clients to connect to it, then you don't need such a mechanism. But if that's not the intention, you'll need something like TURN permissions to prevent it.

@asingh-g
Copy link
Collaborator

asingh-g commented Nov 2, 2023

I think it makes sense to allow all connections through by default, i.e. let it work as a server and expose the client to any targets when CONNECT-UDP is in listener mode.

Besides, if people deem that permissions need to be built, it could be done through a separate extension.

@marten-seemann
Copy link
Contributor

If you want to address this in this draft, you could add a "whitelist" and "blacklist" to the request. These fields would be mutually exclusive, and would contain a list of IP addresses (and ports, maybe?).

That said, I don't have use case for either of them, so I'd be fine with punting it to a future extension.

@DavidSchinazi
Copy link
Collaborator Author

I agree, we don't have a use case for these permissions either. Since it would be straightforward to build this as a future extension, I'm inclined to not incorporate the feature.

@asingh-g
Copy link
Collaborator

asingh-g commented Jan 2, 2024

Tommy's idea of adding the option to block uncompressed connections may be sufficient to do this, see my latest update to the PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants