18:00:08 #startmeeting network-health 18:00:08 Meeting started Mon Mar 30 18:00:08 2020 UTC. The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:08 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:00:32 let's see how managed to be here after we adapted the meeting time :) 18:00:46 hello 18:00:47 o/ 18:00:50 meanwhile for those who are: https://pad.riseup.net/p/tor-networkhealth-2020.1-keep 18:00:56 hihi! 18:01:08 if you have something to add, please do so on the pad 18:01:17 (both statuses/discussion) 18:03:42 okay, let's get started anyway 18:03:48 maybe other folks are coming 18:03:58 aha, we have a dgoulet as well, nice :) 18:04:13 o/ 18:04:18 ggus: so, eff got back to us, how shall we proceed? 18:04:29 do you want to take a first pass on their reply? 18:04:35 should we look at this together? 18:04:39 or...? 18:05:07 GeKo: i think we could move to a pad, and give one week so people cna review 18:05:19 also included in people: steph, roger 18:05:48 works for me 18:05:58 do you want to take that onto your plate? 18:06:11 yep, gimme 18:06:34 * GeKo hands this item over 18:06:37 thanks 18:07:19 it seems otherwise we don't have anything to talk about that is related to the status updates? 18:08:08 okay 18:08:21 so, let's go over to the discussion part 18:08:28 hi! 18:08:36 i have one item i have been thinking a bit about 18:08:38 hi! 18:09:01 so, last week i started badexiting relays for #32864 18:09:35 it turns out that we have some relays that fail in this test but are not misconfigured and not malicious 18:09:55 if you look at the tor-relays thread there was one operator that got back to us 18:10:24 and they have configured their relay in a particular way so that it complies with the dir-spec 18:10:37 to get the exit flag but fails 18:11:02 i wonder what we should do with relays in that area 18:11:25 should we say, "okay, the dir-spec has those requirements, thus this is a proper exit" 18:11:29 How well does the relay perform for clients? 18:11:56 Is it likely to work fine? Or are users going to get mysterious errors that won't be resolved until they build a circuit through a different exit? 18:12:09 or should we impose additional requirements on top of that, so that it does not get the badexit one 18:12:18 overriding essentially the dir-spec 18:12:28 dennis_jackson: i guess it depends 18:12:54 we probably need a user model first to answer those questions 18:13:18 Good point 18:13:29 what is not working on these Exit? 18:13:46 as in what makes them differ from the spec ? 18:14:37 well they adhere to the spec 18:14:47 if you take https://metrics.torproject.org/rs.html#details/51AE5656C81CD417479253A6363A123A007A2233 18:15:03 then it only allows exiting to one /8 on port 80 18:15:17 which is why the exit-dns tests failed 18:15:35 hmmm 18:15:42 "accept *:53" ? 18:15:53 (both athur's and my modified one which had http://example.com and http:eff.org as respective etst urls) 18:15:58 *test 18:16:22 yeah, dunno why they do that 18:16:51 ok so this is an exit policy issue I'm guessing and thus question is to contact them and tell them or if we can't BadExit? 18:17:12 they responded on the thread 18:17:26 no but about your question earlier 18:17:28 14:12 <+GeKo> should we say, "okay, the dir-spec has those requirements, thus this is a proper exit" 18:17:45 and explained that they only allow the one /8 on port 80 as it essentially cut down any abuse complaints for them 18:17:55 and they would still be an exit according to spec 18:18:05 ah ok just annoying for users 18:18:10 To be fair, they essentially want to be an IPv6 exit 18:18:15 yes 18:18:20 but tor is not there yet 18:18:36 How does Tor Browser behave in this situation 18:19:04 well, if you don't have the domain on the hsts preload list 18:19:13 you'll try port 80 first 18:19:36 (or if you don't have the https version bookmarked/in your history) 18:19:44 Maybe succeed if you get an IPv6 address? otherwise new stream? 18:19:47 (or don't type it into the url bar 18:19:50 ) 18:20:13 s/don't// 18:20:35 dennis_jackson: yeah 18:20:49 so, this will definitely be noticable for tor browser users 18:21:07 i have not tested how badly, though 18:21:14 Okay 18:21:28 but i suspect you would rotate the exit at some point 18:21:36 I still don,t see how the Exit policy is making the exit DNS test fails? 18:22:07 well, it's not really a dns test 18:22:28 in the sense that you test dns in particular 18:22:35 I am biased, but I would favour a policy which supports Tor Browser users getting good circuits with low latency, high bandwidth and minimal errors. I would love for their to be a minimal QoL spec for exits in that regard. 18:22:51 you try to resolve the test domain and if you get an error back the assumption is there is something wrong with your dns setup 18:23:26 dennis_jackson: yeah, that's what i was thinking about 18:23:36 Bandwidth is somewhat covered by the current measurement system. Latency is not, but probably takes a lot of effort to solve. So this policy could cover as many hard error situations as we are aware of? 18:23:37 GeKo: I'm _so_ confused, maybe I could read the email thread instead? 18:23:41 GeKo: what is the Subject line? :S 18:23:48 it is linked in the pad :) 18:23:57 Bad Exit 18:24:01 err 18:24:05 BadExit 18:24:13 ah in the pad, fantastic lol 18:24:33 oh you came late: https://pad.riseup.net/p/tor-networkhealth-2020.1-keep is the link 18:25:11 yeah I see it 18:25:34 dgoulet: "Request error: TTL expired" is the error i am currently mostly looking at 18:25:47 but that has to be different from the exit policy? 18:25:53 so, when 10/10 results look like that 18:26:13 then i am assuming there is something wrong with the dns resolution at the exit 18:26:23 dgoulet: what has to be different? 18:27:06 thing is that a tor client won't use an Exit if the policy can't deliver the request basically so you won't choose that Exit for IPv4 port 80 18:27:25 that is where I'm having a hard time understanding why it is a BadExit due to its current policy? 18:27:30 (except the DNS failure test) 18:27:51 in other words, what would it need to do to not be a BadExit in these circumstances? 18:28:05 Is DNS resolution done on the same circuit as the connection attempt? If so, you don't know if the domain is IPv4 until you send the request 18:28:14 (Forgive me, don't know how the internals work here) 18:28:49 I'm not sure either actually :P ... but if tor is trying to connect to an IPv4 through an Exit that doesn't allow it, it is a bug in tor most likley 18:29:06 unless tor assumes 80 + 443 _always_ open if Exit flag and thus this is a edge case we don,t handle 18:29:16 where IPv6 it is but not IPv4 18:29:20 hrm. 18:29:36 But no way to tell if domain is ipv4 or ipv6 prior to lookup? 18:29:39 right 18:30:28 the DNS query comes back to the client, and tor must try to use the same Exit (maybe same circuit) dunno... seems intriguing to me 18:30:43 so, the reasoning for badexiting was the assumption that tor would pick that relay in a browser context for http requests 18:30:53 as it does not know the ipv4 address yet 18:31:00 but would then fail because of just the /8 18:31:08 resulting in the errors we see in the test 18:31:16 ok so would pick that Exit, DNS resolve and then connect to the IPv4 through the same Exit 18:31:33 wait, does tor can do a full connect by hostname through an Exit? 18:32:09 as in DNS query doesn,t need to come back to the client? 18:32:29 good question 18:32:46 i was under the assumption it does :) 18:32:49 but either way 18:32:55 I'm not sure lol... I don't recall us encoding hostnames in cells... but that client DNS thing is a place in tor I'm not too familiar 18:33:00 ok 18:33:20 what happens if the ipv4 address suddenly does not match the exit policy? 18:33:44 yeah assuming we force 80 + 443 to be open but then reject all IPv4 ... 18:33:47 does tor pick now a new circuit? 18:34:05 or fail silently 18:34:07 I would need to look in tor what happen when you get a "policy denied" error 18:34:17 but let's assume it fails 18:34:18 that is an interesting issue tbh 18:34:23 ok 18:34:29 should we badexit that relay 18:34:35 ? 18:34:49 because it seriously affects tor browser users? 18:35:19 "Exit" -- A router is called an 'Exit' iff it allows exits to at least one /8 address space on each of ports 80 and 443. (Up until Tor version 0.3.2, the flag was assigned if relays exit to at least two of the ports 80, 443, and 6667.) 18:35:28 well according to this, yes it should _not_ be an Exit 18:35:35 I see only 443 on IPv4... 18:35:57 no, it allows exiting to on /8:80 18:36:00 so it's fine 18:36:04 *one 18:36:05 Well - on one hand it would be nice to support IPv6 exits, but not sure if the complexity would be worth it 18:36:06 "at least two of the ports" 18:36:17 This relay operator isn't doing anything wrong and it is a reasonable use case 18:36:23 dennis_jackson: can't you just advertise an IPv6 addr? or we force IPv4 on Exit? 18:36:47 If I understand GeKo right, at least one IPv4 is reqired? 18:36:50 required* 18:36:56 GeKo: isn't the phrasing there "at least allow two ports in 80, 443 or 6667 list" ? 18:37:27 But more pragmatically, if Tor Browser currently suffers, I'd support a policy on bad exiting to avoid that as much as we can using a wide range of criteria. 18:37:38 dgoulet: not anymore it seems 18:37:50 indeed, if the Exit impacts UX ... it is no good imo 18:37:51 up until 0.3.2 it was 18:38:01 Ideally, a single script that network health could run that outputs 1 or 0 on a exit. (and such that operators could easily run it on their own relays as a health check) 18:38:52 yeah 18:39:07 GeKo: ok but tor should _not_ pick that Exit if it planned to connect on HTTP IPv4 though... but I bet because it has 80 on IPv6 and doesn't know what the IP version will be, it picked that Exit anyway... 18:39:08 how fun 18:39:13 dennis_jackson: +1 18:39:25 dgoulet: yeah, that's a good point 18:40:00 GeKo: but if the DNS query does return to the client and then tor picked that circuit again, that is crazy bug... would worth an investigation 18:40:14 regardless of that bug, I stand by my point that any Exit impacting UX is no good :) 18:40:22 okay, i agree 18:40:23 especially in TB land 18:40:25 my two cents :) 18:40:52 we should then start thinking about criteria for that 18:41:35 alright, that's all i had at least, thanks 18:41:46 does anyone else has points for discussion? 18:41:55 nothing from me 18:41:59 i'm good 18:42:07 o/ 18:42:15 okay, thanks folks 18:42:26 happy week, stay healthy in those hard times o/ 18:42:30 #endmeeting