-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, we can argue about how something with 5 days per hop latency would work, and it would be interesting to hash out the details. Its not likely to be part of either Freenet or I2P within the 2 year horizon though, so I'm not sure how worthwhile it'd be to discuss right now.
> > How do peers in the 'A' group find out about peers in the 'B' group? > > Through existing trust relationships. 'B' would be peers run by groups > > like rsf who already have trust networks with people on the ground, or > > by western friends of people in the 'A' group who want to help out. > > Who's rsf? [1] http://www.rsf.org/ > A is the open, western, free (hah!) I2P network. Harvestable. > B is the group of semi-closed I2P nodes in the west. Non-harvestable. > C is the group of closed I2P nodes in the non-free Rest. > > A node in C which wants to talk to a node in A will construct a tunnel > which goes to, firstly, a node in B to which it is connected. The node > in B is a "client router", so it can connect to any node in A directly, > but is not in the netDb; this is similar to a "transient node" :). Right, though B may in turn use connections to other nodes in B for its own tunnels. > Then you garlic through A as normal until you reach the destination. > Right? I'm not really sure what this means. Here's how it'd work - a router in C would build, for instance, a 3 hop outbound tunnel, using a peer in B as the first hop, and peers in either A, B, or C as the second and third hop. Its likely that peers in A would be chosen, as the performance of routing through peers in B or C would be worse (since they require transmission down their O(1) hop tunnel instead of directly). The peer in C now has a 3 hop outbound tunnel, and they repeat the process to build a 3 hop inbound tunnel. When they want to contact Bob (a destination connected to a router in A, B, or C), they do a netDb lookup through their outbound tunnel, which includes instructions for the reply to be sent back through their inbound tunnel gateway (which my be in A, B, or C, but probably A, since, again, they'll be profiled better). Now the peer in C knows Bob's inbound tunnel gateways. (The above only needs to be done the first time C wants to send a message to Bob - subsequent messages can use that leaseSet or the leaseSet piggybacked with Bob's responses) The peer then wraps a garlic message to the public key published in Bob's leaseSet, builds a tunnel message targetting one of Bob's inbound tunnel gateways, and sends it out one of the router's outbound tunnels with instructions for it to be forwarded to that gateway when it reaches the outbound tunnel endpoint. Again, when it reaches the endpoint, which may be in A, B, or C, but probably A, it will see "ok, here's a garlic message targetting tunnel X on router Y". It then sends the message to router Y directly, if it can, or if Y (one of Bob's inbound tunnel gateways) is behind a restricted route, it sends it through one of Y's published router tunnels. Once it reaches Y, it is forwarded down tunnel X to Bob. Make sense? > (Whether this will work in practice remains to be seen; it would seem > to me that it would get major incentives inversion problems i.e. > leaching). Peers in B don't give out their contact info to just anyone - they give them out to people they have a trust relationship with. > (Someday you must explain why an everyone-to-everyone mixnet isn't > vulnerable to traffic analysis on tunnel setup BTW, I'd be interested > to know as it's been relevant in our own explorations of premix routing; > we won't be implementing premix in 0.7.0) Well, it isn't /inherently/ invulnerable to traffic analysis, but you can take advantage of a whole bunch of research on batching and mixing strategies [2]. I'd love to discuss some of these down the line, as we'll be working on those for Syndie, so we can hash through different ideas and see what'll work best. [2] http://www.freehaven.net/anonbib/ > Freenet 0.7 doesn't use exploratory routing either; routing is set up in > advance by swapping locations, for more info see the DEFCON slides. What I mean by exploratory routing is routing with a length that depends upon the network's size and capacity, which the greedy routing algorithm proposed does. You will not always get through to the first choice hop at each step (unless you're willing to sacrifice latency by waiting), so at each hop, you may need to swing over to a less close peer who will hopefully be able to get through). This, of course, assumes a perfect closeness metric. Again though, a comparison of Freenet/light and I2P's routing is something I'm sure we'll discuss once Freenet/light is implemented and we can discuss facts. > > > > Though at the scale such a network would run at, the anonet thing > > > > would probably work fine. > > > > An OSPF VPN - http://anonet.fshell.org/ > > Redb3ard's network? Very hard to use, probably doesn't scale, has some > anonymity issues... otherwise a great idea. Right right, great with trusted links up to the scale which OSPF or BGP can work, and its very cheap to implement, since it requires little to no code. I'd probably look into helping simplify the user interface to that if my goal was to help those in hostile regimes - maybe a DSL [3] build. Or perhaps into ways to help OSPF or BGP work better for them. [3] http://www.damnsmalllinux.org/ > > I'd love to hear some details of how you could automate such plausible > > activity in an open source project without giving an adversary a map to > > detect it. > > Piggybacking on real traffic, perhaps? You make it sound so easy. Perhaps it is, but if so, why is there nothing out there either using it or describing workable techniques for low latency high bandwidth comm? > > Thats exactly what I'm /not/ saying. As we've discussed, I2P and > > Freenet/dark offer the same level of obscurity. The difference is that > > I'm not calling it a scalable darknet, because it isn't. > > The difference is that freenet 0.7/dark can provide a system which > should work even in the absence of a large open network. Ok, so you now agree that Freenet/dark and I2P with restricted routes both offer the same amount of 'dark'ness as long as there is a West? I'm not going to argue about what happens once there isn't a West. We will have bigger fish to fry before we reach such a point. =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDTrC0WYfZ3rPnHH0RAhTVAJ9n0U18HihZUH8GP+R10BxHD/NLdgCffJF6 lxdKwy2YiWv/08qXoQxi7lA= =4Mgj -----END PGP SIGNATURE-----
