Hi John, Thanks for the interesting update. As I think this is something that should really be shared more broadly, I've allowed myself to put the list in CC.
I must admit that I was a bit surprised about the initial claim that the CG-NATs would be easily traversed, so I'm not too shocked that you found out that this is not true. But good research can also be about refuting bogus claims by other researchers, so thank you for finding out that the punching will not work for CG-NATs. I do think that implementing HTL/TTL-based hole punching for GNUnet would still be useful as not (yet) everybody is behind a CG-NAT, and for SOHO-NATs this seems to still be a reasonable (albeit also not failure-proof) strategy. Most importantly, I think your point about ICMP-permission DGRAM sockets is important, but mostly because your Java code shows that we can use non-SUID code to figure out our external IP address. So something like that should go into the NAT autoconfiguration logic. As for my paper being flawed, I don't think you can blame a paper from 2010 for not mentioning/using a kernel feature implemented in 2011. However, you are right in that in 2015, we should start to consider using a 2011 kernel feature. However, there is more to autonomous NAT traversal than just sending an ICMP packet. We also need to control the 'identification' field in the IP header. As I don't see how even the 2015-kernel allows setting the IP identification field, I think you're wrong and the paper is still right and you still do need RAW sockets. But, please do prove me wrong, as I'm always happy to remove/replace SUID code in GNUnet ;-). Happy hacking! Christian On 09/24/2015 06:33 PM, John Michael Lafayette wrote: > Hey Christian, > > I have bad news regarding the symmetric NAT traversal implementation. > The papers that I was basing my implementation on implied that most > large scale NATs would have a predictably port allocation strategy and > suggested that of those that had a random port allocation strategy, > penetration may be statistically likely because packets might be allowed > to come back in from a port other than the target port. Both of those > assumptions appear to be wrong - one because most large scale NATs > either are not symmetric (can be hole punched with traditional > techniques) or they are completely random and only accept incoming > packets from their destination port and thus would require hundreds of > thousands of UDP packets to establish a connection. This lengthy hole > punching process might do-able done in theory because the mobile > broadband routers give me a full 60 seconds to inject packets to > establish a UDP connection and they also lack flooding protection, but > in practice is would be too time and data consuming for any normal user. > Testing multiple variations of the technique with 10,000 or more packets > has failed repeatedly. > > The fact that a few mobile broadband routers are built in such a way > that their port allocation schemes are predictable, allowing for both > easy traversal and ip address compaction, but that most are not implies > that the carriers and/or their vendors do not place a high value on > allowing for peer-to-peer connections between users behind large scale nat. > > I think I can safely say that this notion (and the corresponding > research) which says that large scale NAT can be effectively traversed > with the short-long ttl strategy is bogus. > > John > > p.s. In your paper on ICMP hole punching, there's a little flaw. It says > that sending ICMP_ECHO requests and receiving the error reply from that > request requires root permissions on Linux. I believe that is the case > on Mac and on a few Linux variants, but that many/most Linux computers > support these features with a restricted icmp-permissions DGRAM socket.
0xE29FC3CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
