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