Re: Re: Request for protocol extension: get_info/info messages

Hello again,

I hope everyone had a good weekend.

> Thing is "You can't trust other parties" applies to your scheme too. I
> can poison your cache by asking for a torrent, then giving you bogus info
> hash data. I can also generate thousands of garbage header sets, compute
> appropriate info hashes for these and overwhelm you with garbage
> torrents. I can even generate a header set so huge you don't have enough
> disk space for just the header set. Either you're going to run out of
> disk space, or you're going to start discarding valid torrents.

This is all solvable in the cache/peer software.
The cache can choose not to ask for info blob's until a few clients
are concurrently requesting it.
The cache has a maximum message size, it would disconnect on messages
over a certain size.
A hybrid LRU/hit-rate cache cleaning selection algorithm will keep
disk utilisation in check.

> The nice part about the incremental schemes is you don't store any data
> other than the pieces. Store the piece in a file named for the hash and
> nothing else.
> 
> Though it involves the most change to the protocol/code, designating
> pieces by their hash means the least number of attack avenues. I can't
> give you bogus hashes (no one will send anything) nor can I cause you to
> repeatedly download anything (the hash will check, no redownload).
> Anything I tell you to download *must* be valid. The worst I can do is
> waste your bandwidth equally with my own.

I think I misunderstand your proposal. Do you have a reference page?

I agree that my proposal is not the most optimal, I have taken this
path because it requires the least code changes to clients as I
expected/hoped this would have a quicker acceptance by involved
parties.

How wrong I was :-)

> > > Couldn't this feature be used to keep track of all user downloads?  I
> > > know this is already possible for ISPs with basic traffic snooping, but
> > > I think users might worry about an automatic feature that tells his ISP
> > > that he's about to download a file set.  I'd like to think that my ISP
> > > tries hard not to look too closely at my traffic.  It'd feel like a
> > > small invasion of privacy otherwise.
> >
> > It couldn't track downloads. It could alert the ISP of the use of a
> > BitTorrent client, but really I think if the ISP cared they can
> > already determine this and users should be aware that FastTrack
> > clients already lookup "cache.p2p" and emule already look up
> > "edcache.p2p".
> 
> Just because they've made a poor choice is no reason to repeat it.

heh. I can approach to this problem has been shaped by my exposure to
kazaa/emule, but I am having troubles seeing a superior alternative.

> > From: Iain Wade <[email protected]>
> > > Thing is there will be plenty who either explicitly do not wish to use
> > > it, or don't have one handy. For them it is a disadvantage.
> >
> > I think your are mis-judging the impact of a single dns lookup.
> >
> > Every time you type an address into your web-browser your machine
> > would perform at least 4 lookups.
> >
> > an "AAAA" lookup for bittorrent.com.my.search.domain.
> > an "AAAA" lookup for bittorrent.com.
> > an "A" lookup for bittorrent.com.my.search.domain.
> > an "A" lookup for bittorrent.com.
> >
> > Some client would perform more if they have a couple of search suffixes.
> >
> > In contrast, this change performs a single extra "A" record lookup at startup.
> 
> I reject your analysis here.
> 
> The bittorrent.com.my.search.domain. requests only happen if a local
> search domain has been defined (this is not a certainty). If a local
> search domain has been defined, this will likely be over ethernet or
> other bandwidth endowed connection, in which case these can be ignored.
> 
> A client will be forced to look for both AAAA, A6, and A records for your
> bogus domain before giving up; the exact same number as for a valid
> lookup. Worse, the nameserver will have to go all the way to the root
> nameservers for this query, most likely none of the records will be in a
> local cache. So, in the general case you've at least doubled the lookup
> time.

Apparently not :-)

In practice the python gethostbyname lookup doesn't do AAAA lookups by
default, at least on my redhat/fedora systems.

As for hitting root nameservers I expect this would not be an issue as
bind implements a negative lookup cache by default, so a large volume
of these lookups would be handled relatively efficiently at the ISP.

I thought about limiting the scope of that lookup to the local domain
suffix but I am not sure of how to do so in a cross platform way (and
especially not in python).

> > > And a non-MitM cache is likely to scale? Seems like they'll both run into
> > > a wall at about the same time.
> >
> > The difference is that when a MitM cache hits the wall performance
> > goes to shit for all the users passing through that system.
> 
> Oh, that issue. You're already having to MitM the tracker query so this
> is already an issue. You can go back to a combo strategy, return the
> tracker's query but add spoof records for each of the returned ones.

The goal is to not run the mitm tracker proxy .. it sucks quite honestly.

It's open to abuse because it cannot differentiate a tracker request
from any other type of http request (it's currently just not passing
non-bencoded responses back to end users, with a few update-check
exceptions for azureus).

The dns lookup negates the need for this component altogether.

> We may be decaying into client implementation concerns here.

I agree.

I still hope these patches will be included as I don't believe there
is a fundamental problem with them and they opened up other
possibilities as outlined in Olaf's original post (i.e. light weight
bittorrent url's which contain the info_hash and a few bootstrap
addresses, letting the clients download the torrent body from the peer
and start traversing that bootstrap hosts' peer list).

We've talked an awfull lot about a 5-line dns lookup patch.

> > > Good goal. Admirable position. My concern is that less scrupulous folks
> > > may choose to log, or could be forced to log via court order. I'd like it
> > > to be that keeping logs isn't useful because they cannot be made to yield
> > > any information.
> >
> > Again I disagree. ISP's are probably less likely to run tcpdump on
> > their nameservers looking to see which users are trying to resolve
> > btcache.p2p than they are to perform a court-ordered legal intercept
> > on all of a specific user's traffic.
> >
> > Trust me, we've gotten really used to handling legal intercepts since 9/11.
> 
> If there is no cache then the query will go out to the Internet
> announcing that there is a client present. If there is a cache then an
> attacker will at some point become aware of it, and be attacking it. If
> there is no cache then you're announcing your existance where before
> someone would of had a lot of work to even figure out that you existed.

if I made it configurable for the paranoid, would you be happy?

can you see any alternative way of achieving the goal: connect to the
cache of my p2p friendly ISP to accelerate my downloads?

--Iain


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/