Re: [GNUnet-developers] Bad News

[Christian Grothoff]

On 10/03/2015 07:14 PM, John Michael Lafayette wrote:
> *Also, reason against implementing predictive UDP flooding/punching:*
> 
> While a little evidence suggests that Skype has already implemented a
> predictable UDP port allocation work around for SOHO routers:
> 
> "The Skype server knows that Bob is talking to it from port 31234, but the
> connection to Alice will run via a different port. But even here Skype is
> able to outwit the firewall. It simply runs through the ports above 31234
> in sequence, hoping at some point to stumble on the right one." (
> http://www.h-online.com/security/features/How-Skype-Co-get-round-firewalls-747314.html
> )

That's an article from 2006.  It is unlikely to still apply in exactly
this way. And yes, I was aware of this.

> I still don't think it's worth implementing because I can't find any real
> routers out in the streets that increment the port number like this
> anymore. Even small businesses that I go to have random port allocation.
> Not only that, but a number of routers now have a feature called "flooding
> protection" that blocks subsequent packets after a fixed number of failed
> connection attempts, so guessing port numbers willy nilly might cause the
> router to block subsequent packets from your ip.

Question is: can we detect this? We should implement a 'modern' version
of STUN that detects the type of router (including flood protection:
yes/no) and then act accordingly.

> *Also, reasons for/against implementing TCP hole punching:*
> 
> As for the other types of NAT traversal, correct me if I'm wrong, but I
> don't think that you have TCP hole punching, but there are serious
> challenges with this approach.

We don't have TCP hole punching (yet).

> "Establishing a TCP connection in this way is, however, not quite so
> simple, because Alice does not have the sequence number sent in Bob's first
> packet. The packet containing this information was discarded"
> 
> Because of this, an intermediary server (mutual friend node, etc.) has to
> be used to transport the sequence number of the other host's discarded SYN
> packet. Not only that, but sometimes, this failed connection attempt
> results in an error packet coming back to the sender and killing the
> listening connection.

Yes, most hole punches require a facilitating peer. And while there is a
risk of dishonesty in the facilitator, I think that's still preferable
over always routing all traffic via such a facilitator.

> According to a paper entitled "NATBLASTER
> <http://natblaster.sourceforge.net/paper/natblaster.pdf>", sometimes if
> short TTL packets are used (probe TTL to find NAT depth and then outgoing
> packets with that TTL), the router won't forward any error messages to the
> sender, but this isn't guaranteed and in that case the the program would
> have to request that the operating system's firewall silently drop RST
> packets using a command like...
> system("iptables -A INPUT -p tcp -d host.ip.address --dport 1194
> --tcp-flags RST RST -j DROP")
> 
> After the SYN packet is sent and the sequence number is relayed (through
> port 80 or 443), each host has to construct a fake SYN-ACK reply using raw
> sockets and the other host's address/port/sequenceNumber. And of course the
> block on incoming RST reset packets has to be turned off. This is operating
> system dependent and on operating systems that do not have the ability to
> filter out RST packets, the rate of success may be reduced.

RST packets are also used by attackers (like the great firewall) to drop
ongoing TCP connections. So the ability to (selectively?) ignore RST
packets would be beneficial beyond just NAT traversal.  Maybe we can
implement a setsockopt() call to 'ignore RST' for a TCP socket?
(Crazy-ideas++).

> And then after all that effort, it still might fail when one end has both
> unpredictable port allocation and flooding protection or if both ends have
> unpredictable port allocation without flooding protection. TCP hole
> punching is only good for public networks that only allow outgoing TCP.
> 
> Then of course you have relaying. Skype heavily cuts bandwidth when
> relaying is used. Like in my case it dropped video quality down to like
> 320x200 pixels. And it might be possible if the data isn't encrypted to
> make the relay data look like HTTP data in case the data has to go through
> some sort of invasive packet filtering/logging process. But besides those
> three techniques (predictive UDP flooding, TCP hole punching, and clever
> relaying with reduced bandwidth), I don't know of any other options for
> improving NAT traversal success. Given that TCP hole punching may be more
> effective that predictive UDP flooding when outgoing UDP packets are
> blocked, this might be a better technique for getting around
> non-carrier-grade SOHO routers.

Usually, modern NAT traversal always means you implement a bunch of
techniques, plus some logic to figure out which one(s) are most likely
to work.  There is no one magic bullet.  For GNUnet, we should strive to
support more and more techniques over time, and ideally to
auto-configure them as much as possible. That's the only option -- and
the key reason why transport/ and nat/ are inherently messy subsystems.

-Christian

> 
> On Fri, Sep 25, 2015 at 4:13 AM, Christian Grothoff <address@hidden>
> wrote:
> 
>> 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.
>>
>

signature.asc
Description: OpenPGP digital signature