This post is long reading. I could not make it shorter because ... well, networks and networking is not simple.
as i can see in ethereal i know the source of incoming udp packages.
and i know this is the real ip of this one. i start a look, i find a
file, then i look into peer-list and there is the ip of this one.
and then i could try an ip-scan with a tool. next i could see, if
activated, the snmp-infos of this ip. if there is a name, then i know
the ip, the published files and the name of this on. how does it be
secure?
or do i misunderstand there something?
Default mode - IP address is visibleDifferent from I2P, Mute, Ants and other anonymous networks Rodi does not provide immediate IP masking. By default Rodi does not route packets. Rodi works exactly as any other P2P network like Bittorrent. Peer A sends request to peer B. Peer B sends response to peer A.
In this mode assuming normal conditions of the network performance is expected to be comparable to the performance of the Bittorrent network. Because Rodi is UDP based multicast can be supported in some networks (LAN) improving performance dramatically. For example, multicast in LAN can be used to stream HDTV to 100s or even 1000s IP nodes from only one regular PC.
Another point is that data transfer protocols using UDP can be extremely aggressive in utilization of available bandwidth. Over "fat" connection with signifcant delay and jitter and high packet loss ratio UDP based protocols will tend to scale better than TCP.
BouncersThere are two ways to hide IP address in the Rodi network. Both methods can be used together and separately.
- running bouncer as an intermediate node between seed and leacher
- spoofing IP source address
- network of trust (l33t hubs)
on the following diagram
http://larytet.sourceforge.net/images/DiagramBouncingModeB.gif you see simplest way of using of Rodi bouncer. In this case Rodi bouncer behaves exactly as, for example, regular HTTP Proxy. Seed (or publisher) is completely hidden behind Rodi bouncer (or ring of Rodi bouncers).
Publisher asks Bouncer(s) to help to distribute some content. Bouncer agrees. Publisher advertises the content and IP address and IP port of the bouncer. Publisher can post hash of the file, file name, Rodi Hash file in any combination. Downloader sends packets to the Bouncer. Bouncer forwards all packets to the Publisher. Publisher sends all packets to the Bouncer. Bouncer knows to route the packets correctly if there is more than one Downloader.
Bandwidth available for the publisher is limited by the upstream of the bouncer. If bouncer is 56K dialup publisher's upstream is limited by 56KBit/s upstream. Downstream of the dialup modem is not going to be relevant in most cases because Rodi control packets are small and control packets are rare.
Publisher can also use more than one Bouncer in parallel. Publisher advertise IP address and IP port of all bouncers. Available to the publisher upstream is a summ of upstreams of all bouncers.
To improve security Publisher can create a ring of bouncers - connect bouncers one after another. This way log on the ISP where first bouncer is connected will deliver IP address of the second bouncer and so on.
Rodi Bouncer provides relatively good protecttion for the publisher assuming that publisher chooses Bouncers among trusted parties or choose random Bouncers from large pool of Bouncers. The setup can be attacked by mighty adversary using exactly the same mehtods as in Tor or FreeNet networks. For example, adversary can compromise all or majority of the bouncers in the network. Adversary can also log all traffic from all nodes in the network. Currently Rodi does not encrypt payload. Adversary can also consider the network as a block box and hold liable every node sending sensitive data, both Bouncer and Publisher.
Bouncers are willing to provide bouncing services because their score on the seed'c client is growing (implemented partially). Seed will tend to serve bauncers first, because bouncers have better score. Database of peers is system level, like in eMule.
IP spoofingLet's say that Publisher can spoof IP address. Publisher is able to send packets with arbitrary IP address or with IP address which is different from one Publisher gets from the ISP
Now Publisher has more choises. In one of the possible setups Publish advertises real IP address and IP port. Downloader sends packets to the Publisher. Publisher sends response to the Downloader but places different IP in the IP packet.
Performance of the network is the same as in regular not protected P2P network.
Let's say that adversary compromised Downloader. Adversary sends a packet to the Publisher (destination IP). Adversary sees response arriving from different IP address. Adversary should suspect that destination IP address belongs to the bouncer and that real IP address is the one where packets arriving from. Adversary has no meanings to prove that destination IP is a real IP address of the Publisher. Adversary has to log all the traffic on the Publisher node to find out that Publisher spoofs IP. This requires long investigation and can not be done in the real-time. Adversary snifing packets on the edge of the network can not find out in reliable way IP address of the Publisher.
Bouncers and IP spoofingIn another scenario Publisher uses Bouncer, but only for downstream direction. Publisher advertises IP address and IP port of the Bouncer. Downloader sends packets to the Bouncer. Bouncer forwards packets to the Publisher. Publisher sends response to the Downloader with different IP address in the IP packet header. see
http://larytet.sourceforge.net/images/DiagramBouncingModeA.gifTo improve security even more Publisher can ask Bouncer to forward packets to more than one IP address
http://larytet.sourceforge.net/images/DiagramBouncing.gifPerformance of the network is only slightly lower than in regular not protected P2P network, because of higher packet loss over longer path. Most of the data - actual upload, is still direct transaction from the Publisher to the Downloader.
Adversary is in about the same situation as before. Log of the traffic on the node where Bouncer is connected will not deliver reliable result, because there is possibility that Publisher uses more than one Bouncer. Adversary can also discover that Bouncer forwards packets not to one but to many IP addresses. Log collected by the compromised Downloader shows only IP address of the Bouncer and IP address Publisher decided to use for the responses.
Publisher can spoof IP address and use bidirectional Bouncer - both upstream and downstream. This way even compromised Bouncer can not be sure that IP address(es) it sends packets to belong to the Publisher.
Ability to spoofI've met estimation that about 15% of existing connections can spoof IP address. In some cases node can not use arbitrary IP address, but address from some subnet. If node is behind NAT IP spoofing is NOT possible. IP address of the packets will be set by NAT. For example, if node's IP address 192.168.x.x this node is NATed - this node is behind NAT. Inside of the LAN node usually can spoof IP address. It can be the case in corporate networks, campuses, WiFi networks, etc.
Why Rodi ?Rodi does not provide strong protection for the particpating peers. The same attacks which are possible in other networks are possible in the Rodi network too. Current code of the Rodi client does not provide encryption of the payload. If adversary can collect ALL outgoing and incoming from the publisher packets adversary will prove that publisher participates in the distribution.
Rodi promises high performance and efficient bandwidth utilisation when compare with existing anonymous P2P networks. In the Rodi network Publisher chooses (and probably runs) bouncer. Publisher can choose good bouncer or bad bouncer or Publisher can decide to work without bouncer at all. In all cases adversary will find that it is hard to prove that some specific IP address belongs to the Publisher.
Let's say that adversary sends packet to some IP address and gets response from the same IP address. Naturally adversary assumes that Publisher can not spoof and that Publisher does not use Bouncer. Adversary goes ahead and checks the PC. Adversary can find out that in reality PC is just a bouncer and apparently Publisher spoofed IP address - set IP address of the Bouncer in the response.
Smart Publisher can prepare a perfect legal trap for the adversary which jumps to conclusion too fast. Simple sniffing of the packets on the edge of the network is not going to be enough anymore. Adversary will need access to the logs of multiple ISPs. Log collected by ISP should be rather large - it should contain IP header of the packet, exact timestamp and part of the payload.
Let's say that large ISP has 100K subscribers with 1MBit/s upstream connection every one. Assuming packet size 1400 bytes and 70% loading of the network we get 5M packets/s. Log keeps IP header (8 bytes), timestamp (8 bytes), part of the payload (8 bytes) or 24 bytes for every packet. Total amount of data is 120Mbytes/s or 10T/day.
If we assume 2K subscribers behind every gateway (DSLAM/CMTS) we will get ~200G/day of logs. while it's possible technically i am not aware of any existing system which is able to do this for all existing connections simultaneously.
