On Jan 31, 2008, at 11:57 AM, Michael Rogers wrote: > OK... so we're essentially creating a map of the network, identifying > subnets and numbering them? For local subnets we check which of our > immediate peers can reach which others, and possibly override the > network > IDs they advertise - for remote subnets we just trust the network IDs > learned from successful replies?
Yes. > If a peer reports that it can reach subnet X and we don't have any > immediate peers in subnet X, how can we verify that information? I'm not sure it's possible; and restarting a request in such a way as to escape to/find a different network may have unforeseen security implications. If one of our peers claims to be able to reach all the known networks in existence. From the perspective of a node (after the failure of a request in the local network), what better could be done than handing it off to this peer ala "try to get this apart from network 'x'"? > [...] but how do we determine reachability beyond our immediate peers? We don't; like any other freenet algorithm, it only works if enough nodes follow this pattern. In this case, particularly the nodes at the border of a subnet/dungeon in order for them to be colored properly. >>> How do you prevent an attacker from >>> forwarding pings but dropping (selected) requests? >> >> I think that this is a fundamental problem even now. > > Absolutely - I'm not trying to say that your proposal is causing the > problem, only that it doesn't seem to solve the problem unless the > attacker > behaves. >> [...] > Yes, exactly - they are part of the same network as us, they don't > appear > to be a dungeon/rabbit-hole/separate-network/whatever, and therefore > they > can persuade other nodes in our network not to occupy a certain > region of > the key space. > [...] > As I understand it, your proposal is meant to allow each subnet to > occupy > the whole key space. I'm imagining an attacker who wants to exclude > non-attacker nodes from a region of the key space. So our goal is to > identify the attacker's subnet; the attacker's goal is to avoid being > identified as a separate subnet. Unless [in a later implementation] DNFs (maybe weighed against HTL) become an indication of a separate network. Then it would do precisely that. >> No, no... advertising in the sense that a network location is >> presently 'advertised' it is a single value that we remember per- >> peer, >> and not a thing to be flooded or forwarded. For each peer-node we >> would now additionally need to remember four things: >> (1) a CRAM-UID, >> (2) a CRAM-Secret, >> (3) a network-id-they-advertise, and >> (4) a network-id that we assign to them. > > OK... the CRAM-UID and CRAM-Secret are for the challenge-response > protocol > you described above? I'm still not sure why peers need to advertise a > network ID if we're going to assign them one based on their > connectivity to > our other peers... what am I missing? That following the algorithm will eventually color the entire network/ subnetwork/dungeon with the same network id, which is presumed necessary for any sort of distant routing. >> Admittedly, the routing-to-a-distant-network portion is the weakest >> portion of this idea; Matthew has called it 'escape routes'. > > OK, so if we're not going to route to other subnets, what's the > purpose of > network IDs? Just to avoid routing to peers that aren't well- > connected to > our other peers? (Not that that's not useful, but it seems like it > could be > achieved without network IDs.) The first step is identification of the problem, no? Give each well- connected network it's own network id (self-governed and determined by the peers inside it). >> I suppose that if this were to be >> implemented as proposed, we would need a separate LRU per peer, and >> some kind of probabilistic filtering with respect to the net id's we >> forward (e.g. only if it is our network-id or is "established"?). > > I still don't see, in general, how you can distinguish between distant > subnets that really exist and distant subnets invented by an attacker. I don't think that you can. The only thing that a particular node can be sure of is it's peers. Distant routing of a request in this case amounts to a node saying to it's peer, "this request has failed on my network (... and network x, y, z), *you* claim that you can reach network 'w'... go for it." Even if the request succeeds (and purportedly carries with it a label from network 'w'), we can be reasonably sure that it is not on *our* network (we tried, it failed). So now we'll tell our peer's that we can reach network 'w' (through this peer w/ that success). Even if it is a Sybil-simulated subnetwork, routing to it (and perhaps wether or not we advertise it to our peers) will probably end up being related to success- probability; they could only become relied upon by providing good data (not censoring), why not use the Sybil net for storage, then? We would presumably still only insert into our network (or that is, not try to reach a distant network), it still has to escape dungeons. > (This is a different attacker from the one that wants to occupy a > region of > the key space, BTW - this one's goal is to make you search a large > number > of nonexistent subnets before giving up, and possibly to stop you > discovering real subnets by flooding your routing table.) > > Cheers, > Michael Great ideas, great discussion! -- Robert Hailey -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080131/011b66ca/attachment.html>
