15:59:39 <onyinyang[m]> #startmeeting tor anti-censorship meeting 15:59:39 <MeetBot> Meeting started Thu Dec 14 15:59:39 2023 UTC. The chair is onyinyang[m]. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:39 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 15:59:58 <onyinyang[m]> hello everyone! 15:59:58 <onyinyang[m]> here is our meeting pad: [https://pad.riseup.net/p/tor-anti-censorship-keep](https://pad.riseup.net/p/tor-anti-censorship-keep) 16:00:04 <meskio> hello 16:01:25 <shelikhoo> hi~ 16:04:16 <onyinyang[m]> we have one discussion point for today 16:04:26 <onyinyang[m]> Snowflake UDP-like transport ready for a draft review: 16:04:26 <onyinyang[m]> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/219 16:04:59 <onyinyang[m]> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/219 16:05:03 <shelikhoo> yes! 16:05:06 <onyinyang[m]> sorry for the earlier formatting 16:05:15 <shelikhoo> this one is from me 16:05:22 <shelikhoo> don't worry about the format... 16:05:49 <shelikhoo> this is more like a announcement that udp-like transport is ready for a draft review 16:05:49 <dcf1> shelikhoo: what did you change such that the udp-like channel has good performance now? 16:06:24 <shelikhoo> I turned off stream mode and sctp retransmission 16:06:45 <shelikhoo> right now its performance is slightly better than tcp mode 16:07:07 <dcf1> okay, so stram mode has to do with KCP, that's our think; sctp retransmission, that's a parameter on the webrtc dat channel, correct? 16:07:38 <shelikhoo> yes, it is the one just next to `ordered` 16:08:09 <dcf1> right, because there are two orthogonal settings on a data channel: ordered/unordered and reliable/unreliable 16:08:13 <dcf1> https://lists.torproject.org/pipermail/anti-censorship-team/2023-March/000286.html 16:08:43 <dcf1> I guess in your earlier draft, you had only changed ordered->unordered, but had not changed reliable->unreliable? 16:08:52 <shelikhoo> yes, that's true 16:08:56 <shelikhoo> and it is fixed now 16:09:02 <dcf1> ok great, that makes a lot of sense 16:10:29 <shelikhoo> this new version didn't include changes to brokers etc... since they are there to deal with old proxies 16:11:10 <dcf1> ok great! I really appreciate you taking the time to make an MR with the minimal changes. 16:11:17 <dcf1> I am planning to help review this MR. 16:11:18 <shelikhoo> and the new - old proxy coexistence design requires additional consideration 16:11:23 <shelikhoo> yes! thanks! 16:12:17 <onyinyang[m]> nice work shelikhoo :) 16:12:28 <shelikhoo> I don't have anything more to discuss other than encourage more review of the merge request 16:12:30 <shelikhoo> over 16:12:37 <shelikhoo> yes! thanks! onyinyang! 16:12:43 <onyinyang[m]> I think there's not much else to discuss today 16:12:56 <onyinyang[m]> There are a couple of interesting links though 16:12:59 <meskio> we have a paper to discuss :) 16:13:05 <onyinyang[m]> (before the reading group discussion that is) 16:13:09 <onyinyang[m]> yes yes :) I remember 16:13:29 <onyinyang[m]> The first is: https://opencollective.com/censorship-circumvention/projects/snowflake-daily-operations/updates/2023-november-update 16:14:31 <dcf1> The messed up country+transport statistics are supposed to be fixed in 0.4.8.10 (thanks to a fix by trinity-1686a), which I am planning to upgrade to 16:14:59 <meskio> nice 16:15:00 <onyinyang[m]> nice 16:15:16 <onyinyang[m]> There are also 2 interesting links from OONI 16:15:38 <onyinyang[m]> https://ooni.org/post/2023-interview-with-ihueze-nwobilor/ 16:15:50 <shelikhoo> nice! 16:16:17 <onyinyang[m]> has some potentially relevant info for digital rights and anticensorship efforts in Nigeria and other parts of Africa 16:16:40 <onyinyang[m]> and this one: https://ooni.org/post/2023-launch-ooni-censorship-findings-platform/ 16:17:26 <meskio> ohh, the findings reports are nice :) 16:17:43 <onyinyang[m]> With the updated findings reported here: https://explorer.ooni.org/findings 16:18:21 <dcf1> ooni says there are just too many events happening to cover all of them with a full report, so the censorship findings are like mini-reports 16:18:40 <onyinyang[m]> yeah that makes sense 16:19:01 <onyinyang[m]> this is a cool little resource to keep in our pocket 16:19:58 <onyinyang[m]> Ok, I think that's it for the topics to discuss. We can move on to the reading group unless there's anything else? 16:20:30 <meskio> nothing from me 16:20:50 <onyinyang[m]> Today we are discussing: "NetShuffle: Circumventing Censorship with Shuffle Proxies at the Edge" 16:20:54 <onyinyang[m]> https://www.cs-pk.com/papers/3/ 16:21:05 <onyinyang[m]> oh and Patrick is here to discuss with us! 16:21:08 <PatrickKon[m]> Hi all, this is Patrick, here to help with the discussion :) 16:21:11 <onyinyang[m]> Welcome Patrick! :D 16:21:29 <PatrickKon[m]> Though I will only be able to stay until 445 ish ! 16:21:30 <dcf1> right on, thanks for the paper Patrick 16:21:44 <shelikhoo> welcome! 16:22:19 <meskio> nice to have you around 16:23:15 <meskio> does anybody want to give an introduction to the paper? or should we go directly to the content? 16:23:54 <dcf1> I guess quick intro 16:24:41 <dcf1> this paper proposes a place for proxies that is intermediate between end-user proxies (Tor bridges, snowflake proxies) and core network proxies (domain fronting, refraction networking) 16:24:52 <dcf1> which is "edge networks" 16:25:22 <dcf1> the main component is programmable switches that permute changing external IP addresses to point to fixed internal IP addresses 16:25:38 <dcf1> and DNS resolutions to keep up with the current permutation 16:26:11 <dcf1> the idea is that you can mix up all your normal services as well as a few proxies in the same subnet, and make static IP-blocking rules ineffective because the IP addresses change all the time 16:26:47 <dcf1> this paper is not itself a proxy distribution system or an obfsucation protocol. it's meant to plug in with an existing rdsys- or Lox-like and an existing obfs4-like etc. 16:26:59 <dcf1> EOF 16:27:36 <dcf1> PatrickKon[m]: I appreciate the constructive framing of circumvention as a community endeavor. That is the spirit I would like to see in more research. 16:28:01 <meskio> I think is a great idea to rethink defraction networking in the situation where IPv4 ocupation is high 16:28:14 <PatrickKon[m]> Thanks @dcf1 for the intro! A quick tldr is that we're advocating for the community to take a closer look into developing solutions that increase the "circumvention ability" of edge networks (a step up from the traditional way that they can contribute: i.e., deploying individual proxy instances). Here we propose one such solution. 16:29:11 <shelikhoo> I think this is a great idea that would work in place where the government would like to keep external resource accessible 16:29:16 <PatrickKon[m]> * Thanks @dcf1 for the intro! I'll add an additional point: a quick tldr is that we're advocating for the community to take a closer look into developing solutions that increase the "circumvention ability" of edge networks (a step up from the traditional way that they can contribute: i.e., deploying individual proxy instances). Here we propose one such solution. 16:29:28 <dcf1> It's a good angle. And the paper shows a good awareness of existing research and a realistic threat model. 16:30:35 <dcf1> PatrickKon[m]: you are welcome to post your paper at https://github.com/net4people/bbs. I try to post summaries of the papers I read there (see the "reading group" label), but I'm way behind and may not be able to get to this one soon. 16:30:55 <dcf1> Since you have a running deployment, you can post instructions for users who may want to try it. 16:31:42 <dcf1> So one thing I appreciated about this is the comparison to fast-flux DNS, which appears somewhere near the end. 16:32:13 <dcf1> And a big part of the complexity is in tuning e.g. DNS TTLs and the rate of epochs of IP address mapping changes 16:32:30 <dcf1> I think I will need to re-read that to understand it better 16:32:43 <dcf1> On page 6, about long-lived connections, 16:33:20 <dcf1> is there an attack possible where the censor establishes its own long-lived circumvention connections, in order to "lock" proxy IP addresses and keep them from changing? 16:34:32 <PatrickKon[m]> Sounds good dcf1 . Also, in principle the system does not necessarily require a programmable switch. Further development to enable general adoption 16:35:42 <PatrickKon[m]> Good question. Actually, the long-lived "mapping" is tied to an individual client. So new censored clients coming in will be seeing different external IPs 16:36:17 <dcf1> I'm reading "perators need only upgrade an edge network’s border router to a programmable device (e.g., an Intel Tofino P4 switch) to perform programmable packet processing at hardware speeds" on page 2. 16:36:19 <PatrickKon[m]> * external IPs. The mapping contains 4 tuples that include client source IPs 16:36:45 <dcf1> Aha, I see. I hadn't appreciated that. 16:37:54 <PatrickKon[m]> Yup our implementation currently is meant for a programmable switch! But the algo itself should be generally applicable 16:38:18 <meskio> I wonder how will edge network operators feel about routes not being stable, and if that is harder or easier than convincing ISPs to run a tap for something like conjure 16:40:00 <meskio> but I guess we'll see about it 16:40:37 <shelikhoo> my comment is mostly about it is rather hard for individual user to deploy such thing without a cooperating ISP/edge network.. I understand this is the necessary cost for high collateral damage 16:42:24 <dcf1> I like the framing in terms of tradeoffs in Section 2 16:42:32 <dcf1> + support base − collateral damage end-user 16:42:32 <dcf1> − support base + collateral damage core network 16:42:32 <dcf1> ~ support base ~ collateral damage edge network 16:42:52 <onyinyang[m]> it said it took only ~a day to set up, i'm not sure what kind of ongoing maintenance/sysadmin would be involved in operating a netshuffle setup though, but it seems like it could be a more accessible (acknowledging none of this is truly accessible in any non-tech sense of the word) solution 16:43:42 <PatrickKon[m]> Great question meskio , I agree that we will have to see 16:44:09 <onyinyang[m]> dcf1: yes, I really appreciated that framing too 16:45:58 <onyinyang[m]> Patrick Kon: thank you so much for joining us for the discussion. You mentioned you needed to sign off so we don't want to keep you! 16:46:22 <meskio> yes, thank you for coming 16:46:22 <PatrickKon[m]> Our setup currently is still pretty immature, I agree more work needs to be done automate maintenance. The actual setup though was pretty easy (e.g., access to DNS records..)! 16:46:36 <PatrickKon[m]> Thank you all for the helpful comments and feedback! 16:46:57 <dcf1> yes, glad to have made contact and let's stay in touch 16:46:58 <PatrickKon[m]> Feel free to reach out to me if you have questions or would like to chat! 16:47:08 <meskio> :) 16:47:11 <shelikhoo> thanks! 16:47:48 <onyinyang[m]> does anyone have any final thoughts or points of discussion on the paper before we end the meeting? 16:48:31 <meskio> not from me, I think is something to keep an eye on 16:49:13 <shelikhoo> EOF from me 16:49:42 <onyinyang[m]> ok I will end the meeting then :) 16:49:45 <onyinyang[m]> #endmeeting