On Fri, Oct 14, 2005 at 08:49:03AM -0400, jrandom at i2p.net wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Well, my stock answer is that I2P is harvestable, and this is the > > fundamental problem that we seek to rectify. > > Hrm, but for the reason's we've discussed over this epic thread, > your stock answer is not correct. I2P's restricted route topology > isn't something new, its been on the roadmap as I2P 2.0 for the > past 2 years. You need a new stock answer ;) > > > > Some may choose to connect with only trusted peers in A, while > > > other peers in B may choose to connect with a wider selection of > > > peers in A. That is, in addition to connecting with peers in B > > > or C (for those peers in C which it has a trust relationship with). > > > > But since we source route, they must publish this information if they > > choose to only connect to a few trusted peers, correct? > > Peers in B which need to be reachable by peers they do not have > connections with need to publish their routerInfo, which has either > their direct contact information (IP, port, etc) or their indirect > contact information (tunnel gateways they can be reached through). > For trusted scenarios, the routerInfo could be sent to a peer without > publishing it in the overall netDb, but that peer would then > technically be able to republish it again to the overall netDb > (though doing so would likely violate their trust relationship)
Well, it is published to the nodes that the B peer serves, which it trusts. > > > > > - A node in B will only connect to a node in A which it has a trust > > > > relationship with. > > > > > > Not necessarily. Its up to B to decide. Depends upon the threat model > > > of B and the peers in C which it is helping. Not all peers in B have > > > to be controlled by the same organization. > > > > Or any organization-as-such. So B's can directly connect to A's, or they > > can connect only to trusted A's, and then have the trusted A's be the > > first hop on an onion chain to wherever they want to go. > > Right. > > > On the whole, a node in B will not know many nodes in B, but will often > > be able to contact all A's; > > I'm not sure why you say that. If B1 is a peer who only uses trusted > connections to peers in A, then there's no reason to assume the peers in > B it contacts are fewer than the peers in A it contacts. Okay, so what are you saying? That not only does B1 tell C1 its connections, it also tells it the connections of the peers that trust it, and so on, out as far as possible? And then we can onion route through B from C1 to C2, provided a trusted path exists? > > > even if it can't it will usually go through A even to contact C2, > > because it is possible to route through A, correct? > > Depends upon performance - the tunnels are rebuilt based on what > works best. There's code to allow the user to explicitly specify > what peers they want to use in their tunnels too, but I don't tell > people about that, as its hard to use and has anonymity issues, but > may be useful for trusted links. > > > > > - If so, this would mean that all nodes inside the Wall must > > > > be directly connected to nodes outside the Wall. > > > > > > Peers in B may be within the Wall, with peers in C contacting them. > > > > No they can't. Remember that all nodes in A are blocked by the Wall. > > We could split B up into B1 and B2, and have B1 behind the Wall, > > and B2 in the Free World. In which case B1 would have to either: > > a) Publish its connections to B2 to C or > > b) Transparently relay through B2 to A > > Exactly - option 'b'. When C1 tells B1 to send a message to A1, B1 > has the liberty to do so however it feels is necessary. If B1 > cannot talk to A1 directly, it will use its tunnels through B2 (etc) > to do so. Okay, so we have an onion of C1 -> B1 -> A1 -> A2. C1->B1 is 1 hop. B1->A1 can be many hops. This is a prearranged tunnel; these are "exploratory" in your terminology? A1->A2 is of course 1 hop. > > As mentioned before, however, B1 could optimize C1 a bit by giving > it profiles ranking B2 up further (acheiving your option 'a'), but > doing so is not necessary. > > > So most of the time, any contact between C1 and C2 will go through > > A. Yes? > > Whatever the profiles say. If the tunnels through A are incredibly > lossy or congested, tunnels not using A would be used. Hrrrrrrm. But this means you are doing some sort of restricted routes routing, right? How does that work? You can't have prearranged direct tunnels from anywhere in B to anywhere in B, so you need an actual routing algorithm. How do you propose to do this? Publishing the entire network topology to trusted nodes? Or what? > > > If C1 wants to talk to C2 without going through A, the only way > > to do this would be for all the B's to publish their connections > > (stripped of IP addresses) to all C's directly or indirectly connected > > to them. This does not scale, but might still work for plausible scales. > > Is this the idea here? > > No, see above. See my reply - you seem to be saying that you can do routing entirely within the trustnet, I would like to know how you plot these routes. Well, I can deduce a certain amount: The actual garlic chain will be more or less free-form - but lets say a trivial one is C1 -> B1 -> C2. Then B1 is responsible for getting to the C2. C2 is in the database, with a set of tunnels from various nodes. Probably one will be in A, but some will be in B. How do we get from B1 to B2? You are glossing over some magick here. It looks like if this is going to work you will have to develop a darknet routing algorithm of your own. > > > > > - 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? > > > > > > Not necessarily, but probably. > > > > 99% sure, from what I've seen. Unless the first B has a connection to > > C2, it's very unlikely that it won't go through A. > > Depends on the profiles (as above). It seems reasonable to assume that the first B won't have a direct connection to C2. It seems equally reasonable to assume that there won't be a pre-existing tunnel from B1 to C2. Therefore, either we route through A, where we can route freely, or we route through B, which requires some sort of trust-network routing algorithm. Which means that A is not strictly necessary, but it also means that you must solve one of the big darknet problems - if only by sweeping it under the carpet (publishing the topology to those nodes involved and imposing a maximum size limit to keep update traffic reasonably under control). > > > Well... how does the network grow within the Wall then? New C's > > have to be introduced to existing B's... > > Wetware, or whatever human trust networks exist. > > > Your topology is highly parasitic. Most data will have to go > > through A, meaning that most data will have to go across the > > firewall. > > Depends on the profiles. But its true that the peers in C aren't > likely to contribute much in terms of bandwidth or CPU power to > peers in A, but peers in B think their contribution in terms of > content and liberty is more valuable. Peers in C wouldn't do > filesharing, they'd do email, some browsing, and some content > publication (syndie). If they needed to push some bulk data (1GB+), > they could technically do so, but it might be worth talking to the > trusted person to see if another means of transport could be > arranged (sneakernet, etc). I'd like to understand the reasoning behind this; see above. -- 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/20051014/a6558153/attachment.pgp>
