-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
[split from 'Giving away some "pre-warmed" relay keys for adoption']
I'm of the opinion that it may be worth adding code to pin relay identities to IP addresses on the DirAuth side so that consensus weight and flag assignment gets totally reset if the ORPort IP changes, but if there's too much churn already it may cause more trouble than it's worth.
I hope such code will not be added, because it renders relays on dynamic IPs basically useless. In the past ~week only there were >1000 fingerprints (<3% cw fraction) using more than one IP address (in that timeframe)
I'm somewhat torn on the whole key pinning thing, because I think an individual operator moving their relay around is sort of ok (though in an ideal world the consensus weight should get reset and rapidly re-measured), but giving away the private component of a relay's identity key is putting users at risk, and is behavior that should be discouraged if not outright prohibited if possible (and key pinning would be a heavy handed way to rule out this sort of stupidity).
On Sun, 26 Jul 2015 16:11:56 +0200 nusenu nusenu@openmailbox.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
[split from 'Giving away some "pre-warmed" relay keys for adoption']
Ok.
I'm of the opinion that it may be worth adding code to pin relay identities to IP addresses on the DirAuth side so that consensus weight and flag assignment gets totally reset if the ORPort IP changes, but if there's too much churn already it may cause more trouble than it's worth.
I hope such code will not be added, because it renders relays on dynamic IPs basically useless. In the past ~week only there were >1000 fingerprints (<3% cw fraction) using more than one IP address (in that timeframe)
Hey neat, numbers, thanks. <3% cw doesn't seem that bad.
I will reiterate that such a thing only will become viable once the bandwidth measurement stuff sees massive improvement (and it is being worked on), so this isn't a short term thing, and is just an idea.
I question the usefulness of most of the relays running on residential lines in the first place for other reasons (Eg: most consumer routers are crap, and will probably not be able to simultaneously maintain a connection to every single other relay + bridge, which is rather unhealthy to the network overall. Being able to measure this and delist/reduce consensus weight here would be good as well.).
If the relay's IP is constantly changing significantly faster than the Guard rotation interval (needs more numbers here), I'm not sure if they make great Guards, but this is an arma/asn type question since they think more about Guards than I do.
Under a Tor that has the sort of pinning behavior I envision, a relay that changes an IP once in a blue moon still remains useful, a relay that changes an IP frequently (for some definition of frequently) will be used as a middle only (which is still useful).
Regards,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hello Yawning,
We need to confirm this: is a relay holding TLS connections to the majority of the other relays?
On a relay with over 100 days of uptime (middle relay) Stable, HSDir, etc. I have (# netstat -a | wc -l) 1942 connections. Another one, with less uptime just has 548 connections. These relays have a small consensus weight. A guard with good consensus weight has much more, but anyway under the ~6400 (total number of relays in the consensus).
On 7/26/2015 7:48 PM, Yawning Angel wrote:
On Sun, 26 Jul 2015 16:11:56 +0200 nusenu nusenu@openmailbox.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
[split from 'Giving away some "pre-warmed" relay keys for adoption']
Ok.
I'm of the opinion that it may be worth adding code to pin relay identities to IP addresses on the DirAuth side so that consensus weight and flag assignment gets totally reset if the ORPort IP changes, but if there's too much churn already it may cause more trouble than it's worth.
I hope such code will not be added, because it renders relays on dynamic IPs basically useless. In the past ~week only there were
1000 fingerprints (<3% cw fraction) using more than one IP
address (in that timeframe)
Hey neat, numbers, thanks. <3% cw doesn't seem that bad.
I will reiterate that such a thing only will become viable once the bandwidth measurement stuff sees massive improvement (and it is being worked on), so this isn't a short term thing, and is just an idea.
I question the usefulness of most of the relays running on residential lines in the first place for other reasons (Eg: most consumer routers are crap, and will probably not be able to simultaneously maintain a connection to every single other relay + bridge, which is rather unhealthy to the network overall. Being able to measure this and delist/reduce consensus weight here would be good as well.).
If the relay's IP is constantly changing significantly faster than the Guard rotation interval (needs more numbers here), I'm not sure if they make great Guards, but this is an arma/asn type question since they think more about Guards than I do.
Under a Tor that has the sort of pinning behavior I envision, a relay that changes an IP once in a blue moon still remains useful, a relay that changes an IP frequently (for some definition of frequently) will be used as a middle only (which is still useful).
Regards,
On Sun, 26 Jul 2015 21:09:13 +0300 s7r s7r@sky-ip.org wrote:
We need to confirm this: is a relay holding TLS connections to the majority of the other relays?
This is another metrics needed thing. In general, at any given time, any relay should be prepared to be able to open or accept a connection to any other relay/bridge, because circuit failures are extremely unhealthy for the network and anonymity.
As the number of users tends towards infinity, the number of concurrent TLS connections on a given relay will increase till it caps out at 1 per every other node in the network (plus destinations if Exit, clients if Guard), because the path selection will work out such that at least one user will pick a path that involves every possible relay pair.
So in a magical more anonymous future, yes, relays will hold TLS connections to the majority of other relays. The growth won't be linear since the path selection is based on consensus weight, so having nifty metrics to graph trends here will be useful, since as you noted in your example we aren't at that point yet.
On a relay with over 100 days of uptime (middle relay) Stable, HSDir, etc. I have (# netstat -a | wc -l) 1942 connections. Another one, with less uptime just has 548 connections. These relays have a small consensus weight. A guard with good consensus weight has much more, but anyway under the ~6400 (total number of relays in the consensus).
There are consumer grade routers that would not be able to sustain the small example due to NAT session tracking limitations. This is sad, relays behind such devices will do bad things to the network.
See https://trac.torproject.org/projects/tor/ticket/15482#comment:26 and the linked tor.stackexchange.com question, and the follow up discussion for practical issues caused by such devices.
Regards,
On 26 July 2015 at 17:48, Yawning Angel yawning@schwanenlied.me wrote:
On Sun, 26 Jul 2015 16:11:56 +0200 nusenu nusenu@openmailbox.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
[split from 'Giving away some "pre-warmed" relay keys for adoption']
Ok.
I'm of the opinion that it may be worth adding code to pin relay identities to IP addresses on the DirAuth side so that consensus weight and flag assignment gets totally reset if the ORPort IP changes, but if there's too much churn already it may cause more trouble than it's worth.
I hope such code will not be added, because it renders relays on dynamic IPs basically useless. In the past ~week only there were >1000 fingerprints (<3% cw fraction) using more than one IP address (in that timeframe)
Hey neat, numbers, thanks. <3% cw doesn't seem that bad.
I will reiterate that such a thing only will become viable once the bandwidth measurement stuff sees massive improvement (and it is being worked on), so this isn't a short term thing, and is just an idea.
I question the usefulness of most of the relays running on residential lines in the first place for other reasons (Eg: most consumer routers are crap, and will probably not be able to simultaneously maintain a connection to every single other relay + bridge, which is rather unhealthy to the network overall. Being able to measure this and delist/reduce consensus weight here would be good as well.).
It seems my relay at home is doing quite well (but my IP even if not static has never changed so far so it's not very relevant to the discussion). It currently has 5763 open tcp connections in the tor container, 3116 are to my port 9001 (mix of guard and other relays I believe) and I guess the 2647 others are outgoing to other relays.
It seems the router is a http://enterprise.zte.com.cn/en/products/network_lnfrastructure/cpe/broadban... rebranded by my ISP and it has no problem with that amount of NAT.
Uptime: 34 days Consensus Weight: 45000
If the relay's IP is constantly changing significantly faster than the Guard rotation interval (needs more numbers here), I'm not sure if they make great Guards, but this is an arma/asn type question since they think more about Guards than I do.
Under a Tor that has the sort of pinning behavior I envision, a relay that changes an IP once in a blue moon still remains useful, a relay that changes an IP frequently (for some definition of frequently) will be used as a middle only (which is still useful).
On Sun, 26 Jul 2015 22:32:18 +0100 Pascal Terjan pterjan@gmail.com wrote: [snip]
I question the usefulness of most of the relays running on residential lines in the first place for other reasons (Eg: most consumer routers are crap, and will probably not be able to simultaneously maintain a connection to every single other relay + bridge, which is rather unhealthy to the network overall. Being able to measure this and delist/reduce consensus weight here would be good as well.).
It seems my relay at home is doing quite well (but my IP even if not static has never changed so far so it's not very relevant to the discussion). It currently has 5763 open tcp connections in the tor container, 3116 are to my port 9001 (mix of guard and other relays I believe) and I guess the 2647 others are outgoing to other relays.
It seems the router is a http://enterprise.zte.com.cn/en/products/network_lnfrastructure/cpe/broadban... rebranded by my ISP and it has no problem with that amount of NAT.
Grats, you have a semi-useful router. Do you want a cookie?
Anecdotal evidence that things appear to be working fine isn't all that helpful here. Basically, there should be code to deal with relays running behind things on lists like this:
https://wiki.vuze.com/w/Bad_routers#Due_to_.28too.29_many_connections
So they don't do horrible things to the network. If your router is working, then great, it meets what should be a minimum standard of usefulness.
On 26 July 2015 at 22:42, Yawning Angel yawning@schwanenlied.me wrote:
On Sun, 26 Jul 2015 22:32:18 +0100 Pascal Terjan pterjan@gmail.com wrote: [snip]
I question the usefulness of most of the relays running on residential lines in the first place for other reasons (Eg: most consumer routers are crap, and will probably not be able to simultaneously maintain a connection to every single other relay + bridge, which is rather unhealthy to the network overall. Being able to measure this and delist/reduce consensus weight here would be good as well.).
It seems my relay at home is doing quite well (but my IP even if not static has never changed so far so it's not very relevant to the discussion). It currently has 5763 open tcp connections in the tor container, 3116 are to my port 9001 (mix of guard and other relays I believe) and I guess the 2647 others are outgoing to other relays.
It seems the router is a http://enterprise.zte.com.cn/en/products/network_lnfrastructure/cpe/broadban... rebranded by my ISP and it has no problem with that amount of NAT.
Grats, you have a semi-useful router. Do you want a cookie?
Anecdotal evidence that things appear to be working fine isn't all that helpful here. Basically, there should be code to deal with relays running behind things on lists like this:
https://wiki.vuze.com/w/Bad_routers#Due_to_.28too.29_many_connections
Wow that list is impressive, some of them can't handle 110 connections?! That would indeed be very bad to use such a router, but I guess people would notice that they can't use their connection for anything as soon as they start a relay and would give up
So they don't do horrible things to the network. If your router is working, then great, it meets what should be a minimum standard of usefulness.
On Sun, Jul 26, 2015 at 04:48:37PM +0000, Yawning Angel wrote:
If the relay's IP is constantly changing significantly faster than the Guard rotation interval (needs more numbers here), I'm not sure if they make great Guards, but this is an arma/asn type question since they think more about Guards than I do.
I've been thinking about this one since the thread started. Changing IP addresses "a little bit" isn't so bad. But if a Guard shifts to another place on the Internet, often, this would actually be quite bad. The reason is that clients who use that relay as their guard will effectively shift their paths with it, giving network-level adversaries (as compared to relay-level adversaries) more chances over time to see their traffic. From the perspective of the network-level adversary, it's as though the users are choosing a new guard each time their guard shifts location.
For much more discussion of this point, see https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-par... including the paragraph "Rather than running a guard relay and waiting for the user to switch to it, the attacker should instead monitor as many Internet links as he can, and wait for the user to use a guard such that traffic between the user and the guard passes over one of the links the adversary is watching."
I wonder how many guards shift location significantly across the Internet, and how often?
--Roger
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Roger Dingledine:
I wonder how many guards shift location significantly across the Internet, and how often?
For simplicity lets define 'significantly' as 'guard changed its AS'.
Taking into account data starting from first of July. There were 54 relays with the guard flag with more than one distinct AS, *but* a manual glance on the data suggests that 30-35 of them can be ignored (false positive) due to changes introduced by onionoo's geoip update (where a lot of IPs changed their AS form IANA to Digital Ocean). Then there are a few ISPs with multiple AS numbers (like Digital Ocean and PlusServer) and ~10 of the relays are linked by Roman (according to their contactinfo).
So nothing to worry about to much I guess.
On Wed, Jul 29, 2015 at 02:59:05AM +0200, nusenu wrote:
Roger Dingledine:
I wonder how many guards shift location significantly across the Internet, and how often?
So nothing to worry about to much I guess.
Or to turn it around, it makes it a lot easier to dump the WFU (weighted fractional uptime, one of the components of the Guard calculation) tracking when a relay changes AS -- we don't mess up normal relays, and we protect users from the rare dangerous ones.
The "but that makes the IP-to-AS database a new vulnerability" issue remains though.
--Roger
tor-relays@lists.torproject.org
-
nusenu -
Pascal Terjan -
Roger Dingledine -
s7r -
Yawning Angel