On Thu, Oct 13, 2005 at 03:17:00PM -0400, jrandom at i2p.net wrote: > -----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.
It would probably be lower than that on average, but certainly some hops would be a week latency. Probably most requests would have 6 hops at most for success... more with premix. The point is that the dark-freenet architecture has a future. It will be usable as-is until they do signature analysis; it will be usable with slight modifications until they do local traffic analysis; it will be usable with more substantial modifications until they do ISP-level traffic analysis; it will be usable in the long term with whacky transports such as the below, in MANY places. And many places won't get beyond the harvesting and signatures level. The basic technology is interesting. > > > > 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? I think so. > > > (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. So some peers in A have a trust relationship with peers in B? You haven't answered the point, anyway - client nodes are supposed to be able to contact anyone, right? > > > (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. Ahh, okay. > > 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? Initially, wrapping it in VoIP or whatever will be enough. After that, we may have to sacrifice "low latency", and to some degree "high bandwidth". Provided that we do this, it *may* be possible to disguise traffic. > > > > 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? Well... Some things we need to get straight in order to make a proper evaluation: - A node in C will only connect to a node in B which it has a trust relationship with. - A node in B will only connect to a node in A which it has a trust relationship with. - All chains from C start C, B. The second hop, outgoing, is always in B. No? - If so, this would mean that all nodes inside the Wall must be directly connected to nodes outside the Wall. - Both traffic analysis and traffic sanctions (as opposed to arresting people) are *much* *much* easier on the border. Freenet/dark could have a substantial internal darknet; this is not possible with I2P, correct? - If a node in C wants to talk to another node in C, it will probably have to go through not only B, but also A. Correct? This is what I mean by "parasitic". It has impact both on security and performance. If B is a scarce resource relative to C, it has a *serious* impact on performance, and therefore on usability. It also has a significant impact on security, in that EVERYTHING has to go over the border at least once. Are my assumptions above, and my analysis, reasonable? > > 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. Guns aren't everything. Information matters. And I don't believe that prohibiting anonymous p2p would necessarily be perceived by the public at large as a significant step towards despotism. > > =jr -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20051013/d8f4a54c/attachment.pgp>
