[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Bad News

From: Christian Grothoff
Subject: Re: [GNUnet-developers] Bad News
Date: Fri, 25 Sep 2015 10:13:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0

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!


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. 

Attachment: 0xE29FC3CC.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]