[tor-dev] Blocking-resistance in I2P (Was Re: Hello, I am a Tor Browser user in China. Currently, many obfs4 bridges are blocked by China's firewall.)

[str4d <str4d@xxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Yawning Angel wrote:
> [Folding in the 2nd reply]
>> If you know some details of how I2P resists blocking, please add
>> them to this wiki page: 
>> https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports
>
>> 
> It doesn't do anything special.

Yet (see below).

There are several reason for I2P not being blocked as much as Tor:

* Traffic - I2P is used by fewer "clients" (tens of thousands) than
Tor (hundreds of thousands to millions).
* Content - I2P doesn't provide easy access to clearnet resources like
Tor does.
* Easiness - non-bridged Tor uses TLS as its outside protocol, and can
therefore be easily identified using standard TLS identifiers for
firewalls. Identification of I2P traffic requires special-purpose
identifiers (which do exist, but add to the maintenance burden of the
firewall).

Thus, blocking I2P currently provides less value-for-effort than
blocking Tor.

> 
> The old TCP based protocol (NTCP) is trivially identifiable.

We have been (slowly) working on NTCP2, a replacement for NTCP, for
nearly 2 years now. We have two different proposals on the table [0],
and are also considering the benefits of the mutual-authentication
variant of Ace [1,2]. Anyone here interested in protocol design is
welcome to add to the discussion!

> 
> Blocking the more modern UDP protocol (SSU) would require looking
> for high-entropy UDP or doing statistical attacks IIRC.  Active
> probing is possible if they run a node that's part of the network
> and obtain enough key material (But, I'd need to look at the
> floodfill system again to figure out how many nodes for how long is
> realistically required).

Active probing of this kind essentially requires that the adversary
enumerate the entire netDB, because geographical information cannot be
used to index into the hash table. We estimate there to be about 750
floodfills at present, so it's not outside the realms of possibility.
However, in practice it isn't really viable:

* By default, routers in China (and several other countries, picked
based on the Press Freedom Index [3]) start in hidden mode, meaning
they don't publish their details in the netDB. So harvesting attacks
will not pick any of those up, and therefore won't be useful for
matching the source of UDP packets.

* I2P routers actively measure the performance of their peers, and
make routing decisions based on their measurements. If an adversary
dropped UDP packets based on matching their destination to the
harvested netDB, the router would simply use other routers that aren't
being blocked.

The most vulnerable point in the system is actually the reseed servers
- - blanket blocks on them can prevent a router from finding any initial
peers. However, if a router can connect to a reseed server, it has a
good chance of being able to connect to the network (HTTPS with
certificate pinning prevents snooping on or modifying what peers a
router is given).

Now that I think of it, the reseed system would be an ideal location
to start introducing PTs into I2P. We have been thinking about how to
leverage PTs in inter-node communication for several years, but
reseeding over PTs would be much easier to implement and would provide
noticeable benefits (making blanket bans much harder).

str4d

[0] http://zzz.i2p/topics/1577-ntcp2
[1] https://moderncrypto.org/mail-archive/curves/2014/000151.html
[2] https://moderncrypto.org/mail-archive/curves/2014/000163.html
[3]
https://github.com/i2p/i2p.i2p/blob/master/router/java/src/net/i2p/route
r/transport/BadCountries.java
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWDc+cAAoJEBO17ljAn7Pgoq8P/iI2+qr6b65dYPpGCk8R2XA4
Dq2PxpjGX6n74PW96DWg7eHGGjCPLh22SnGSDoU7l6mDCAM9u7BTh1j/se5uMzuh
6Y2z3dml5L+I+JXd+WdqGQK8gFkAMXrVMc9waEY8bKC1/ENssUXBlN1Jfm3lcttj
BirJxyc7c14EX2gHsMLE/cbgeVUl+sf4/A2cXqjLmlnrUSiGRBPx7AAU/fPbSA0P
JgvYvbUQ0NCly8BSZkQRL5qh01DuF9ZD39JkOAvy+N0pW0EoCPjLVGsdY4RjWnSZ
zQF2IJoig35gi6Tqxk/jUS1b6+hoCacTN7Ly00WAykAjJqFF5OfIaD60HJizdlbX
5aAwncAJhaddaMVpekp4zBhjI07gvZW9k3Nzjy6yRcBGYxg96PU5fedk37HTMcyu
Ixpi2hu84FHDwE8YVfTVw9yrDzkp0azVsgS0CwJSONtrpfKDcU3z9L928N/abdMS
d7OBJo3omPfMmjMyGjqjQ0+348oTVarEV4hfqDIICbvIPfXRWkGKRMcNEXbjcg+f
+5gISZpZ+FX9UiyhWm4MP+B+fcyvT/QO5/wH0B1k9rBYO+1VUAFNKkzqBxqOy1QM
166irImK9kh5OTtdxww7guYx+h5zLOJSB3tcnEG5Ksu3rCY7iEnVV2C6bb8Irpg1
ItGd4ak9UDVtFN2HY0OX
=oTAv
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev