RE: [Blocks-development] Future Direction: Hardening Blocks

[Spencer Jr., M. <sp...@ac...>]

I have a strange, incomplete idea for the future of Blocks.  I want to
explain what I have so far, and let's discuss this as a group.

If you follow this to the end (gosh you must be bored :) ) then you'll see
where I'm trying to go with this:  network abuse and spam can only be
loosely defined, so we need an adaptive, economic-like system that adjusts
the network in a reactive but automatic way to deliver the greatest benefit
to the most people at the least cost.  Yes, I know that's a tall order -- I
haven't figured out how to do it either.  But maybe as a group, we can come
up with something.

PROJECT GOAL, DEFINED

In a broad and general sense, we want lots of people to be able to use
Blocks to publish and find whatever information they want.  Our system is
unsuccessful when people can't find the files that other people publish --
when information producers and information consumers can't find each other
automatically.

We also know that several layers of protocol are required to bring producers
and consumers together...and some of that protocol is human.  We have
provided the automatic message passing foundation the network is built
on...and a file publishing, broadcasting, and downloading mechanism people
can use to associate filenames with data, and move the data around.  On top
of that is human language and file-naming-sense:  porn will be labelled
something porn-like, mp3's will say something about the song type, anime
episodes will have the series, episode number, etc.

And on top of that is a generic feeling of openness and trust between users:
we can be reasonably certain that people aren't going to share bogus data or
run bogus clients.

Those last two human layers are our major weakness:  they aren't being
managed and quantified automatically.  So all of this stuff I'm going to
propose, and all I have proposed in the past, amounts to a way of taking
those things that humans naturally assume will be true and checking them
with the software.

That is...from a security standpoint, humans are stupid.  They will believe
what they see, because it's easier to believe what you see than to check the
facts first.  So we should build a framework that checks facts
automatically.

MANY THREAT MODELS

It's not completely black and white, whether something is abusive or isn't
abusive.  Flooding is abusive.  Sharing popular files isn't.  Spam is kinda
abusive.  Deliberately mislabeling files is abusive.  Labeling a file
vaguely, out of ignorance or forgetfulness, is slightly abusive.

In theory...if you had a human acting as a Blocks client, physically
inspecting each and every packet that went through his node, some abusive
traffic would get through.  Floods and obvious abuses would be stopped...but
subtle attacks could still continue:  vaguely named files, truncated
files...files that nobody cares about...people trying to download every copy
of their favorite mp3 all at once.

ABUSE DEFINED AS ECONOMICS

Why does email spam suck?  So little resource usage on the attacker's end,
so much resource usage on the victim's end.

Or to say it with economics:  To the attacker, resource cost is low and
utility is high...to the victim, resource cost is high and utility is very
low.  Resource cost in this case is bandwidth:  I can spam easily from a
28.8 modem and a few open relays.  I don't have to spend much money or time
or bandwidth.  For you...your computer might take a while to display the
email, or the email might load up some graphics or popups or something...so
that's a lot more resource usage than you really wanted to spend on spam.
Utility is high for the attacker, because they get a lot of 'good' out of
the spam:  lots of eyeballs see their ad, and maybe one in a million people
buy the product, because they're stupid newbies and don't realize that
supporting spam is bad.  Utility is low for you, because you don't really
care about making money fast right now.

Television ads:  for the 'attacker', resource cost is very high, and utility
is high...and for you, resource cost is low (you're watching TV anyway,
after all) and utility is...well...about medium.

BLOCKS AND ECONOMICS

How about some Blocks-related examples?

Well, Blocks is pretty much anonymous...so from a client standpoint, you
have no idea what their resource cost or utility is like.

Very popular movie files:  resource cost is very high here, because lots of
people are trading very large files...but utility is also very high.  If you
were to talk to everyone you're connected to, they'd probably all agree that
"It sure is straining the network to send all these files, but it sure is
worth it -- I've been meaning to go see that movie..."

Packet flooding:  resource cost is high, and utility is pretty much
nonexistant.

Content flooding:  resource cost is about medium, I guess...maybe high if
the content is pretending to be popular files, and is getting downloaded a
lot...and utility is pretty much nonexistant.

Obscure or unpopular content:  resource cost is low, because the content
isn't being requested that much...but utilty is also low, since the content
really isn't helping that many people.

AUTOMATIC ECONOMICS

Obviously, if a person could physically inspect their Blocks traffic, and
could talk to everyone they're connected to, it would be easy to optimize
the network.  All you have to do is look at the packets and
connections...keep things that are 'worth their bandwidth' and drop things
that aren't.

It sure would be cool if Blocks could do that automatically:  somehow decide
how much 'worth' each packet has, and decide whether things are over the
'worth' threshhold or not.

...and after that, I draw a blank.  I can barely even imagine where to
begin.

Maybe some systems could manage this by giving each node a certain number of
points...some kind of scarce economic resource, beans or dollars or
something...which is gained by being a successful information producer and
lost by being an information consumer.  This hurts leeches and helps
central-hub nodes.  But I can't imagine how to implement that without a
central authority...and I'm not even sure if that would be a good idea
anyway.  It's just a vague thought anyway.

The resource we're controlling is bandwidth (or packet traffic in
general)...and because of the anonymous and distributed nature of Blocks,
the only bandwidth we can measure and control with any certainty is our own.
Utility also has to be managed...and perhaps that can be measured by the
web-of-trust:  popular files that people like will have positive
utility...unknown, never-before-seen files have neutral utility...and files
that people routinely mark as spam and avoid downloading have negative
utility.

So if you can correlate resource cost with utility on your node alone, you
can kinda optimize your node so it'll benefit the most people for the least
bandwidth.  Maybe a very popular central-hub node is very sensitive to
resource cost...so if you connect there and send traffic, you'd better be
serving up some top-flight popular files or you'll get disconnected.  A leaf
node could connect to someone and start leeching...but they might find their
bandwidth squeezed down to a couple k/sec once the target node figures out
that the leaf node is a leech.

And you are always in control of your own bandwidth (random-UDP-packet
flooding to the contrary) -- if you ask someone to lower the traffic rate on
their connection to you, and they don't do it...just drop the connection.


OK, maybe this'll get some gears turning for you network experts.  My
experience ends with the encryption and web-of-trust stuff...so I hope this
gives you all some good ideas and starts some interesting discussion.  :)

--Michael Spencer
bl...@ms...

-----Original Message-----
From: lu...@et... [mailto:lu...@et...]
Sent: Monday, August 14, 2000 12:29 PM
To: Erik Moeller; blo...@li...
Subject: Re: [Blocks-development] Future Direction For Blocks


* Erik Moeller wrote:
> Before we go to ratings and authentication, we should clear the 
> scalability issue and possible routing/resuming problems.

Hurm.  Given the mess that Gnutella has become, I think it's very important
that we make sure that the blocks network is impervious (or at least
tolerant of) to:

- False announcements, advertising and other Bad data
- Flooding and other DOS attacks
- Bogus/incomplete data

It doesn't matter how spiffy the technology is, if it can be abused, it will
be.  *sigh*

-Luke

_______________________________________________
Blocks-development mailing list
Blo...@li...
http://lists.sourceforge.net/mailman/listinfo/blocks-development