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

meek on Fastly/Akamai/other CDN
by ValdikSS 31 Jul '23

31 Jul '23

Hello, I found Meek-azure deprecation plan on anti-censorship team's gitlab. https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/33 From what I see in desktop Tor Browser, only meek-azure is available as a meek transport, and with its deprecation I assume no other meek transports would be available. As the deprecation is caused by removing domain fronting support on Azure, are there any plans to setup meek on other CDN providers which still support fronting, such as Fastly or Akamai?

2 1

Turkmenistan's tor users want you to change bridge's port addresses
by Ahmet Orakov 10 Jun '23

10 Jun '23

Hi, Turkmenistan authorities have been blocked almost all the networking ports. We want you to contact bridge operators and ask them to change ports of their bridge's to 8080 (available in our case) which I provide you below: Recently, most of the western and european media sites came under blocking in Turkmenistan. #Freedom to Ukraine #Glory to Heroes 808301E9950E572EBE79980285E8E7D78B16A618 cert=86M38pylZayLk2VKcizQg8w3GNFu5ZdFWW/MBS/ZCQ7AqjUiydamhscfhMFeTWtx2AULAQ iat-mode=0 B7E8B832F055435293840D69FE476AA6143C0449 cert=X2IIgewaeED2fctW8uSAd9NTsq8fP3uhsm7yS6QUC3k/NdXvEMtJelEz/t3X5SnmFCnHJQ iat-mode=0 7DC107121C944199FBF986F61A590B5911BCFD14 cert=OvTYJaLQNjv8cJ4Vj002aIhzBkP1LZSqFoU6nd5DBEyUnb2yCsAr0vvScUBsKotZ+E3SYw iat-mode=0 6C11CE58EA4D4C3C7EC078EBDC9D7D8961A58699 cert=q9W7JYmdRvQqs9MEa7rAKU5iNiu5zKtkyJPVH5aH61QRgcTrjtom58EoDnTnnlc37xNZPQ iat-mode=0 336BC480CB125457C0750840F3066AA3A547FCF1 cert=JcieuQi1sZw807G/GJUXdaTaQpECLwKAx72EUJLpGq/ofVPx8Z6ZCOY93YxCptmbq5PjMw iat-mode=0 9F0900762FEF3552F5E7617A6B52558B8BB2CAF0 cert=DX1Pchtj4I2EXhkQN1yryMl/6m8BlypZ+OH/Jj0Vo1yOIiAvun2sx1iEmdSkTgMrp4jUNw iat-mode=0 701BECA6C592D1168DDAD86FF50396629A0719A7 cert=T1JXGjxYb/gMfkqutgYylGC/seenQXw3xAgPP6sBWjczqQWCB2TIrrsokBBw3aoo208JUw iat-mode=0 7DE375B51781A17D247DB34A232AA7601BE1D706 cert=fYYGpWdrQrm3ulRuNP0yM97fTt0ZB5jWaUli9R8wmPzAuw0XfR85nnnRkXHIdYkUA3F5ew iat-mode=0 32A6ED70E38B4756F73AA6949A1ADC12F8076C67 cert=HbGyA+dK07sXAtwZqrJYgJhZw0+KiChGm6k0LLsVpaVEZr4NWpAPPK40/QWydBiqiD6dRg iat-mode=0 26E7ADAFD8ACB33A5696C74C8C8A6D6FDBB7CED6 cert=CaXOuzZW4ey7n/XpHw7mNHcKJiabY9HKgzM6K9jdUkkwq+PBR+aeDqrH1bOObbLwEOpzdw iat-mode=0 We appreciate your efforts! Best regards, Ahmet

1 0

Snowflake Mobile
by Rik Viergever - Murena 06 Jun '23

06 Jun '23

Dear all, I'm looking to get in touch with the maintainer of Snowflake Mobile for Android: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… I work for Murena (www.murena.com), we make 'privacy-by-design', open- source mobile phones. We would be interested to explore if we could support the Snowflake project by making it as easy as possible for the users of our smartphones to operate a Snowflake proxy. I did a small search online and then found the Snowflake Mobile repo. We would be interested to hear more about the current status of the app and its development and to discuss potential for collaboration. best regards, Rik -- Rik ViergeverPublic Affairs, Partnerships and Fair Tech +31 (0) 6 4289 3639 rik.viergever.ext(a)murena.com www.murena.com PGP: go to https://keys.openpgp.org and search for my email address

2 1

deprecation of git.torproject.org and obfs4proxy fork
by meskio 31 May '23

31 May '23

Hello, git.torproject.org is being deprecated in favor of gitlab[0]. We have moved all our projects to gitlab, and configured redirections in git.torproject.org[1]. If you use any of those repos please configure your git remote to use the gitlab one from the anti-censorship project: https://gitlab.torproject.org/tpo/anti-censorship/ We've being maintaining a fork of obfs4proxy, as some of the changes we need are not accepted by upstream[2]. As part of that reorganization of repositories we have renamed our obfs4proxy fork to lyrebird. So there will not be confusion between the original obfs4proxy project and Tor's fork: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyre… We are conscious that moving to gitlab opens up the space to more attack vectors, to reduce the need of trust on gitlab infraestructure we are working on a commit signing proposal: https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/8 Let me know if any of those changes are a problem to you and how can we help. [0] https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-36-gitoli… [1] https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/86 [2] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyre… -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

Port updation to 8080 is required for these bridges
by Ahmet Orakov 25 May '23

25 May '23

Hi, Please consider contacting bridge operators and ask them to change ports of these bridges to 8080. Turkmenistan's tor users need your help! Turkmenistan blocked almost all the networking ports, except the common ones (80, 8080) and to bypass censorship I want you to change ports of these bridges, cause the provided ports already have been blocked in Turkmenistan. 1714FC03DE40EAD9EDF20A10CAACDF6B6DFCF677 32A6ED70E38B4756F73AA6949A1ADC12F8076C67 A8E56244D112204C8632042AA776BC38D471285E Best regards, Ahmet. tor user

1 0

Turkmenistan's tor users want you to change ports to bypass censorship
by Ahmet Orakov 30 Apr '23

30 Apr '23

Hi, Authorities in Turkmenistan have already blocked almost all the networking ports, a few of them still alive. Please consider contacting relay operators in order to change port addresses of these bridges to 80, 8080 or 443 which I indicated below 6FC0828C5F2BF7231EF237184B168E1A55AFFDAE C60CAF61C9210E5BBF8FCEEF63D7638ED00092CD 1948FEF52897F6A25E456B7DB9C2D37EFB7250C1 7E59CD3DA76A403665ED162243327E6AE255411C DE131D27860718A95CF691948BC36FA16187DB2B CDA13CF52FFF3A70AEFB3A793B16DC2A63406531 3F32DE3EEAEDB3FC05AD8D42FFEF81FB930948DF 2C89244A2E4DE454D06DDBCEB239B233109A73A7 3E073BB0DDB25C7098DF00F49CC7186CC735203C B7E8B832F055435293840D69FE476AA6143C0449 035320676E125E1F85C68B1461E649DC7DA30C84 Best regards, Ahmet tor user from Turkmenistan

1 0

Turkmenistan's tor users face mass bridge blocking
by Ahmet Orakov 26 Apr '23

26 Apr '23

Hi, I'm Ahmet who actively spread active bridges (in our case) across the Turkmenistan. Recent days we face mass blocking and it create issues to surface freely on the internet. Authorities in Turkmenistan intend to restrict us from using tor browser and any other programs which can give access to the external world with the help of modern firewall equipment. Our team have managed to find reachable tor bridges, but problem remains on bridge's ports cause government in Turkmenistan blocked almost all the networking ports. Even reachable bridges by pinging may not often connect to the tor browser because of the port issue. Here is a few available ports which stay unblocked in Turkmenistan's case: 22, 53, 80, 8080, 443, 993, 995, 9999. Here is the full list of reachable bridges with port issue, and changing it's ports will help us to gain access to the external world. obfs4 108.31.127.213:8525 3EF93C217B2D5301FFBCC4880D24D09BD4401C61 cert=lx7lidZJdUriNMCjkSh/xcnVx2t67/KmXFe+YLXq+0bNba3STzmoBlJh+ERtzrnuuOrCTg iat-mode=0 obfs4 93.55.88.235:8081 13DDD2BED74D068AFF3EEE2B9D13C4E4D4667DDA cert=bez4elSLBpp58h6fml9ecJ/epgNWFFAE6YsXz41emzHE/YMCZaBsxPMtBcFA+JoxydDbag iat-mode=0 obfs4 207.188.167.189:45669 99941A7E1CF8C10FEDEDC3655608FD2F502B689A cert=772JkWjGxXoKMH+ptfhA9IArSCXFspI/FxJ8utA/AP1n0jssn4fAq/XacAax4/bJuhYDIw iat-mode=0 obfs4 207.172.185.193:22223 F34AC0CDBC06918E54292A474578C99834A58893 cert=MjqosoyVylLQuLo4LH+eQ5hS7Z44s2CaMfQbIjJtn4bGRnvLv8ldSvSED5JpvWSxm09XXg iat-mode=0 obfs4 79.114.110.223:7778 7DE375B51781A17D247DB34A232AA7601BE1D706 cert=fYYGpWdrQrm3ulRuNP0yM97fTt0ZB5jWaUli9R8wmPzAuw0XfR85nnnRkXHIdYkUA3F5ew iat-mode=0 obfs4 90.146.72.121:7985 D6699CA3CF1D8BA4246A15E5635824F52ABB127F cert=DgG3Mls043qsaI31mNTfc35yGcMSv9L9rOkTLINRC8fXrFNnGRWPvoeBKpQV/Snty+kVNA iat-mode=0 obfs4 75.134.106.30:35501 99C8AF7D79F8CA0D9D70F779503ECAA49F6C3FA2 cert=TlqfINuhMlbmoJhJ2mDISf/Eg8xHakPcPLBOC4usQTwzGCEagpOYuV4ZSs9t7rUCeBrtDg iat-mode=0 obfs4 92.194.180.141:42935 DE131D27860718A95CF691948BC36FA16187DB2B cert=D3++fMxl72GBW+/IyVBBDy8EIWSqy1jlO6xA10N6nsdOLlpQLvNSbY26jw9J3yKYiRG4Dg iat-mode=0 obfs4 81.174.32.138:45159 035320676E125E1F85C68B1461E649DC7DA30C84 cert=JxcDiqlANfYVzu34qeNkmCn0xOmd+SbqB42u9TbaoBRQkwyALZSx98cZeMMuZDevqmkxTA iat-mode=0 obfs4 177.104.92.101:25001 821CAED1A79AC1878B4ADEC0712E4DFC358768F4 cert=1TNR/XswmhC3if9+mBo6JS6gklBltC5T27s/3ffZj4v6F5gnAUXLbImBGBZCB9qhLSY5EQ iat-mode=0 obfs4 2.205.244.68:8888 B7E8B832F055435293840D69FE476AA6143C0449 cert=X2IIgewaeED2fctW8uSAd9NTsq8fP3uhsm7yS6QUC3k/NdXvEMtJelEz/t3X5SnmFCnHJQ iat-mode=0 obfs4 71.73.124.31:8887 F33989B6E8E3FFD37B6F764169B78ED0B83321F5 cert=FeLwuG61HwXuOXSYDxScC9K4nVp9GQdGVAdRUKilk3/0J2GsDyikvEhV/1ADpShsYQlSaw iat-mode=0 obfs4 187.75.226.94:8988 AF19883740E44E541795020EC59EC5F746851E19 cert=/n/ygNigvyPr5LVJfJoKd3JAuiSi9UnY61FzOCgqdCi1HD7WIGw6jR/mzLyJzhaLziT/JQ iat-mode=0 obfs4 92.221.111.176:1395 3E073BB0DDB25C7098DF00F49CC7186CC735203C cert=8KqBavNDfLHPMeB5HRxKDwliC7u5lI7e03xNU1/FZYrUK/+TDSSL5+osnkSOarfxHL/HAw iat-mode=0 obfs4 97.115.76.192:4343 AF7993FF8BDDD7F99AB26A09F9738414569BEF27 cert=MrF6L5jh+MqdVfoMfpz/QRhDl/yjqhxf24wjll4PBQKRe4OUXPJ+rESJcc5OGSTlLOAheg iat-mode=0 obfs4 177.73.92.19:5242 3FCF4978110BCE7AC92370BD9BD8E145F9630DFB cert=Z6wBTMa/gZDGWXSox0MYX6jW+zjNelKqvg3sYwZyIOY/Xkwflno554OhYNoQib3/ubjKdA iat-mode=0 obfs4 51.241.113.176:9003 661CACC60315EE3C67A1DA5D3F858819CE5F8BB8 cert=XiqiFAQR/83BbdxhUsN5G1C+QWUY2RVPwyPABlG53wT+tQHZwzMR0aFOQEeAK7d+FSzJDQ iat-mode=0 obfs4 188.27.166.105:61001 2D9B02D11541D942E3B1AB4B53B59A13EDC52689 cert=f6gO0qbkhh/rZ0lkiTr1ieH5t3EkXmCUISkLogB32VvhTc7KzWlCaBfSHYghGhpLBrliZg iat-mode=0 obfs4 217.86.148.59:10235 ECDE7860636D20A3374804FE8FF36D89B7AFE96D cert=O3GU2XtIUe6umRZqDk5uoHH1aP8zxqNLPF9l9oTMSknYnyI4XN81OA/UUIJN3d8Qf77NQw iat-mode=0 obfs4 79.116.39.249:32001 9DA2468ACD8BE06F66EBC62DFAE7042ABBBE6A45 cert=yi9MvwPMMG+SNhQGKRwCxsFogLWIUqMRfSAV4SRVNz9/scReT28qkNo4UXLfagK1a8OGLA iat-mode=0 obfs4 79.231.112.13:42893 3A76222696BA38823C43521FD604189A285D9859 cert=FR1z74IEj2chaLm4ztMtjnU1X4VfAAC6m6fPVSN37IggVKmhJqH0w81b1eEyYoBYDDAyZQ iat-mode=0 obfs4 92.211.9.209:1338 2C89244A2E4DE454D06DDBCEB239B233109A73A7 cert=jQcCwZNLeQV26cMposGJlhhUnKrYsHw6c60MAmEqEDiBy7GzZO3P3OJFBfla2UoJD0HPBw iat-mode=0 obfs4 88.152.121.42:18013 3F32DE3EEAEDB3FC05AD8D42FFEF81FB930948DF cert=uVHTPWVuScMjgw+xJl6JGkgTSkk84LbdT9XAH4V0d9qW0qBNlnxjld4vhKLOGSAkJrh6cg iat-mode=0 obfs4 86.119.0.151:25262 CDA13CF52FFF3A70AEFB3A793B16DC2A63406531 cert=veuTKH5BmSqP3Lbashf8DiprMXxenwTryXRVNKMqMJ+vL2lyC3rzQQQlVwaGgjv6UUU/QA iat-mode=0 obfs4 92.194.198.136:42935 DE131D27860718A95CF691948BC36FA16187DB2B cert=D3++fMxl72GBW+/IyVBBDy8EIWSqy1jlO6xA10N6nsdOLlpQLvNSbY26jw9J3yKYiRG4Dg iat-mode=0 obfs4 88.15.20.180:8024 8F0CCF3F6FDFE65A4341BCB8921D92DEFBBC57BA cert=Hs80aPMdaWhVSO7zQH99gJOgNX6QXibdj6i+bXoibFlvXsoU7a5q5BgCbjQeKVXh0aA1bQ iat-mode=0 obfs4 81.2.237.101:46688 2E80CA22679F0855612D4B5C6E14F515B8DBFEAC cert=OXOZwG0qx0UhHxawivrIj+W5Hv8+GWQrvZpZjDQarcwuuish16q6mFr/E3MJi9r6sKRrAw iat-mode=0 obfs4 173.75.228.117:7655 57DD323A976B78B7AB71297FA855A1DB5AA84E26 cert=Aqc+jkyQLxi29oxZcxxsMcExUz6B0UoWofBsLVxvK2T16QAnExVGDe0Ss4BAeYyxWz6hCg iat-mode=0 obfs4 86.30.100.123:42957 F3FA0D45D35E987484848345F8D92AB1D883889B cert=cxC0DfySYT/IBGBesOq64QKHCl5WdiR08qxcdsCpbpkj/2m6vwzpCFsP6m8r/+ZhdC26CA iat-mode=0 obfs4 72.65.246.86:19002 649B458222B1DB29DD1CFF0BF84DBD46019E260F cert=5JhfiNXzWL0gafmi6rFMtUo2Vb4MxN7ih7pNij6vlOhRvbh//rD57eDI4QPdUXaR6ZqSJA iat-mode=0 obfs4 143.177.166.29:9089 5B11A0A5E929354846930081B9F41184FCB0B9A8 cert=26lt8B0gaB9hyL7LEGPyYU3lz5uHAL+D7T0NsaVMxp7Q53f0WW5NneNMTPal5YUwG6ugHw iat-mode=0 obfs4 95.89.239.67:6433 6FC0828C5F2BF7231EF237184B168E1A55AFFDAE cert=2Lapv8zlsKDmheQsY+l4R/39dHT0TMe7mMN9ctkIacz2WgpKagfGiPLAUB+GUKG1Zg5sGQ iat-mode=0 obfs4 95.248.228.75:80 11790370D080C588C1CD210D55B58EF0C634191D cert=gYvzB9u82/ld5pyBigDmhAg23MfvIcJY3IXKu/hDf0bgb+6YsTKWGz/nmM7ZJsTvs9V3WA iat-mode=0 obfs4 88.193.230.188:34669 8A3153FCFADC2C3671A6996BF9C0DB28C8DC1792 cert=i0QTJIz6nV6kfY3q91Wa15JCEGRIn3mfMk1hLz/u0zQxEzre65xRzpoY5W5WBvNh/dIQTA iat-mode=0 obfs4 88.2.229.205:31417 393C21E212C6561DBB37CBC73ADE26CA475E7D0E cert=HGHYdF7SpYNgzCtxTAkD4rI2UESAcrSQ/Ak+pp6EVtFepZkWHQ+pmz5tF2Qx8pDH33FhDA iat-mode=0 obfs4 100.38.225.64:9958 202748B7A34254D6AFED0889FBAEE4A3DC7E7F56 cert=KXJT8LJNBQ+GPpTUccWBCNZNwd/X/pa8qpTLutYwtApljmK+N5NpM+WrCtlKyo4GJDFYLA iat-mode=0 obfs4 177.73.92.19:5242 3FCF4978110BCE7AC92370BD9BD8E145F9630DFB cert=Z6wBTMa/gZDGWXSox0MYX6jW+zjNelKqvg3sYwZyIOY/Xkwflno554OhYNoQib3/ubjKdA iat-mode=0 *Please contact and ask relay operators to update their bridges ports!* Best regards, Ahmet

2 1

Identify from which continent people connect from
by mxz+tor-anti-censorship-team＠mxzero.de 23 Mar '23

23 Mar '23

Hi, a while ago (10.02.2023) I tried to send an email on the tor-talk mailing list but apparently it never got through as it's still awaiting approval. (it wasn't denied either, afaik) So, I'll try my luck here as this is sort of censorship related, too. Copy and paste of the email: --- Hi, recently, there was an interesting side note on the cryptography mailing list [1]. Quote: > (People have written code to predict what continent an anonymous person using Tor is on, based on noticing over a period of time when their remote system clocks ran faster or slower, assuming that was caused by nighttime versus daytime temperatures.) I was wondering if any of you know about this and where I could find code that does this? Any links to research and papers would be highly appreciated, too. Especially, I'm wondering how they do this: - via differences in the above mentioned system clock (impressive?!) - timing analysis with latency? things like lower latency in Europe as there are more tor relays around compared to Argentina. - do you need to have any prerequisites? e.g. controlling at least one node, or the exit node, or a "clear text" server/hidden service that someone connects to? Finally, if that's the wrong list, please refer me to the right one. Thanks! [1]: https://www.metzdowd.com/pipermail/cryptography/2023-February/038109.html

3 6

Snowflake
by Jordan Hillis 22 Mar '23

22 Mar '23

I have a snowflake link embedded in my website www.computerrepairjs.com

1 0

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

16 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

2024

2023

2022

2021

2020

2019

anti-censorship-team