Re: [tor-relays] pinning relay keys to IPs (or not)
(where a lot of IPs changed their AS from IANA to Digital Ocean) A couple of minor notes regarding ASNs: 1) many IPs fall under a hierarchy of ASs where a large core-network provider (e.g. Level3) advertises a block and a second client leaf-AS advertises a sub- block. Sometimes the core AS advertises the smaller blocks though that has diminished with the CIDR route consolidation initiative. Also some ASs advertise bocks and sub-blocks. This shows up often with the CYMRU lookup data dig +short D.C.B.A.origin.asn.cymru.com txt and DNS will rotate the multiple advertisements, so one should sort the list by CIDR size and select the smallest block (i.e. largest CIDR / value). Possibly MaxMind takes care of all this in their data. 2) one can likely ignore AS changes when the IP has not changed, thus avoiding problems caused by network restructuring 3) perhaps many dynamic allocations where the IP changes to different AS can be detected by examining the AS owner identifiers and looking for a match I agree guards are special and perhaps should not be allowed to change ASs at all without loosing the flag, maybe even should stay glued to one IP to avoid any failed client connections and the negative impact that may have on anonymity. It seems reasonable to allow dynamic-IP middle and exit relays. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] pinning relay keys to IPs (or not)
At 22:05 7/28/2015 -0400, you wrote: A couple of minor notes regarding ASNs: Also the AS number assigned to an IP address may legitimately vary depending on the source/observer. This is due to the relativistic nature of BGP routing. For example a Comcast address 74.95.187.105 is listed in AS 33287 by CYMRU (my preferred source), but Routeviews does not see the sub-block due to BGP aggregation and puts it in 7922. Looking-glass servers are helpful when trying to understand AS-IP assignments, here are just two of many http://lg.he.net http://lookingglass.level3.net/ = Much of the above applies equally to IPv6 except that by design, the IPv6 address space is far less fragmented and very often an AS will advertise only one and never more than a handful of address blocks. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] pinning relay keys to IPs (or not)
On Sun, Jul 26, 2015 at 04:48:37PM +, 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-parameters 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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] pinning relay keys to IPs (or not)
On 26 July 2015 at 17:48, Yawning Angel yawn...@schwanenlied.me wrote: On Sun, 26 Jul 2015 16:11:56 +0200 nusenu nus...@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/broadband/201404/t20140418_422573.html 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). ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] pinning relay keys to IPs (or not)
On 27 Jul 2015, at 01:30 , starlight.201...@binnacle.cx wrote: Perhaps a way to do it is reset the consensus for a relay if its IP address moves to a different Autonomous System. Is rare that dynamic IP causes relays to hop ASs (e.g. possibly SBC/ATT), and list of exceptions could be created for the few cases where it causes trouble. CYMRU has a dynamic service for looking up AS from IP. What if an entire IP block (or entire AS) moves ASs? What if the external dependency on CYMRU allows the entire Tor Network to be reset if CYMRU is hacked/broken/incorrect? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com pgp ABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] pinning relay keys to IPs (or not)
-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 nus...@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 SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJVtSJJAAoJEIN/pSyBJlsRykoH/2RlWBnvgg2/Ecux3BCOEH7d UgpmBufoX5/g2wqNkixNhSVPICCbSnzie5HuIcSjZXUZ1B7YZPU86xgZPKFRm5pn lMzgfsoUUYsOwz9PluRC0Og5YbssUIpB71jOhOaCO+RxvX034s4FVZbd++ByH1qi rXzV+d6KRaQAB6+Togo+qHy8NTQJqoGpw8y4ikJa96puyJD95AAjs2KBwaqOUsGD A4IGNSsEUbfRfkZURDqecasQnQPsHtH3OBlnv2/pKmlp5DuxSQJNSrqqpqDRa8su XGtXZkYd7tqCCE6EJRau4MUaiRV5CvQImcYEmyyNSMmiPSXKwvaA7cpiYjJMga8= =UCjN -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] pinning relay keys to IPs (or not)
On Sun, 26 Jul 2015 21:09:13 +0300 s7r s...@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, -- Yawning Angel pgpcciOfZ2l9G.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] pinning relay keys to IPs (or not)
On 26 July 2015 at 22:42, Yawning Angel yawn...@schwanenlied.me wrote: On Sun, 26 Jul 2015 22:32:18 +0100 Pascal Terjan pter...@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/broadband/201404/t20140418_422573.html 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. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] pinning relay keys to IPs (or not)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 teor: On 27 Jul 2015, at 01:30 , starlight.201...@binnacle.cx wrote: Perhaps a way to do it is reset the consensus for a relay if its IP address moves to a different Autonomous System. Is rare that dynamic IP causes relays to hop ASs (e.g. possibly SBC/ATT), and list of exceptions could be created for the few cases where it causes trouble. CYMRU has a dynamic service for looking up AS from IP. What if an entire IP block (or entire AS) moves ASs? What if the external dependency on CYMRU allows the entire Tor Network to be reset if CYMRU is hacked/broken/incorrect? That will all not work, IPs are nothing which you can rely on and reset consens if it does change. My home IP jump between to ASs every day on reconnect. My ISP own both AS and with the IPv4 shortage that will get even more crazy the next few years. I'm cleary against reset consens, ban FP or what ever you guys think would be right. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVtQXaAAoJEHkrhgAY5jaZjqgQAIprJTp+23DCddKlym8z/RkN jhUK0zpWNpCYnfnlRujNtBcLoZBrKXCN5HhglOB70qsOONC6oGpKoQ1u51xiX1wL zDH39kiRgZnhmaJm3W8J4Q2ZiLU233VLgfHsnuBWiFwGErBwRDIqMI6NDF6vbdF3 D7iXY8Adp4/6bwJaf0UDMt6qjYTUtL53vvtnjMK2eKwuwfiuXJjl8yQaDFN6qdzD fSiohvUQdGN7oLDdqIOEmkBtX/ndK29aqvO+1mS8aXqkwDujNZHfDvoLYINJFEdG qM5v7FLZY7Ey2FB3jaJQICq0DjUcRQM2+i2XilKQH/nQNeX5t4VjEhv4Gj+WR86b S7v+m2vEwzLqqeZlyii31Cl9LBN8xOzUaw1JP2ErC9gxoB0BxyOz7Nv5Op49l1d6 yRxgYxyD/JIXJEC6GwvOCZOjITZBlMq4rhTX8kNLafwyiw2VucP5iPfEFZ09rXNt 9wr+68fhUU9OqUiolZJ44dIkRhBvymTaBFZNIcXqlrEh63vrIX5RSmNldxH84cau 6IpAuBREA7teqrWxoxYw/s2M6+BHqQiJVK5I4rlJyTk8KLyraDQ2W+QjGF2ZCKn9 HRiLTelLuREtH2nR4JDIrOAL+OacF6cqnh0ozRe/1h3q6zgEhp263GZxVpvroL9V 6yVR/Y6yi9mAQ/BHTgAG =ZZCo -END PGP SIGNATURE- 0x18E63699.asc Description: application/pgp-keys ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
