Rodi (P2P)
Functional requirements
Use cases
Help the project
Try Rodi (beta)
User Manual
Post IP range
How to...
Message board

SourceForge.net Logo
Get Firefox

Valid HTML 4.0! Valid CSS!


Two different problems here

  • Real 100% secured and anonymous access
  • Fight intercepting equipment
Let's say that a powerful 3rd party - let's call them the adversary, installs a client and start to log IP addresses belonging to the network. The adversary assumes that there are no bouncers, a program that runs on a server in the internet and functions as a proxy between a client and one or many servers, used by the network otherwise the data collected this way is not reliable. In other words, if the adversary intercepts a packet containing information it is looking for it does not necessary mean that source IP of the packet belongs to the node hosting the data. While the burden of proof is put on the adversary it is more important to note that the adversary must obtain realiable data and that is not easy in a multi-proxy server environment such as has been proposed in the Rodi project..

Bouncers do not provide 100% anonymity, because the adversary can still attack the system using statistical analysis of response time, intercepting ALL incoming and outgoing requests from a specific node, etc. Still the concept looks good enough for many applications. Rodi uses UDP packets for both data and control messages; such as search. It can be argued that the source IP of any packet can be faked and the traffic log can not be regarded as proof that a specific host sent the packet. Let's say that adversary sends a data request to specific IP address and receives a reply - a packet containing some other IP source and the data. The 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. This is very 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.

Let's call the 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 the packet to B with it's (D's) source IP in the IP header and in the "get data" request. B forwards the packet to P with B's IP address in the IP header. P receives the packet and conditionally checks that the IP source in the header is (or is not) the same as in the request and then may check that the 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 directly send the data by 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.

No one of the participants has to set IP source correctly in the IP header of the IP packet. The only requirements that downloader sends it's correct IP address in the UDP packet payload. Optionally payload can be signed and encrypted providing additonal layer of protection.

Bouncer and Publisher can agree upon using this or that IP address space in order to recognize each other. Together with MD5 signature and encryption this scheme helps the publisher to work in stealth mode. Publisher simply ignores any packets arriving from unknown IP addresses. Bouncer never see a single packet from the publisher. And downloader never see any packet from the bouncer. While adversary can easily find all participants - P, D and B, it is much harder to prove that the data transfer indeed took place.
Let's say that B is adversary - it sees only data reqest.

Let's say that adversary is D - there is no proof that incoming packets with P's 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 preventing or making it unlikely for the adversary to run bouncer. P can also argue that there are more than one bouncer participate in the data transfer and that P is only one of them.

Data transfer between downloaders and publishers can be encrypted by weak or strong enctyption making it impossible or very hard for the analysing equipment in the middle to discover the content of the packets.
In normal scenario bouncer can only examine control packets, not the data itself and control packets can be encrypted as well. If required by the adversary to filter the packets containing specific information bouncer can argue that the scheme is not reliable and is not going to work, because deep inspection of the encrypted packets even if encryption is weak can not be done in realtime.

The only way adversary can attack the network is to log traffic from all three participants - P, D and B. One solution 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 to 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.

Authorization and friendly peers.
Rodi network provides key servers, where content publisher can post Nickname and RSA public key as part of the process of advertising of IP range (see example of simple identification server here) . When sending data packets publisher signs the packets with the private key. Downloaders or subscribers are expected with time to learn the nickname of the publisher. This way publisher and subscribers can create network of trust. Key servers belong to trusted 3rd party.

Key server assures uniqueness of the nicknames in the Rodi network. Both - name of the Rodi House and name of the peer, are unique. Rodi House can post it's public key and all members of the House can use the same public key when releasing content.
If key server is compromised it means that posted pairs nickname/public key are not reliable. Downloaders who already learned and stored copy of the pair will continue to work without disruptions. Key server does not keep any personal information, but only range of IP addresses, nicknames and generated by the peers public keys. Optionally publisher can receive from the key server signature encrypted with private key of the key server. Key server signature contains nickname of the publisher, public key of the publisher and credentials of the server, for example URL. Publisher then can attach signature information element to every sent packet. Signature information element contains following parts

  • binary part hash (MD5) of the packet
  • nickname of the publisher/URL of the key server
Binary payload is encrypted using private key of the publisher. Downloader is expected to decrypt the binary payload using public key found on the trusted key server. Downloader makes sure that that the binary payload is indeed encrypted with publisher's private key and MD5 of the packet is correct.
Key server provides XML based interface to the database containing nicknames and public keys of the publishers. Rodi client can load the database and periodically check for updates.
Rodi House can run own key server(s) and provide to the publishers belonging to the house House Signature.

MD5 software speeds are adequate for most of the deployed 'last mile' connections, but can be found to be slow for next generation of high speed connections. Publishers behind fast connections can prepare signed packets and store most frequently asked data blocks in cache to improve performance. Publishers can use separate cache servers to store prepared data blocks.

Signature information element is optional if the whole payload of the UDP packet is encrypted. If signature does not contain nickname or the whole payload is encrypted downloader is expected to find corresponding public key using destination IP address and IP port to which the original request is issued.

Hash of the packet is calculated for the whole packet including signature information element where the binary part is zeroed. Publisher encrypts the resulting hash with private key, copies the encrypted hash into the signature information element and sends the packet. Publisher can attach multiple signature information elements to the packet, for example, personal signature and signature of the key server.

Publisher is free to use different private keys for different destinations. At this point it is not permitted to use different keys with the same destination node.

Rodi publisher maintains data base of private keys. Rodi client application never stores private key and requires to add private keys after every power up. Private keys can be stored in separate encrypted files. Rodi supports loading of encrypted key files using master key. User will enter master key to load private key. Important ! Rodi client application keeps the private keys in the RAM unencrypted.

Rodi downloader maintains data base of public keys. Entry of the data base contains following fields

  • Publisher ID, like nick name or IP address.
  • Type of the key
  • Publisher public key
  • Flags, for example trusted or not trusted to download data from, to upload data to, to manage the application, etc.
There are multiple ways to find out what public key of the publisher is. Downloader can access key server manually or automatically and load table of the public keys.

If Rodi client application receives signed packet and can not recognize Publisher ID and find public key the correspondent entry will be added to the log and the packet will be treated as regular unsigned packet.

Normally downloader starts to upload data to other peers immediately after the first block is downloaded and hash of the block is checked. There are two ways to ensure integrity of the data coming from untrusted source - downloaders.
In one scheme downloader receives table of hashes from the trusted publisher. The packet containing block(s) hash is signed by the publisher and assumed to be authentic. Downloader compares every downloaded block with the relevant hash from the table.
In the second scheme downloader can store (cache) received from the publisher signed blocks and upload them as required. The second scheme is probably usefull when publisher creates dedicated network of servers to upload sensitive content. Normally MD5 is calculated for the whole packet inlcuding system related information elements like session ID. If cache servers are used publisher will calculate MD5 only for the data payload (does it create a loophole in the logic ? session ID is 64 bits randomly generated key and data payload contains block offset, but not the file hash. in different scheme publisher can zero variant fields of the packet before calculating MD5 and it is possible to define order of the information elements for MD5 calculation. More design here )

The first priority is to protect publisher. Two types attack are most often

  • DDOS (distributed denial of service) attack
  • Attack against security holes in specific application/OS
In case of DDOS the only solution right now is to use a network of friendly bouncers behind different ISPs using different types of equipment and spoof source IP address. This way DDOS will require more resources from the adversary than when attacking a single host and the adversary can not attack the publisher directly because the source IP of the arriving packets can not be relied upon. Also a Publisher can ask it's ISP to filter incoming packets before sending them to last mile connection (cable/DSL). Unfortunately none of these approaches is possible in many cases. IP address spoofing is not possible on some Windows systems and sometimes ISPs have their routers set to use source IP filtering. Rodi can be used to bounce a data stream but if you think you need it MUTE project is a way to go.
The Rodi peer generates a unique 32 bit session ID for every established connection. Also there is support for MD5 signature and different types of encryption. So it looks very unlikely that faked blocks will be sent by adversary because every block can be checked against MD5 table received directly from the publisher.
How does a downloader knows that the downloaded data came from the publisher and not from the adversary? This is where friendly bouncers come into play. When publisher advertises (for example, on a website) a new document, she specifies one or more IP addresses she (publisher) will accept as a bouncers. It would be relatively simple to support a closed community protected by strong encryption and hierarchical passwords. Such a community will typically install a security server to provide all registration/key exchange.

Loosely related notes
Rodi can provide limited routing capabilities. Optionally publisher can specify to use a randomly generated ID (see MUTE filesharing network for details) instead of an IP address. Client's looking for the data receive the publisher's 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 is: if you don't route you don't get routing services from the neighbors. This is also called Autonomous Reputation Scheme (ARS) or autonomous tit-for-tat mechanism.
Also nodes 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 argue that anybody could fake the MAC because MAC address is configurable on most Ethernet cards.

Message board