Jeff Capone wrote: > That is essentailly what we do, use TCP protocol header only and treat it > like UDP.
Do you have a reasonable big statistics? What is probability of successful NAT traversal using your approach? I mean not a statistics gathered in the lab by combining all router pairs you have, but a real world statistics? > -----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
