That is essentailly what we do, use TCP protocol header only and treat it like UDP.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Pevzner Sent: Friday, December 15, 2006 4:36 PM To: theory and practice of decentralized computer networks Subject: [p2p-hackers] Re: A new approach to NAT/Firewall traversal Jeff Capone wrote: > Alex, > > Some firewall do not let UDP in or out. The advantage with TCP is > even if you have a very restricted firewall on one side, the outbound > connection will look like a normal tcp open to it and it will allow > the connection to form. I understand it very well. Now imagine, you do everything as with UDP packets, but use manually generated TCP packets instead. Router think that this is TCP stream, OS network stack doesn't see your traffic at all (because it is generated and handled by your driver), and you have a whole freedom to send whatever and when you need. The only cost, you will have to properly setup TCP header fields, so router will think it sees the normal TCP stream. > True, we just do not want another application to use that port. But > we do use the native tcp stack in the connection setup so we do not > have to generate all the packets. I believe the effort required to fool the TCP stack is higher that effort to generate all packets by yourself. After all, you can always use source code from the excellent BSD stack, freely available. But well, now I understand you position. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Alexander > Pevzner > Sent: Friday, December 15, 2006 4:20 PM > To: theory and practice of decentralized computer networks > Subject: [p2p-hackers] Re: A new approach to NAT/Firewall traversal > > Jeff Capone wrote: >> Actually, 2 simultanous opens rarely works from what we have seen >> since it is unlikely that the SYN packets from both sides will make >> it through. It is possible, that on one side, since a SYN when out, >> the SYN from the other side may make it in, but that is not typically >> the case. So to gurantee that the SYN makes it in, we send it >> through the out of band channel and inject it into the adapter so the >> TCP layer thinks it actually made it through the firewall. The OS >> TCP layer will even send the SYN-ACK. Once the control information >> is passed through to the TCP stack of the OS, it will not see any of >> the actual traffic, just keep alive traffic. Our stack will manage >> the traffic at > this point forward. > > I just wonder, if you have your own TCP stack, why bother with sending > the proper SYN packets to the OS-native TCP stack? > > You might simply use TCP "as UDP" to fool the routers. I mean, you > might use TCP packets (generated and processed by your own stack) as > UDP packets usually used, and you only need to maintain the valid > SYN/ACK/FIN flags and sequence numbers to make router an illusion that > it sees the normal TCP stream. > > At this case there is only one interference with the native TCP stack: > you must reserve TCP port numbers in the native stack, that are > actually used by your software. This is very easy to do, though... > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
