[mnet-devel] Grid Of Trust -- pre-design
Jim Dixon
jdd at dixons.org
Tue Dec 9 14:42:11 GMT 2003
On Tue, 9 Dec 2003, [iso-8859-1] Some Guy wrote:
> > I don't think that DOS attacks at the IP level are properly part of this
> > discussion. DOS attacks are already a permanent feature of the landscape,
> > and in fact are already dealt with using spiffy p2p networks: network
> > operators use OSPF and sometimes BGP announcements to get rid of them,
> > these announcements being shared among OSPF/BGP-speaking routers organized
> > in p2p networks. Both protocols support blackholing traffic from and to
> > specific IP addresses.
>
> I've wondered if P2P could learn a lot from how OSPF/BGP work.
Definitely. OSPF and BGP4 represent the results of decades of experience
in routing traffic over unreliable networks populated with lots of bad
guys. They work.
> Company A requests a X bandwidth leased line to company Company B.
> They both call up their providers and they take care of it. The line
> always supports X bandwidth even if other lines coming into the
> company get flooded. Now imagine automating this process to remove
> the phone line and sharing one physical cable. The main difference to
> TCP: connections must be initiated on both ends.
This is a bit mystifying. What are you sharing the physical cable with?
You say there is a difference between something and TCP. What is the
something? What process is being automated?
I think that you are probably trying to describe a standard service, a
channelized circuit. In Europe a 2M E1 will be sliced into 32 64K
channels, which can be assembled into higher speed services, say one
128K circuit, two 64Ks, one 512K, and one 1M. If you like you can run
data over some circuits and voice over some others. Is this what you
are talking about?
> > > > > The solution I see is for friends to build small cliques of nodes
> > > > > which we can call "super nodes" which then act as a single node in the
> > > > > described network. If a super node has enough independent IPs so that
> > > > > it could give out one to every neighbor, it would be safe against
> > > > > floods.
> > > >
> > > > On the face of it, this just doesn't make sense. Explain, please. Just
> > > > how can I loan my IP to the guy across the street?
> > >
> > > You and your 15 quake buddies decide to start a node. One guy runs
> > > the master and picks p and q and gives you guys N. Everyone can take
> > > a shot and calculating the hash cash. Only the master need have the
> > > private key though. Then one of you bootstraps in using that
> > > identity. Every few neighbors you learn about are given a different
> > > IP to connect to.
> >
> > Where do the IP addresses come from? And why can't the bad guys just DOS
> > the entire lot? There are techniques for doing this that require very
> > little bandwidth.
>
> The bad guys won't know more than 1 of the IPs of the super node.
> Each super node talks to each other one over just 1 of its IPs.
But where do the IP addresses come from?
> > If I understand your scheme correctly, someone is going to have to acquire
> > a routable CIDR block. This is at the very least a /24, a block of 256
> > addresses. Those addresses have to be handled by a router. That router
> > has to have bandwidth to the Internet. Who pays for all of this?
>
> No, I have a sub node at my place, and my buddy Bob has one at his.
> We might have completely different ISPs. I give my IP out to half the
> of our nieghbors; he the other half. If I get flooded, he'll still
> function.
Then how do you talk to one another?
> > Consider two scenarios:
> > * Scenario 1: anyone wishing to join the network has to tie up his
> > machine(s) for at least an entire day; in one of your proposals, for
> > a day out of every month. Chances are good that the first time you
> > do this you screw it up, so it takes two days. For some people, even
> > more days.
> > * Scenario 2, anyone wishing to join the network has to either
> > (2a) go to a Web server and sign up to an existing trustnet
> > (2b) round up some friends (by email?) and set up one by adding IP
> > addresses to a list
> > Total time required: minutes.
> Right so and adversary with a bunch of K times your resources can do K
> of them in "minutes". How do you plan to limit participation in your
> magic Byzantine protocol, hash cash :-P? All an adversary has to do
> is boot up a million times and keep the spot he's happiest with.
What spot? If we are talking scenario 2b, why should you and your friends
let him in? You don't know him.
If we are talking scenario 2a, well, somehow this network has grown to a
considerable size. They use perhaps some sort of system whereby new
members have to be vouched for by existing members. I would expect there
to be many many different systems for clearing new members. Over time,
some would prove better than others.
> The only thing I see you limiting him by his his number of IPs. Is
> that you're whold big argument:"let's use IPs as a limit instead of
> CPU or drive space"?
My real argument is that the big flat p2p networks that were proposed
around 1999-2001 are sitting ducks, easy targets for adversaries with any
resources. The next generation of p2p systems must be small, fluid, hard
to hit. In military terms, the old-style networks are like Saddam
Hussain's big, soft, clumsy army. New network architectures must be more
like al Quaida, built around personal trust. They should be easy to
build, so that you think nothing of throwing them away. They should
expect and react gracefully to attacks, fragmenting if necessary. They
should be modular, so that if a better way of solving problems comes
along, you can just plug it in. All of this makes it difficult for an
adversary to see them, let alone take action against them.
> > > Hmmm, I may have an alternative idea to use storage space instead of
> > > pure CPU. Maybe you'll like that better. I'll try to think it
> > > through a bit more.
>
> > Go back to the Sybil paper, which considers using storage space and
> > decides that it cannot work.
>
> You go back to that paper. You're the one claiming that you can
> magically use some mysterious protocol to limit identity. I'm
> claiming exactly as the paper that you can use limited resources to
> limit an adversary, but it'll never be perfect; they can always
> generate identities proportional to thier resources.
I have never spoken of perfection. Neither does the paper. What the
paper does say is quite specific: no method like hashcash can prevent
Sybil attacks. A separate certification authority is required to do that.
The paper is from Microsoft, so they suggest a single central authority.
I am pointing out that individuals can build their own certification
authorities. They won't be perfect. Most will be badly managed. Some
will be owned by the Bad Guys. But if there are a lot of them, this won't
matter at all.
> > > If you've got some better idea to randomly assign nodes jobs, feel
> > > free to suggest.
>
> > Cluster of N authentication servers using a Byzantine protocol.
> > Initially set up by acquaintances. Other people can choose to use the
> > cluster. If and when its reputation is compromised, they can set up their
> > own clusters. Some clusters will become well known, trusted, and very
> > large, providing excellent cover for those seeking anonymity.
> >
> > There will be many clusters, most quite small. That is, there will be a
> > crowd of clusters, providing excellent cover for those seeking anonymity.
>
> So how do I know which cluster has what part of a global DHT? Does it
> tell us and we trust it? Are you still tring to build a global DHT,
> or is this a solution for some other problem?
But I have _never_ suggested building a global DHT. What I have suggested
is designing an infrastructure that can be used to implement p2p networks
of all sizes, using a variety of techniques.
The large clusters, of course, will doubtless be global DHTs. But they
will overlap, with many people belonging to more than one cluster - and
casually copying data from one to another.
If the objective is anonymity, this is how to attain it.
--
Jim Dixon jdd at dixons.org tel +44 117 982 0786 mobile +44 797 373 7881
http://jxcl.sourceforge.net Java unit test coverage
http://xlattice.sourceforge.net p2p communications infrastructure
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
mnet-devel mailing list
mnet-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mnet-devel
More information about the Mnet-devel
mailing list