- anti-censorship-team - lists.torproject.org

Partially reliable and/or unordered WebRTC data channels
by David Fifield 17 Mar '23

17 Mar '23

Shelikhoo brought up an interesting point at today's meeting. Snowflake uses WebRTC data channels on the client–proxy link. Data channels are SCTP in DTLS. They are by default fully reliable and in-order, like TCP, and that is the way we currently use them. But SCTP and in turn WebRTC data channels also have "partial reliability" and "unordered" options that might be a better fit for our uses. http://meetbot.debian.net/tor-meeting/2023/tor-meeting.2023-03-16-15.57.log… 16:25:29 <shelikhoo> webrtc(SCTP to be specific) can be set to not retransmit packet 16:25:34 <shelikhoo> and deliver packet out of order 16:25:43 <shelikhoo> to application 16:26:14 <dcf1> I did not know about that. Do we use it that way in Snowflake? 16:27:28 <shelikhoo> it is called "unreliable mode" https://pkg.go.dev/github.com/pion/webrtc/v3#DataChannel.MaxRetransmits 16:29:28 <dcf1> Ok. I might have missed an issue, is that mode used in Snowflake? Or could it be? 16:30:27 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… 16:30:54 <shelikhoo> https://pkg.go.dev/github.com/pion/webrtc/v3#DataChannelInit 16:31:18 <shelikhoo> Maybe no...? but we can enable "unreliable mode" ## Background The specification of WebRTC data channels, RFC 8831, requires the SCTP implementation to support limiting transmissions by either time or number. https://www.rfc-editor.org/rfc/rfc8831 > SCTP, as specified in [RFC4960] with the partial reliability extension > (PR-SCTP) defined in [RFC3758] and the additional policies defined in > [RFC7496], provides multiple streams natively with reliable, and the > relevant partially reliable, delivery modes for user messages. > ... > The partial reliability extension defined in [RFC3758] MUST be > supported. In addition to the timed reliability PR-SCTP policy defined > in [RFC3758], the limited retransmission policy defined in [RFC7496] > MUST be supported. Orthogonal to reliability, the SCTP implementation must support ordered or unordered delivery of messages. https://www.rfc-editor.org/rfc/rfc8831#name-sctp-protocol-consideration > This SCTP stack and its upper layer MUST support the usage of multiple > SCTP streams. A user message can be sent ordered or unordered and with > partial or full reliability. Removing retransmissions and ordering restrictions makes a data channel into a datagram delivery service that preserves message boundaries, but not ordering, and does not guarantee delivery. https://www.rfc-editor.org/rfc/rfc8831#name-sctp-protocol-consideration > Limiting the number of retransmissions to zero, combined with > unordered delivery, provides a UDP-like service where each user > message is sent exactly once and delivered in the order received. The WebRTC Data Channel Establishment Protocol's DATA_CHANNEL_OPEN message is where the ordering and retransmission limits are specified. (Note partial reliability and ordering are two separate concepts, and that you can only limit retransmissions by time or number, not both.) https://www.rfc-editor.org/rfc/rfc8832.html#name-data_channel_open-message > DATA_CHANNEL_RELIABLE (0x00): > The data channel provides a reliable in-order bidirectional > communication. > DATA_CHANNEL_RELIABLE_UNORDERED (0x80): > The data channel provides a reliable unordered bidirectional > communication. > DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): > The data channel provides a partially reliable in-order > bidirectional communication. User messages will not be retransmitted > more times than specified in the Reliability Parameter. > DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81): > The data channel provides a partially reliable unordered > bidirectional communication. User messages will not be retransmitted > more times than specified in the Reliability Parameter. > DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): > The data channel provides a partially reliable in-order > bidirectional communication. User messages might not be transmitted > or retransmitted after a specified lifetime given in milliseconds in > the Reliability Parameter. This lifetime starts when providing the > user message to the protocol stack. > DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): > The data channel provides a partially reliable unordered > bidirectional communication. User messages might not be transmitted > or retransmitted after a specified lifetime given in milliseconds in > the Reliability Parameter. This lifetime starts when providing the > user message to the protocol stack. Though in SCTP the unordered flag (U) may vary per DATA chunk, data channels can only be entirely ordered or entirely unordered. https://www.rfc-editor.org/rfc/rfc9260#name-ordered-and-unordered-deliv The JavaScript API exposes these settings in the RTCPeerConnection.createDataChannel method: https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createDa… > `ordered` (Optional) > Indicates whether or not messages sent on the RTCDataChannel are > required to arrive at their destination in the same order in which > they were sent (`true`), or if they're allowed to arrive > out-of-order (`false`). Default: `true`. > `maxPacketLifeTime` (Optional) > The maximum number of milliseconds that attempts to transfer a > message may take in unreliable mode. While this value is a 16-bit > unsigned number, each user agent may clamp it to whatever maximum it > deems appropriate. Default: `null`. > `maxRetransmits` (Optional) > The maximum number of times the user agent should attempt to > retransmit a message which fails the first time in unreliable mode. > While this value is a 16-bit unsigned number, each user agent may > clamp it to whatever maximum it deems appropriate. Default: `null`. Similar options are exposed in Pion PeerConnection.CreateDataChannel and the DataChannelInit struct: https://pkg.go.dev/github.com/pion/webrtc/v3#DataChannelInit > // Ordered indicates if data is allowed to be delivered out of order. > // The default value of true, guarantees that data will be delivered > // in order. > Ordered *bool > // MaxPacketLifeTime limits the time (in milliseconds) during which the > // channel will transmit or retransmit data if not acknowledged. This > // value may be clamped if it exceeds the maximum value supported. > MaxPacketLifeTime *uint16 > // MaxRetransmits limits the number of times a channel will retransmit > // data if not successfully delivered. This value may be clamped if it > // exceeds the maximum value supported. > MaxRetransmits *uint16 ## Possibilities for Snowflake Currently in Snowflake, we treat the data channel as if it were a TCP stream: we ignore message boundaries and concatenate all messages in order. What we transmit over this stream, though, is a sequence of discrete KCP packets (and possible padding), delimited using length prefixes: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… The boundaries of encapsulated KCP packets do not necessarily correspond to SCTP/data channel message boundaries. We may be able to increase efficiency by using data channel messages directly, one KCP packet per message. Because KCP has its own retransmission and reordering facilities, we could completely turn off reliability and ordering at the data channel layer. One of the reasons we use the packet encapsulation we use now is to permit shaping the size of network packets. But matching data channel messages 1:1 with KCP packet does not necessarily negatively affect traffic shaping capability. We could put a simple length prefix at the head of each message that indicates the effective payload length, with the rest being padding. If the traffic schedule calls for a payload smaller than an immediately available packet, an all-padding message can be sent. Such a change would require changes at the proxy. Proxies would need a second mode to take message boundaries directly from the data channel, rather than concatenating messages and decoding message boundaries from the joined-up stream. Proxies could backward-compatibly forward the messages to the bridge over WebSocket, applying the packet encapsulation at the proxy rather than the client. Or (requiring a change at the bridge too), we could use WebRTC on the proxy–bridge link and similarly send packets with unordered and unreliable data channels.

1 0

Re: [anti-censorship-team] anti-censorship-team Digest, Vol 43, Issue 1
by ut0znfpg＠duck.com 25 Feb '23

25 Feb '23

Hi! I was wondering if ANY of the dark or deep web browsers featured on the Chrome/Google Play store are trustworthy in and of themselves, and if Tor can be accessed with them, or if any use Tor automatically. I have a Chromebook, and I know that Tor does not work with it as you have yet to develop a version for it. Why is it that I think that it will be impossible to have Tor work safely with Chrome/Chromebooks; because Google is EVIL?! :-) Who do you trust for DNS? What is the world's most private and secure computer? I remember Australia having some cool guys build a n independent computer system, but these would not be available outside of Oz. Comments? On Feb 24, 2023 at 7:00 AM, "anti-censorship-team-request(a)lists.torproject.org " <> wrote: --------------------------IronVest--------------------------- Preview: Send anti-censorship-team mailing list submissions to anti-ce --> SPAM? CLICK to BLOCK: https://ironvest.com/app/0/#emails/r8196gs9ev5p@opayq.com/toggle This email is Masked using Ironvest - it was sent from duck.com to r8196gs9ev5p(a)opayq.com (your reply stays Masked). To protect your privacy, do not forward this message, or add new recipients like CCs or BCCs. Thanks for being an IronVest customer! --------------------------IronVest--------------------------- Send anti-censorship-team mailing list submissions to anti-censorship-team(a)lists.torproject.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team or, via email, send a message with subject or body 'help' to anti-censorship-team-request(a)lists.torproject.org You can reach the person managing the list at anti-censorship-team-owner(a)lists.torproject.org When replying, please edit your Subject line so it is more specific than "Re: Contents of anti-censorship-team digest..." Today's Topics: 1. onbasca and rdsys (meskio) ---------------------------------------------------------------------- Message: 1 Date: Fri, 24 Feb 2023 12:47:19 +0100 From: meskio <meskio(a)torproject.org> To: anti-censorship-team <anti-censorship-team(a)lists.torproject.org> Subject: [anti-censorship-team] onbasca and rdsys Message-ID: <167723923930.1535.1605523355422205109@localhost> Content-Type: text/plain; charset="utf-8" Hello, Onbasca[0], a relay bandwidth, has just added support for testing bridges. I have modified rdsys to use it[1]. onbasca produces a bandwidth ratio, on how fast is a bridge compared to the rest of bridges (1 is the median), and rdsys decides if distribute a bridge if the ratio is higher than a configured threshold (right now 0.75) or if is jet untested. rdsys does ignore the onbasca results if there is less then 50% of bridges with high enough ratio to be distributed. As this was needed by a sponsor I have already deployed it in production. I wrote a survival guide: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Onbasca-Surv… I tested it and I don't expect much problems, but as I will be AFK next week if rdsys gives any problem is easy to roll back to the previous version of rdsys without onbasca support. I left the previous binary of rdsys backend in ~/bin/rdsys-backend.old, so rolling back will be running as rdsys user in polyanthum: systemctl --user stop rdsys-backend mv ~/bin/rdsys-backend.old ~/bin/rdsys-backend systemdl --user start rdsys-backend [0] https://gitlab.torproject.org/tpo/network-health/onbasca/ [1] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/merge_requests/76 -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

WebRTC Encoded Transform (or Insertable Streams) for media channels in Snowflake?
by David Fifield 24 Feb '23

24 Feb '23

We have discussed how Snowflake uses WebRTC data channels (DTLS), while some other WebRTC apps use media channels (DTLS-STRP), and how that could be used in a classifier. See for example Section 2 of https://censorbib.nymity.ch/#Fifield2016b. We have also entertained the possibility of encoding Snowflake data into an audio/video stream, à la FreeWave (https://censorbib.nymity.ch/#Houmansadr2013a) or CovertCast (https://censorbib.nymity.ch/#McPherson2016a) in order to use media channels in Snowflake. I came across an API that may permit us to use media channel, without the trouble of an audio/video codec. WebRTC Encoded Transform (formerly Insertable Streams, I think) provides a way to get at and manipulate the raw bytes of media frames. https://w3c.github.io/webrtc-encoded-transform/ > This API defines an API surface for manipulating the bits on > MediaStreamTracks being sent via an RTCPeerConnection. The API defines RTCEncodedVideoFrame and RTCEncodedAudioFrame types that give you an ArrayBuffer of the encoded media data: https://w3c.github.io/webrtc-encoded-transform/#RTCEncodedVideoFrame-interf… // New interfaces to define encoded video and audio frames. Will eventually // re-use or extend the equivalent defined in WebCodecs. [Exposed=(Window,DedicatedWorker)] interface RTCEncodedVideoFrame { readonly attribute RTCEncodedVideoFrameType type; readonly attribute unsigned long timestamp; attribute ArrayBuffer data; RTCEncodedVideoFrameMetadata getMetadata(); }; https://w3c.github.io/webrtc-encoded-transform/#RTCEncodedAudioFrame-interf… [Exposed=(Window,DedicatedWorker)] interface RTCEncodedAudioFrame { readonly attribute unsigned long timestamp; attribute ArrayBuffer data; RTCEncodedAudioFrameMetadata getMetadata(); }; One of the intended use cases of Encoded Transform is a end-to-end encryption when then media streams pass through a middlebox that removes and re-adds hop-by-hop DTLS-STRP layers: https://webrtchacks.com/true-end-to-end-encryption-with-webrtc-insertable-s… https://jitsi.org/security/ > You can turn on end-to-end encryption (e2ee) as long as you are using > Jitsi Meet on a browser with support for insertable streams. The explainer document has a sample of inverting all the bits in an encoded media frame: https://github.com/w3c/webrtc-encoded-transform/blob/5c7ab84f4ce338f299172f… // Receiver transform function createReceiverTransform() { return new TransformStream({ start() {}, flush() {}, async transform(encodedFrame, controller) { // Reconstruct the original frame. const view = new DataView(encodedFrame.data); // Ignore the last 4 bytes const newData = new ArrayBuffer(encodedFrame.data.byteLength - 4); const newView = new DataView(newData); // Negate all bits in the incoming frame, ignoring the // last 4 bytes for (let i = 0; i < encodedFrame.data.byteLength - 4; ++i) newView.setInt8(i, ~view.getInt8(i)); encodedFrame.data = newData; controller.enqueue(encodedFrame); } }); } I am not clear on the difference between Encoded Transform, Insertable Streams, and WebCodecs, but here are some possible browser support tables: https://chromestatus.com/feature/6321945865879552 https://caniuse.com/?search=webcodec https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_API

1 0

onbasca and rdsys
by meskio 24 Feb '23

24 Feb '23

Hello, Onbasca[0], a relay bandwidth, has just added support for testing bridges. I have modified rdsys to use it[1]. onbasca produces a bandwidth ratio, on how fast is a bridge compared to the rest of bridges (1 is the median), and rdsys decides if distribute a bridge if the ratio is higher than a configured threshold (right now 0.75) or if is jet untested. rdsys does ignore the onbasca results if there is less then 50% of bridges with high enough ratio to be distributed. As this was needed by a sponsor I have already deployed it in production. I wrote a survival guide: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Onbasca-Surv… I tested it and I don't expect much problems, but as I will be AFK next week if rdsys gives any problem is easy to roll back to the previous version of rdsys without onbasca support. I left the previous binary of rdsys backend in ~/bin/rdsys-backend.old, so rolling back will be running as rdsys user in polyanthum: systemctl --user stop rdsys-backend mv ~/bin/rdsys-backend.old ~/bin/rdsys-backend systemdl --user start rdsys-backend [0] https://gitlab.torproject.org/tpo/network-health/onbasca/ [1] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/merge_requests/76 -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

(FWD) [anti-censorship-alerts] monit alert -- Connection failed default-bridge-georgetown
by Roger Dingledine 19 Jan '23

19 Jan '23

Hi Micah! Is the georgetown bridge is flaky as it seems? We have alerts set up for the default bridges and it seems like yours alerts a lot and the others alert rarely. It always comes back after a little while, so this isn't a "hey your bridge is down" mail so much as a "what's up with your bridge" mail. I wonder if it is an issue with the network it's running on; or if it's an issue with the bridge itself, e.g. maybe there is something in Tor's logs that could help diagnose; or if it's something wonky about our alerts. (I am cc'ing anti-censorship-team so others can coordinate and stay in sync; note that this is a public list with archives.) Thanks! --Roger ----- Forwarded message from Monit <anti-censorship-monitor(a)nymity.ch> ----- Date: Thu, 19 Jan 2023 12:26:36 GMT From: Monit <anti-censorship-monitor(a)nymity.ch> To: anti-censorship-alerts(a)lists.torproject.org Subject: [anti-censorship-alerts] monit alert -- Connection failed default-bridge-georgetown X-Mailer: Monit 5.26.0 Connection failed Service default-bridge-georgetown Date: Thu, 19 Jan 2023 13:26:35 Action: alert Host: server01 Description: failed protocol test [DEFAULT] at [209.148.46.65]:443 [TCP/IP] -- Connection timed out _______________________________________________ anti-censorship-alerts mailing list anti-censorship-alerts(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-alerts ----- End forwarded message -----

2 1

Paper identifying snowflake traffic
by Kevin Bock 09 Jan '23

09 Jan '23

2 1

How much traffic is Snowflake sending to stunprotocol.org
by John Selbie 03 Jan '23

03 Jan '23

Greetings, I hope this is an appropriate mailing list to discuss a technical issue with Tor's Snowflake project. Please redirect me to the right place if not. I am the original author and maintainer of the open source project, Stuntman. Stuntman is an implementation of the STUN protocol, which includes the STUN server. More details at www.stunprotocol.org. In short, a STUN server helps bootstream direct "p2p" connections such as WebRTC sessions or similar VOIP scenarios by allowing internet devices to self-discover their own public IP address and obtain a (UDP) port for communicating with another node. I also run a public instance of a STUN server with the code at stun.stunprotocol.org. It's been up and running for about 10 years now. It's hosted on AWS. In recent years, the hosting bills for this server have started to get on the high side, even with reserved instances. The number of STUN queries it processes per day is now on the order of hundreds of millions. The stunprotocol.org domain receives nearly a million DNS queries on Route 53 daily. What used to cost a trivial number of dollars to run is now starting to reach $1000 in annual service costs. This isn't paid for by a corporation or well funded internet organization. I pay this out of my personal pocket. It's been a mystery what has been driving the increasing traffic to the server - especially redundant requests from the same IPs. I was inspecting the DNS logs the other day and started to investigate the nodes sending out redundant DNS requests repetitively. Trying to understand why these nodes wouldn't leverage DNS caching. And to my surprise, one of the IPs was running a web server that presented a TOR landing page. That led me to discover this discussion online: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… And a quick inspection of the Snowflake code leads me to find that stun.stunprotocol.org is the default STUN server for Snowflake proxy and listed throughout the documentation as well. While the Snowflake project has good intentions, it doesn't appear to take my hosting costs into consideration. I'm hoping we can have a good discussion on the following: 1) How many snowflake clients and proxies are active and how many STUN requests are each generating towards stunprotocol.org? Do we think the entire worldwide usage of Snowflake could be responsible for millions of STUN queries to stunprotocol.org per day? 2) Expected number of DNS queries (it's a 3-day TTL on these DNS entries, so it blows my mind that there are so many redundant requests). Does Pion or any other part of the Snowflake code tend to go direct to the namespace server itself? 3) Removing stun.stunprotocol.org as the default STUN server. OR... 4) Alternatively, I'm always open to accepting donations to help run the service costs of stunprotocol.org. I'm definitely not getting rich running this thing. Thanks, John Selbie

4 6

stun.altar.com.pl:3478 no longer functioning?
by David Fifield 30 Dec '22

30 Dec '22

According to OONI stunreachability measurements, stun://stun.altar.com.pl:3478 has been showing 100% anomalies since 2022-10-13. If it's down for good, we ought to remove it from the list of STUN servers. https://explorer.ooni.org/chart/mat?test_name=stunreachability&since=2022-1… Previous mention of stun.altar.com.pl: https://lists.torproject.org/pipermail/anti-censorship-team/2022-May/000237…

1 0

snowflake-01 bridge performance tuning and optimization
by David Fifield 04 Oct '22

04 Oct '22

Linus and I have been putting in a lot of time on the Snowflake bridge over the past week or so to improve performance. The increase in users after the blocking of Tor in Russia last September (the one that led us to the multi-tor architecture) was large, but this recent increase is many times larger. We've cleared out the major bottlenecks and since two days ago days the bridge is finally meeting the additional demand. But it's close: during the busiest times of day the CPU and RAM resources are nearly 100% consumed, and the need for horizontal scaling still exists. There have been a lot of changes, both major and minor. You can find listings at: https://gitlab.torproject.org/tpo/network-health/metrics/timeline/-/blob/f5… https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… The most important optimizations have been: - Reduce allocations in WebSocket reads and writes. - Use more than one KCP state machine. - Conserve ephemeral ports in localhost communication. - Disable nftables connection tracking. I attached a graph of bandwidth on the bridge. You can see that between 24 Sep and 02 Oct the daily peaks were unnaturally flattened. The daily shutdowns in Iran caused a paradoxical *increase* in bandwidth, probably because it relieved congestion in the system for the fewer remaining users. In the past two days the shape of the graph looks more natural, and a shutdown decreases bandwidth as you would expect. At its peak, bandwidth is above 4 Gbps. The daily lows are higher than the highest highs of two weeks ago. ## Reduce allocations in writing packets The code forreading and writing encapsulated packets from WebSocket connections was doing unnecessary memory allocations. Some implicit, like a 32 KB buffer being created by io.Copy, and some explicit, like the intentional packet copies being made in the QueuePacketConn type. Reducing allocations makes the garbage collector run less often, and there's also a small benefit from reduced buffer copies. https://gitlab.torproject.org/dcf/snowflake/-/commit/42ea5ff60ce9b3a0dff305… https://gitlab.torproject.org/dcf/snowflake/-/commit/4d4fad30c429bba9062d1b… https://gitlab.torproject.org/dcf/snowflake/-/commit/57c9aa3477513daf433476… ## Use more than one KCP state machine Though most part of snowflake-server are multi-threaded and can scale across many CPUs, the central KCP packet scheduler was limited to one CPU. Because we have a session identity (the client ID) separate from any KCP-specific identity, it's not hard to partition client packets across separate KCP instances by a hash of the client ID. Expanding the number of KCPs from 1 to 2 was enough to relive this bottleneck. https://gitlab.torproject.org/dcf/snowflake/-/commit/17dc8cad8299eae76c4019… ## Conserve ephemeral ports in localhost communication The pluggable transports model relies heavily on localhost TCP sockets. The number of users had increased enough that it was sometimes exhausting the range of port numbers usable for distinct localhost 4-tuples. The kernel's errno for this situation is EADDRNOTAVAIL when you try to connect; it manifests variously in different programs as "cannot assign requested address" or "no free ports," generally leading to a terminated connection. We mitigated this problem by having different programs use different localhost source IP addresses (e.g. 127.0.1.0/24, 127.0.2.0/24, etc.) to expand the space of distinct 4-tuples. In a couple of cases this was done in a hacky way that will need to be revisited, by hardcoding a source address range in the source code. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://gitlab.torproject.org/dcf/snowflake/-/commit/d8183ff9680ac9f92e888a… https://gitlab.torproject.org/dcf/extor-static-cookie/-/commit/0d9078d6aad8… ## Disable nftables connection tracking We took care of it before it became a problem, but we found it necessary to disable connection tracking in the firewall. The number of tracked connections was getting close to the limit, and past the limit, packets just get dropped. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…

1 0

Need to increase number of tor instances on snowflake-01 bridge, increased usage since yesterday
by David Fifield 30 Sep '22

30 Sep '22

There is increased usage of the snowflake-01 bridge since yesterday, likely related to protests/shutdowns in Iran. The 4 load-balanced tor instances, which recently were at about 60% CPU at the steady state, are currently near 100%. I am planning to increase the number of instances today. I am also seeing a lot of "no address in clientID-to-IP map (capacity 10240)" (dozens per second), so I will increase that parameter at the same time. After this, I don't think this bridge can easily sustain another doubling in traffic. It would be good to start sharing load with snowflake-02 sooner than later (https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl…) Here's a bridge-extra-info from a couple of days ago. (Remember this represents 1/4 of traffic.) Here `ir` is in about tenth place in users. https://metrics.torproject.org/collector/recent/bridge-descriptors/extra-in… ``` @type bridge-extra-info 1.3 extra-info flakey1 5481936581E23D2D178105D44DB6915AB06BFB7F published 2022-09-20 13:10:55 write-history 2022-09-20 03:48:24 (86400 s) 1530049041408,1515073429504,1571942788096,1624372588544,1540386311168 read-history 2022-09-20 03:48:24 (86400 s) 1508810912768,1497901086720,1553884182528,1606369537024,1525348965376 dirreq-stats-end 2022-09-20 05:10:35 (86400 s) dirreq-v3-ips ru=13792,us=1864,cn=1240,de=648,gb=384,??=368,by=368,in=280,fr=272,ir=272,ua=224,ca=168,nl=160,br=144,au=136,es=112,it=112,eg=96,sa=80,mx=72,se=72,ro=64,tr=64,ae=56,ch=56,pl=56,be=48,cz=48,jp=48,za=48,at=40,fi=40,id=40,kz=40,lv=40,il=32,kr=32,ph=32,ar=24,az=24,bd=24,cl=24,dk=24,dz=24,ee=24,hk=24,hu=24,ke=24,lt=24,ng=24,no=24,nz=24,pk=24,pt=24,sg=24,th=24,bg=16,co=16,ec=16,gr=16,ie=16,iq=16,ma=16,md=16,mu=16,my=16,si=16,tn=16,tw=16,uz=16,vn=16,af=8,al=8,am=8,ap=8,ba=8,bf=8,bh=8,bj=8,bn=8,bo=8,bs=8,bz=8,ci=8,cm=8,cr=8,cu=8,cv=8,cw=8,cy=8,do=8,eu=8,ge=8,gh=8,gn=8,gt=8,hn=8,hr=8,ht=8,is=8,jm=8,jo=8,kg=8,kh=8,kw=8,lb=8,lk=8,lu=8,ly=8,mg=8,mk=8,ml=8,mm=8,mt=8,mv=8,na=8,ne=8,np=8,om=8,pa=8,pe=8,pg=8,ps=8,py=8,qa=8,rs=8,rw=8,sc=8,sd=8,sk=8,sn=8,so=8,sv=8,sy=8,tg=8,tj=8,tm=8,tt=8,tz=8,ug=8,uy=8,ve=8,vi=8,ye=8,zm=8,zw=8 dirreq-v3-reqs ru=25256,??=4032,us=3040,cn=2408,de=1008,gb=616,by=608,fr=472,ua=472,ir=448,in=424,nl=304,ca=296,au=256,br=224,it=200,es=192,eg=136,se=128,mx=120,ro=120,sa=112,ae=88,ch=88,jp=88,pl=88,tr=88,cz=80,lv=80,ph=80,be=72,kr=72,za=72,at=64,fi=64,kz=64,id=56,no=56,ar=48,hk=48,il=40,lb=40,lt=40,pk=40,az=32,bd=32,cl=32,co=32,dk=32,hu=32,ke=32,nz=32,pt=32,sg=32,bg=24,dz=24,ec=24,ee=24,gr=24,mu=24,my=24,ng=24,si=24,so=24,th=24,tw=24,uz=24,am=16,ba=16,bz=16,cm=16,cr=16,hr=16,ie=16,iq=16,jo=16,lk=16,lu=16,ma=16,md=16,mm=16,rs=16,sk=16,tn=16,vn=16,af=8,al=8,ap=8,bf=8,bh=8,bj=8,bn=8,bo=8,bs=8,ci=8,cu=8,cv=8,cw=8,cy=8,do=8,eu=8,ge=8,gh=8,gn=8,gt=8,hn=8,ht=8,is=8,jm=8,kg=8,kh=8,kw=8,ly=8,mg=8,mk=8,ml=8,mt=8,mv=8,na=8,ne=8,np=8,om=8,pa=8,pe=8,pg=8,ps=8,py=8,qa=8,rw=8,sc=8,sd=8,sn=8,sv=8,sy=8,tg=8,tj=8,tm=8,tt=8,tz=8,ug=8,uy=8,ve=8,vi=8,ye=8,zm=8,zw=8 bridge-stats-end 2022-09-20 05:10:44 (86400 s) bridge-ips ru=18816,us=2984,cn=1720,de=1024,gb=640,by=576,??=496,in=488,fr=400,ir=400,ua=280,br=256,nl=256,ca=232,au=192,it=168,eg=160,es=152,sa=128,pl=112,tr=112,mx=104,se=104,ch=96,ro=96,ae=88,jp=80,at=72,be=72,cz=72,id=72,fi=64,kz=56,ph=56,za=56,kr=48,lv=48,az=40,dk=40,il=40,ng=40,no=40,pk=40,ar=32,cl=32,dz=32,gr=32,hk=32,hu=32,ke=32,lt=32,nz=32,pt=32,th=32,bd=24,bg=24,co=24,ee=24,ie=24,ma=24,mu=24,my=24,sg=24,tw=24,uz=24,vn=24,am=16,cr=16,ec=16,hr=16,iq=16,jo=16,kw=16,lk=16,lu=16,md=16,pe=16,py=16,rs=16,sd=16,si=16,sk=16,tm=16,tn=16,ug=16,ve=16,af=8,al=8,ap=8,ba=8,bf=8,bh=8,bj=8,bn=8,bo=8,bs=8,bw=8,ci=8,cm=8,cu=8,cv=8,cw=8,cy=8,do=8,et=8,eu=8,ge=8,gh=8,gn=8,gp=8,gt=8,hn=8,ht=8,is=8,jm=8,kg=8,kh=8,ky=8,lb=8,li=8,ly=8,mf=8,mg=8,mk=8,ml=8,mm=8,mq=8,mt=8,mv=8,na=8,ne=8,ni=8,np=8,om=8,pa=8,pg=8,ps=8,qa=8,re=8,rw=8,sc=8,sn=8,so=8,sv=8,sy=8,tg=8,tj=8,tt=8,tz=8,uy=8,vi=8,ye=8,zm=8,zw=8 ``` Here's another bridge-extra-info from about nine hours ago. Now `ir` is in second, third, or fourth place, depending on the metric. ``` @type bridge-extra-info 1.3 extra-info flakey1 5481936581E23D2D178105D44DB6915AB06BFB7F published 2022-09-22 13:18:22 write-history 2022-09-22 03:48:24 (86400 s) 1571942788096,1624372588544,1540386311168,1503769995264,1541499914240 read-history 2022-09-22 03:48:24 (86400 s) 1553884182528,1606369537024,1525348965376,1487172212736,1519574591488 dirreq-stats-end 2022-09-22 05:10:35 (86400 s) dirreq-v3-ips ru=13656,us=2120,ir=2056,cn=1384,de=616,by=432,gb=392,??=384,fr=288,in=264,ua=256,ca=168,nl=168,br=152,au=144,es=112,eg=104,it=104,sa=80,pl=72,se=72,tr=72,ae=64,ch=64,mx=64,ro=64,be=48,cz=48,fi=48,jp=48,za=48,at=40,id=40,kz=40,az=32,cl=32,dk=32,il=32,ke=32,kr=32,lt=32,lv=32,ma=32,ng=32,nz=32,pt=32,co=24,ee=24,gr=24,hk=24,hu=24,mu=24,no=24,ph=24,pk=24,tn=24,ar=16,bd=16,bg=16,do=16,dz=16,ge=16,hr=16,ie=16,iq=16,md=16,my=16,rs=16,sg=16,sk=16,th=16,tw=16,ug=16,uz=16,am=8,ap=8,ba=8,bf=8,bh=8,bj=8,bn=8,bo=8,bw=8,ci=8,cm=8,cr=8,cu=8,cv=8,cw=8,cy=8,ec=8,eu=8,ga=8,gh=8,gt=8,gy=8,hn=8,is=8,jm=8,jo=8,kg=8,kh=8,kw=8,ky=8,lb=8,lk=8,lu=8,ly=8,me=8,mk=8,ml=8,mm=8,mo=8,mv=8,mw=8,na=8,ne=8,ni=8,np=8,om=8,pe=8,pr=8,ps=8,py=8,qa=8,re=8,rw=8,sc=8,sd=8,si=8,sn=8,so=8,ss=8,sy=8,tg=8,tm=8,tt=8,tz=8,ve=8,vi=8,vn=8,ye=8,zm=8,zw=8 dirreq-v3-reqs ru=26032,??=4128,us=3408,ir=2792,cn=2784,de=960,by=664,gb=648,ua=592,fr=512,in=360,ca=280,au=272,nl=264,br=248,es=208,it=184,eg=176,mx=152,ae=144,pl=136,ch=128,tr=120,ro=112,se=112,jp=96,sa=96,fi=88,za=80,at=72,be=72,cz=72,il=64,kr=64,kz=64,az=56,dk=56,hu=56,id=56,lt=56,rs=56,hk=48,ke=48,lv=48,cl=40,co=40,ng=40,no=40,nz=40,ph=40,pk=40,pt=40,ee=32,ge=32,gr=32,ma=32,md=32,mu=32,sg=32,tn=32,am=24,ar=24,bd=24,bg=24,dz=24,ie=24,my=24,sk=24,th=24,tw=24,uz=24,cr=16,cy=16,do=16,ec=16,eu=16,hr=16,iq=16,lk=16,ly=16,mm=16,pe=16,si=16,ug=16,vn=16,ap=8,ba=8,bf=8,bh=8,bj=8,bn=8,bo=8,bw=8,ci=8,cm=8,cu=8,cv=8,cw=8,ga=8,gh=8,gt=8,gy=8,hn=8,is=8,jm=8,jo=8,kg=8,kh=8,kw=8,ky=8,lb=8,lu=8,me=8,mk=8,ml=8,mo=8,mv=8,mw=8,na=8,ne=8,ni=8,np=8,om=8,pr=8,ps=8,py=8,qa=8,re=8,rw=8,sc=8,sd=8,sn=8,so=8,ss=8,sy=8,tg=8,tm=8,tt=8,tz=8,ve=8,vi=8,ye=8,zm=8,zw=8 bridge-stats-end 2022-09-22 05:10:44 (86400 s) bridge-ips ru=18440,ir=5200,us=3624,cn=1880,de=984,gb=656,by=648,??=520,in=472,fr=416,ua=320,nl=264,br=240,ca=232,au=216,eg=176,it=160,es=152,sa=136,pl=128,se=120,tr=120,ae=104,ch=104,mx=104,ro=96,be=80,jp=80,cz=72,fi=72,id=72,mu=72,za=72,at=64,ng=64,kz=56,ma=56,tn=56,hk=48,il=48,pk=48,az=40,cl=40,co=40,dk=40,dz=40,ke=40,kr=40,lt=40,lv=40,no=40,nz=40,pt=40,ar=32,gr=32,ie=32,my=32,ph=32,sg=32,bd=24,bg=24,ee=24,hu=24,iq=24,rs=24,th=24,tw=24,vn=24,zm=24,cr=16,cy=16,do=16,ec=16,ge=16,gt=16,hr=16,kw=16,lk=16,md=16,mm=16,om=16,pe=16,sd=16,sk=16,tz=16,ug=16,uz=16,ve=16,af=8,al=8,am=8,ao=8,ap=8,ba=8,bf=8,bh=8,bj=8,bn=8,bo=8,bw=8,bz=8,ci=8,cm=8,cu=8,cv=8,cw=8,eu=8,ga=8,gh=8,gn=8,gu=8,gy=8,hn=8,is=8,jm=8,jo=8,kg=8,kh=8,ky=8,lb=8,lu=8,ly=8,me=8,mk=8,ml=8,mo=8,mt=8,mv=8,mw=8,na=8,ne=8,ni=8,np=8,pg=8,pr=8,ps=8,py=8,qa=8,re=8,rw=8,sc=8,si=8,sn=8,so=8,sr=8,ss=8,sv=8,sy=8,sz=8,tg=8,tj=8,tm=8,tt=8,uy=8,vi=8,ye=8,zw=8 ```

5 18