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.
