Our nameless project.

[John Preston]

On Sat, 2014-05-31 at 19:15 +0200, davidroman96 wrote:
> On 31/05/14 17:54, grarpamp wrote:
> >> hosts that comunicate each other spoofing the
> >> source ip
> >> will recieve
> >> the file with spoofed ip
> >> in our network all the source ips are fake
> >> (spoofed ips)
> >> our project delete your real ip
> >> and put a one fake.
> > This may work in your test lan, but on the real internet, packets
> > with bogus src ip's are generally dropped at the customer interface
> > with rpf and other filters, thus breaking your app.
> >
> >> With this method the reciever don't know who want to download X
> >> file and if the NSA or FBI get the logs of the reciever they can not use
> >> it for trace the origin.
> > They will become a receiver and trace them back with netflow.
> >
> 
> We know that the sources ips generally are dropped, this is the only
> problem that we have.
> But if multiple hosts can use the same ip how the connection can be
> traced? Only the ISP have the information, the receiver don't know
> anything a part from the content of the packet.
> 

Except that packets will be dropped if they look like they're coming
from somewhere they shouldn't: https://en.wikipedia.org/wiki/BCP_38

I would, instead of taking the IP spoofing approach, I would have
designed the network with the intention of making it appear that a
message could be destined for anyone using public key encryption: if A
sends a message to B and B can't decrypt it, it wasn't intended for B,
so it gets forwarded to other nodes in the network. Traffic analysis is
defeated by layering encryption and constantly sending lots of flak:
nonsense messages. If you can maintain the throughput at each node as a
constant and make one message look different between entering and
exiting a node, I believe it would be theoretically impossible to
conduct traffic analysis.