I can give you more real-world statics once we have more users :)! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Pevzner Sent: Friday, December 15, 2006 5:00 PM To: theory and practice of decentralized computer networks Subject: [p2p-hackers] Re: A new approach to NAT/Firewall traversal
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 _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
