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