From: Eugene Leitl (eugene.leitl@lrz.uni-muenchen.de)
Date: Sun Feb 27 2000 - 23:14:04 PST
I haven't had the opportunity to try Napster yet (upgrade to glibc is
way overdue). Everybody is raving about it, though, so it is probably
very good.
It seems however, that Napster suffers from a few design flaws:
centralism (there is a central database, right?); it seems to produce
cleartext traffic in certain patterns on a certain port (otherwise the
protocol wouldn't have been reverse engineered so quickly and it would
not be so easily detectable/blockable, as recently happening in
certain university networks striving to conserve bandwidth). Is this
correct?
It would have been nice to to be able to run the global title index
via a distributed database (no single point of failure, e.g. due to
unfriendly legal action), which establishes connects through
addresspace searches of nearby (in terms of number of hops and/or
bandwidth) nodes, and sending something very much resembling a SSL
connection as created by a vanilla secure browser session, both in in
regards to used protocol and traffic pattern. Scanning for/blocking
Napster traffic would so become much more difficult. An obvious
problem is how to avoid collision with vanilla https (other than
intercepting/redirecting https://aaa.bbb.ccc.ddd/napster/
traffic. Perhaps just using https on a different port would be a
smarter idea, though usage of a nonstandard port is bound to draw
closer scrutiny).
A moderate connectivity (say, ~10), with each node acting as a relay,
would allow each node to reach any other node within just a few hops
over the virtual network. Caching the index of titles stored directly
on these nodes could probably reduce the traffic quite a bit. A
top-100 list and related-list (users who downloaded this title also
downloaded the following titles, ranked by total downloads) would seem
to greatly increase program functionality.
It would seem to be necessary to limit the scope of visibility to
direct neighbours only, to prevent malicious users from obtaining
extensive lists of other Napster users' addresses. To increase
obfuscation, introducing some traffic mixing should be contemplated,
injecting pseudorandom garbage traffic between direct neighbours to
foil statistical traffic attacks.</paranoia>
The program should be capable of serving arbitrary types of digital
content.
The rationale is to sneak code into a widely used utility which would
create an infrastructure for secure anonymous peer to peer
communication, content sharing and digital payments (let's call it
CryptNet) on top of insecure, increasingly monitored/filtered public
networks.
Comments?
-- Eugene
This archive was generated by hypermail 2b29 : Sun Feb 27 2000 - 23:17:45 PST