[mnet-devel] Grid Of Trust -- pre-design

[Some Guy]

 --- Jim Dixon <jdd at dixons.org> wrote: 
> On Sun, 7 Dec 2003, [iso-8859-1] Some Guy wrote:
> > > > The real problem is flooding on the IP level.  If and adversary can
> > > > pop in and get the IPs real quick, he can flood any of the nodes he
> > > > wants.  Maybe someday ISPs will give us a solution to this problem.
> > >
> > > Another assertion that needs some proving.
> >
> > I was hoping you'd jump in with some ideas.  You know way more about
> > ISPs than I do.  I could imagine an ISP requiring proof that an
> > incoming connection is approved.  Such certificates would have to
> > exchanged out of bound (or across a spiffy P2P network).
> 
> 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.

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.

> > > > 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.
 
> 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.
 
> > > > That does however get you past your hash cash problem for new users.
> > > > A new user wouldn't need to burn a CPU*day, if he just joins someone
> > > > else's clique.
> > >
> > > Oh, we are dumping hashcash, are we?  That's good news.
> >
> > Someone has to do the hashcash or something that produces a random
> > result and costs something.  You can all send me a hundred dollars and
> > I'll give you a random ID, but then you'd have to trust me. :-P
> 
> But there is a simple solution.  N people get together and build an
> authentication server cluster which uses a Byzantine protocol to issue
> random IDs.  This is reliable so long as fewer than 2/3s of the N nodes in
> the cluster have been compromised.  This is actually quite simple to do,
> costs very little, and is scalable.
> 
> 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.  

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"?

> > 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.

> > 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?

Sorry Jim, I've been a bit rough on you in this one.  It seems like we're both doing a good job of
frustrating each other.  Let's hope some good comes out of it.

__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Logos und Klingeltöne fürs Handy bei http://sms.yahoo.de


-------------------------------------------------------
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