[BitTorrent] Re: Request for protocol extension: get_info/info messages

Elliott Mitchell ehem at m5p.com
Sat Jan 15 03:00:05 EST 2005


>From: Iain Wade <iwade at optusnet.com.au>
> The problem here is that it is still susceptible to corruption. You
> can't trust the other parties in a p2p download without being able to
> verify what they've said. The info blob can be verified by comparing
> the hash of it to the info_hash on the connection. This ensures all
> clients connected with that info_hash are talking about the same
> content.
> 
> Also, this extension would be more effective in the short term before
> it's adoption is widespread because with the get_info/info extension
> only one client needs support for the feature and the client only
> needs to be available for a short time to upload the info blob, but
> with yours at least one client supporting the feature would need to be
> available at all times to support checking.

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.

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.

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


> From: Iain Wade <iwade at optusnet.com.au>
> > 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.

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

We may be decaying into client implementation concerns here.

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

> > > Got I hate this YahooGroups interface :-/
> > 
> > Join the club, though as a mailing list it does mostly work.
> 
> I'm getting significant lag here :(

This is a moderated list. Wait a while and you should get on the white
list.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \   (    |         EHeM at gremlin.m5p.com PGP 8881EF59         |    )   /
  \_  \   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/




 
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:
    BitTorrent-unsubscribe at yahoogroups.com

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





More information about the BitTorrent mailing list