3 ms·

There’s two issues here- 1) They switched away from UDP, now use TCP. So NAT traversal / punching isn’t possible. 2) Even if UDP was used there’s still some n

There’s two issues here- 1) They switched away from UDP, now use TCP. So NAT traversal / punching isn’t possible. 2) Even if UDP was used there’s still some network setups that aren’t traversal friendly, such as most cellular/LTE networks where port mappings are unpredictable.

eps 8y ago
TCP-based NAT punching is perfectly possible. Not that it’s needed often in systems that employ punching (due to it being a fallback option if UDP is unavailable), but it’s easy to do and works well.
- viraptor 8y ago
  How does that work? NATs (usually?) track TCP state. That means party A sends a SYN and will only pass in SYN-ACK. Party B's NAT drops SYN on the floor. Same happens the other direction. It works for UDP because there's no concept of an established connection, but TCP?
  - eps 8y ago
    Look up something called Symmetrical TCP Open.
    - viraptor 8y ago
      Name in papers: stunt, natblaster, p2pnet. They mostly depend on raw sockets unfortunately. And: > Similarly, adding port prediction to the P2PNAT approach allows it to handle symmetric NATs increasing its success rate to 84.3% Interesting that it works, but doesn't seem very reliable.
      - eps 8y ago
        You are reading wrong papers :) Clients A and B connect to a rendezvous host. R looks at A and B's ports, guesses which ports they will use for the next connection and instructs them to connect to each other respectively. First SYN packets are lost, but they poke holes, so on the retry the symmetrical open kicks in and peers hook up into a shared TCP connection. The end.
        viraptor 8y ago
        Again, that's only if the NAT allows this. Not all of them do and not all of them will have predictable port mappings. See http://www.ijimt.org/papers/226-G0027.pdf http://www.ijimt.org/papers/226-G0027.pdf for example for details about what works when.
        eps 8y ago
        It's been a while since I worked on this, but back then over 80% NAT devices used simple +1 port allocation. Some fraction was using other increments and only OpenBSD used truly random overloading. The main issue with port prediction in general wasn't making it per se, but making it quick enough so that it won't expire. From what I remember ingress TCP filtering was universally very dumb - if there was a SYN out, anything on the same quartet of IP/ports was allowed in. That was on a sample of several thousand devices, though most of these were of consumer grade. It was also few years before the paper you linked to above.

eps 8y ago

TCP-based NAT punching is perfectly possible. Not that it’s needed often in systems that employ punching (due to it being a fallback option if UDP is unavailable), but it’s easy to do and works well.

viraptor 8y ago
How does that work? NATs (usually?) track TCP state. That means party A sends a SYN and will only pass in SYN-ACK. Party B's NAT drops SYN on the floor. Same happens the other direction. It works for UDP because there's no concept of an established connection, but TCP?
- eps 8y ago
  Look up something called Symmetrical TCP Open.
  - viraptor 8y ago
    Name in papers: stunt, natblaster, p2pnet. They mostly depend on raw sockets unfortunately. And: > Similarly, adding port prediction to the P2PNAT approach allows it to handle symmetric NATs increasing its success rate to 84.3% Interesting that it works, but doesn't seem very reliable.
    - eps 8y ago
      You are reading wrong papers :) Clients A and B connect to a rendezvous host. R looks at A and B's ports, guesses which ports they will use for the next connection and instructs them to connect to each other respectively. First SYN packets are lost, but they poke holes, so on the retry the symmetrical open kicks in and peers hook up into a shared TCP connection. The end.
      - viraptor 8y ago
        Again, that's only if the NAT allows this. Not all of them do and not all of them will have predictable port mappings. See http://www.ijimt.org/papers/226-G0027.pdf http://www.ijimt.org/papers/226-G0027.pdf for example for details about what works when.
        eps 8y ago
        It's been a while since I worked on this, but back then over 80% NAT devices used simple +1 port allocation. Some fraction was using other increments and only OpenBSD used truly random overloading. The main issue with port prediction in general wasn't making it per se, but making it quick enough so that it won't expire. From what I remember ingress TCP filtering was universally very dumb - if there was a SYN out, anything on the same quartet of IP/ports was allowed in. That was on a sample of several thousand devices, though most of these were of consumer grade. It was also few years before the paper you linked to above.