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

don't waste dials to reserved addresses #1173

Closed
cryptix opened this issue Apr 30, 2015 · 5 comments
Closed

don't waste dials to reserved addresses #1173

cryptix opened this issue Apr 30, 2015 · 5 comments
Labels
exp/expert Having worked on the specific codebase is important help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature

Comments

@cryptix
Copy link
Contributor

cryptix commented Apr 30, 2015

I talked to somebody, who heard from somebody, .. that some network intrusion detection systems flag connection attempt sprees to unreachable addresses as malicious scanning attempts.

Apart from a discussion about overzealous monitoring, this reminded me that we need to revisit Dialing and Advertising.

For me as a node on, let's say 192.168.23.42, I have no business trying to connect to a node on 192.168.123.x for instance. Same goes for whole block of 10.0.0.0/8, etc.

We should add a facility that uses OS lookup to get the local addresses and constructs the intersection of the local and the remote peer addresses, using the rules of Reserved IP addresses to see if it is even possible that this peer is on my subnet. There still might be false positives then of remote peers also having a VPN winch uses 10.10.x.x as well but we would cut out a lot of vein dialing attempts.

I'm not sure if this would work but with the new local network discovery, we might consider not even advertising local/private addresses on a global scale and just to listen on them for other locals to discover and dial them.

@cryptix cryptix added difficulty: moderate kind/enhancement A net-new feature or improvement to an existing feature labels Apr 30, 2015
@jbenet
Copy link
Member

jbenet commented May 1, 2015

We should add a facility that uses OS lookup to get the local addresses and constructs the intersection of the local and the remote peer addresses, using the rules of Reserved IP addresses to see if it is even possible that this peer is on my subnet.

sounds right. though not so simple-- have to also take into account complicated topologies where nodes may be inside VMs / containers inside virtual networks. (wheeee! networking is fun! ...)

I'm not sure if this would work but with the new local network discovery, we might consider not even advertising local/private addresses on a global scale and just to listen on them for other locals to discover and dial them.

No, this doesn't work. see the ICE + WebRTC specs.

So, browsers with WebRTC, torrents+friends using ICE, all face this problem and have likely come up with reasonable heuristics for us to evaluate. we can't take them wholesale because we have some different use cases, but good to compare. Also may be we could have settings for how aggressive peer dialing is -- so that in harsh networks we can tone down (at the expense of perf).

@whyrusleeping
Copy link
Member

Off topic, but I cant wait for us to have relays...

@tilgovi
Copy link

tilgovi commented Oct 21, 2015

Just because a node is in a reserved subnet does that mean that we can't dial them? We don't know what routes may be accessible to our default gateway.

@jbenet
Copy link
Member

jbenet commented Oct 27, 2015

@tilgovi that's true. it doesn't actually mean we can't dial them... these are annoying heuristics that can often go wrong, and drive people crazy ("why doesn't this very simple thing connect!"). In the end we will need to drive our dialing (or not dialing) decisions based on observations about the network.

@RichardLitt RichardLitt added exp/expert Having worked on the specific codebase is important and removed difficulty: moderate labels Feb 2, 2016
@RichardLitt RichardLitt added help wanted Seeking public contribution on this issue and removed help wanted Seeking public contribution on this issue labels May 31, 2016
@ghost
Copy link

ghost commented Jun 15, 2016

This got largely resolved by #1433 and #1226 (comment)

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
exp/expert Having worked on the specific codebase is important help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature
Projects
None yet
Development

No branches or pull requests

5 participants