[p2p-hackers] Spoofing source address to tunnel through address-restricted/symmetric NAT

[David Barrett]

Ah, thanks Matthew for the detail.

So, it sounds like this wouldn't be practical for true P2P as raw socket 
support would prohibitively restrict deployment, and most consumer ISPs 
would block outbound spoofed UDP packets anyway.

However, that still leaves the serverside.  Assuming you were able to 
find a colo that'd let you dump spoofed UDP onto the backbone, would 
consumer ISPs block *inbound* spoofed UDP packets?  How would they even 
know?

The theoretical advantage of this would be for rendezvous and relay 
services, where servers need to occassionally contact clients.  In the 
case of a geographically-distributed server farm, a client needs to 
separately hole-punch to each server, which is a pain.  Using serverside 
spoofed UDP, you might get around this.

And as for the legal/ethical issues of using spoofed UDP, if I'm 
spoofing traffic from one of my own servers (ie, server B is spoofing 
packets from server A, but both are owned by me) then I see no cause for 
complaint.

-david

Matthew Kaufman wrote:
> In the general case this won't work, because odds are (extremely) high that
> the ISP the "other clients" are attached to is doing filtering that won't
> allow their spoofed-source UDP packets to reach the destination.
> 
> This has been a "best practice" for ISPs for years now (see the NANOG
> archives to find out just how many years), so is nearly universally
> deployed, especially on consumer broadband networks (and university
> networks) where the potential for abuse is highest.
> 
> Actually trying this is easy if you can generate raw IP datagrams (requires
> root on a Unix machine (including MacOS X), can't be done without driver
> work on older Windows, is easy on XP, is limited in what you can generate on
> XP SP2)... After all, the IP and UDP header just isn't that complicated to
> synthesize.
> 
> You would, of course, also need a UDP-based transport protocol that you
> could modify to work this way and which wasn't dependent on the source
> address for demultiplexing who it was talking to... after all, everyone who
> makes it through their ISP's filters will have the same source address, and
> that's typically how you figure out "who this packet came from". The amicima
> MFP protocol (which we hope to release in just a few more weeks in
> open-source form) would work, since it doesn't rely on the source address to
> demultiplex incoming datagrams to the associated sessions as a side effect
> of its IP address mobility capability.
> 
> 
> Matthew Kaufman
> matthew at matthew.at
> www.amicima.com
> 
> _______________________________________________
> p2p-hackers mailing list
> p2p-hackers at zgp.org
> http://zgp.org/mailman/listinfo/p2p-hackers
> _______________________________________________
> Here is a web page listing P2P Conferences:
> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
> 
>