Rodi Introduction
If tracker fails there is no way to move torrent file to another tracker and inform all seeds/clients that tracker is moved. New torrent file should be created and data distribution process should be started from the very beginning. If after restart client finds that tracker is down there is no way to continue download Nodes send "what i have" messages which consumes some upstream and part of downstream of the destination peer. There is no reason to send anything to the peer without direct request from the peer and even in this case request can be ignored to save the upstream. In the typical application downstream of the client is significantly wider than upstream, like 4:1 or even more. The case is especially noticeable for ADSL lines which serve about 100 millions subscribers (number is valid for the end of 2003, source http://www.lightreading.com/). I can make case that modern networks are reliable and require only minimal set of flow control and retransmission features above the data link (UDP). There is no reason to send data over TCP if client is not going to use flow control of TCP. In the simplest scenario the host can use best effort scheme when sending packets to the client with no timeout for acknowledge. If client fails to receive a packet new request can be issued at any time, assuming that packet can be found on the host. Client can optionally specify in it's request to the host optimal burst size (window size), packet size, inter burst and inter packet delay. In the best scenario client will not issue any requests to the host beside initial request. Because UDP connection is stateless no time will be spent for establishing peer to peer connection. Security is a huge problem for the existing bittorrent network. In most cases bit torrent tracker accept any client, in some cases client should go through registration procedure running by regular WEB server before the client gains access to the tracker. Part of the registration procedure is saving client IP address which is assumed to be unique. Many question immediately arise. Not clear how the system can work if client is protected by PROXY and real IP address is invisible for any 3rd party. What happens with dynamic IP addresses. How tracker can assure that current request is arrived from the client registered on the server and not from one with the same (faked?) IP address. How host can make sure that request arrived from the authorized client ? How client can make sure that the host storing the data is authorized. Security Upstream. One possible solution that secured registration procedure includes sending to the client via protected channel 2 keys - client ID and tracker ID. Besides two keys supplied by the server, there is a nickname chosen by client. When client initiate transaction it receives from the tracker session ID - this is a third key used by the client for the client - host communication. Every request from the client to the tracker contains client nickname and protected by MD5 for the whole data including the client ID, but client ID itself is not sent to the line. Similarly every request from the client to the host is protected by MD5 for the whole data including tracker ID and session ID, but tracker ID is not sent to the line. I assume here that all hosts already received from the server tracker ID and can calculate and check MD5 of the incoming packet. Correct tracker ID means that the client belongs to the network. Combination of correct client ID and client name means that the client specified correct user name and have initial access to the tracker. Here how different packets look like for client to tracker and client to host communication
Security Downstream .Similar to the client tracker signs every packet with MD5 calculated for the whole data including tracker ID and session ID, but send the packet which contains only session ID and payload. Upon receiving the packet client is expected to recover the initial packet using stored tracker ID, calculate MD5 sum and compare with received summa.When communicating with host client expects that all packets arriving from the host are signed with MD5. Host calculate MD5 using stored tracker ID and session ID, but sends only payload and MD5 summa. Here how different packets look like for tracker to client and host to client communication
Data encryption and how to fight P-Cube, Allot Communication, Expand Networks, Lancope Inc., Ellacoya Networks, Packeteer and similar solutions. One of the possible scenarios that the payload can be encrypted by the host before sending to the line with some private key generated by the tracker. Client receives public key generated by the tracker as part of initial handshake. In the different approach the whole data packet can be encrypted in the data exchange between host and client and between client and tracker. Let's talk more about this. There are three separate problems the system can try to answer.
Can be argued also that when ISP sells contract including 24/7 unlimited access at specified bandwidth customer expectations are that network performance is application independent, otherwise ISP should issue clear statement as part of the contract that, for example, P2P or proprietary VoIP application has low priority and services provided by ISP's mail server has higher priority. Let's say that IP address and port number can not be recovered by intercepting system, for example, all nodes are behind PROXY servers supporting packet encryption in both directions. This approach bring additional costs related to the maintenance of PROXY servers. P2P protocol can be defined in a way that helps ISP to recognize replicas and cache the data locally. For example, GetData request is a unique URL string and GetData response is a binary packet. Such ISP friendly approach could decrease network loading significantly. There is a copyright issue arise, because cache is effectively part (or even full) of probably copyright material and ISP cache participates in illegal sharing of copyright material. The issue is far from clear, because ISP does not make any usage of the information in cache besides facilitating the data transfer, these are the hosts who store and publish the material (see http://www.joltid.com/ and http://zdnet.com.com/2100-1104_2-1027508.html for more on caching). Typical internet browser stores information in the temporary files cache and it is not considered infringing on copyright laws. Data protection is one most trickiest. Network consists of trusted and untrusted nodes. Let's say that tracker is a trusted party by both host and the client entity. Let's say that all nodes protected by PROXY and real IP addresses can not be recovered from the packet. We need some procedure of exchanging the keys between host and client. Host encrypts the data and publish the key and data title on the tracker. As part of the publishing procedure host specify what clients have an access to the data and encryption key. Host can generate separate keys for every trusted client using client's nickname. This way the data can not be accessed without one of the limited number of keys. When host sends data to the trusted client it uses the correspondent key to encrypt the data, client must use provided by the host key and only this key to access the data. To avoid on the fly encryption host can use single public key for encryption. This way host can cache already encrypted data for future use. Pay attention that thanks to MD5 signature tracker and host are sure that client is authorized to access the data. Client upon receive of the data use the personal and unique key to open the packet and check MD5. Let's say that tracker is not trusted node. The only solution I see at this moment is using separate media (like e-mail) for key exchange or some trusted server belong to 3rd party. Anonymity. Two different problems here
Bouncer does not provide 100% anonymity, because the adversary still can attack the system using statistical analysis of response time, intercepting ALL incoming and outgoing requests from specific node, etc. Still the concept looks good enough for many applications. Rodi uses UDP packets for both data and control messages (like search). It can be argued that source IP of any packet can be faked and log of the traffic can not be regarded as a proof that specific host sent the packet. Let's say that adversary sends a data request to specific IP address and receives reply - packet containing some other IP source and the data. Publisher of the data can argue that the data request was handled by some other node. In the real network we can bounce data requests but data transfers can still be P2P. Important! We use conectionless protocol like IP. In case of IP it's enough to specify correct destination IP for data delivery. All retransmission requests are routed through the network. Rodi provides limited routing capabilities. Optionally publisher can specify to use it's randomly generated ID (see MUTE filesharing network for details) instead of IP address. Client looking for the data receive publisher ID and not publisher IP address. Every client stores a routing table to support anonymous operations and allocate part of the upstream. The rule here if you don't route you don't get routing services from the neighbors also called Autonomous Reputation Scheme or autonomous tit-for-tat mechanism. Node can stamp the outgoing packets with arbitrary source IP (usually it's not possible if you behind DSL/cable modems, NAT). Rodi can ignore source IP of the packet and fetch the contact information from the payload. Another approach to the problem of anonymous internet access is WiFi. ISP can sell service not on monthly subscription base but pay-per-day/pay-per-hour. For example, imagine ISP providing services in the appartment building or in train. Customer simply buys a card with a key/coupon and pay in cash (coupon can be printed on the train ticket). The ISP does not have to keep billing information. MAC address and DHCP server log is the only way to find out what desktop was using any specific IP. Even if ISP keeps DHCP logs client can always alrgue that anybody could fake the MAC because MAC address is configurable on most Ethernet cards. Bouncers. Let's call publisher server P, downloader D and some other peer B (bouncer). Let's assume also that the protocol is IP based. P never accepts data/look requests directly from D. D sends packet to B with it's (D) source IP in the IP header and in the "get data" request. B forwards the packet to P with new (B) IP address in the IP header. P receives the packet and checks that IP source in the header is (not) the same as in the request and/or that source IP (IP of B) belongs to friendly host (group security server, for example). P sends data directly to D. Essentially the idea here is to bounce control messages but send directly the data itself. Because the protocol is UDP based it can not be reliably proved that P published the data, because P can always argue that the IP address was spoofed by B. B has no idea about actual data transfer because it sees only the "get data" request and not the data itself. D can argue that it sent request to one peer but received (or did not receive) data from the other and the data was not what it (D) was looking for. While adversary can easily find all participants - P, D and B, it is much harder to prove that the data transfer ideed took place. Let's say that B is adversary - it sees only data reqest. Let's say that adversary is D - there is no prove that incoming packets with P IP address are indeed generated by P. Let's say that adversary is P. D can argue that it did not receive a single packet and even more, that D never asked for the data in first place and it is B which did the work. Let's say that adversary runs both B and D. P can choose bouncer(s) randomly among existing peers or from list of well known IP addresses. This way adversary can never run B. The only way adversary can attack the network is to log traffic from all three participants - P, D and B. One solution mighty adversary can use is to sign agreement with all service providers (ISPs) where ISPs are oblidged to log the traffic from any peer upon request and request can come in real-time. let's say that all ISPs open access to their routers for the adversary. While it's possible it is not easy for large scale network. Another aplication for bouncres is centralized security server holding encryption keys for control part of the protocol. Distinct pairs of keys can be generated for all participants and security server is the only place where all keys (public and/or private) are kept. IP network topology awareness, internal rounting protocol, looking for shortest pathTBD Firewalls. Using any and only one IP port (for example, HTTP - 80) for the communication can help to fight some of the firewall configurations. Still in some cases stronger scheme should be implemented. The system can fake look&feel of real RTP or NFS packet - IP port number, Protocol type, etc. and destination node can still process the packet as regular. The system does not make use of TCP flow control features and essentially implement it's own packet delivery protocol (it can be, for example, flavor of Frame Relay protocol). In the first phase i am going to fake RTP packets. It makes sense, because
IP Multicast. Next step from UDP seems obvious - using multicast for serving multiple clients. TBD I will appreciate any comments of the project, especially from IT professionals, WEB managers, ISPs. See also: BitTorrent Specification Filesharing applications http://dmoz.org/Computers/Software/Internet/Clients/File_Sharing/ MUTE http://mute-net.sourceforge.net/ GNUnet http://www.gnu.org/software/gnunet/ RTP header http://www.networksorcery.com/enp/protocol/rtp.htm UDP data transfer http://dsd.lbl.gov/DIDC/PFLDnet2004/talks/Grossman-slides.pdf Multicast http://www.nwfusion.com/details/502.html Multicast security http://www.live.com/mcastfw.html HP tech report "Peer-to-Peer Computing Dejan S. Milojicic, Vana Kalogeraki, Rajan Lukose, ..." http://www.hpl.hp.com/techreports/2002/HPL-2002-57.pdf P2P and related SW http://www.slyck.com/programs.php Another P2P news web site http://p2pnet.net/ P2P statistics (Sep, 2004) http://www.itic.ca/DIC/News/2004/09/02/P2P_Statistics_August_2004.en.html P2P and SIP http://www.techweb.com/wire/networking/47900119 Report on worldwide digital piracy http://www.itic.ca/DIC/News/index.html P2P Gets Serious http://www.lightreading.com/document.asp?doc_id=56091 Why DRM is bad http://www.craphound.com/msftdrm.txt Publications on Coral project web site http://www.scs.cs.nyu.edu/coral/overview/ More on IRIS here http://www.newscientist.com/news/news.jsp?id=ns99992861 (sponsored by National Science Foundation) More research publications from Chord http://pdos.lcs.mit.edu/chord/ Self-certifying File System (SFS) http://www.fs.net/sfswww/ Berkeley DB http://www.sleepycat.com/ Wavelet Transform Tutorial http://users.rowan.edu/~polikar/WAVELETS/WTtutorial.html High resolution wallpapers from Dali, Picasso http://www.rasiel.com/ Version Control System Comparison http://better-scm.berlios.de/comparison/comparison.html Keyword Matching http://www.limewire.org/techdocs/KeywordMatching.htm Java code examples http://www.limewire.org/techdocs.shtml Open Source JVM http://sablevm.org/docs.html Java to ELF compiler http://jcvm.sourceforge.net/ Another Java compiler http://gcc.gnu.org/java/ Subversion Version Control http://svnbook.red-bean.com/ Performance Comparison of Java/.NET Runtimes http://www.shudo.net/jit/perf/index.html Project WASTE documentation http://waste.sourceforge.net/docs/docs.html Project MNET documentation http://mnetproject.org/repos/mnet/doc/ More details on traffic shapers http://www.broadband-pbimedia.com/ct/archives/0703/0703_pondering.html and more comments from lightreading http://www.lightreading.com/boards/message.asp?msg_id=93718 Another way to secure access to the server "Port Knocking" http://www.portknocking.org/ "The longest and most comprehensive measurement study" of Bittorrent http://pds.twi.tudelft.nl/~pawel/pub/bittorrent.pdf Streaming P2P and Bittorrent http://www.ifi.uio.no/dmms/papers/129.pdf Rodi GUI Spec
Let's keep it as simple as possible. Rodi core provides access to the internal data bases and management functions. Core opens management socket
and waits for requests from the management. Management can be just a simple CLI or graphic and color rich GUI application and can be
written using any language and can run on any system. This project develops two interfaces - CLI and light GUI.
CLI provides menus to print current statistics, configure system parameters, start/stop upload/download, publish data, etc.
This is another logo for the project you can vote for the best logo using email
larytet@yahoo.com
Home |