Two different problems here
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..
- Real 100% secured and anonymous access
- Fight intercepting equipment
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,
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
. 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 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.
- binary part hash (MD5) of the packet
- nickname of the publisher/URL of the key server
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
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
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.
- 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.
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.
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
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
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.
- DDOS (distributed denial of service) attack
- Attack against security holes in specific application/OS
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
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
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.