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
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
