10 ms·

The State of NAT Traversal

189 points by api 12y ago

2bluesc 12y ago
I think the vast majority of my IPv6 traffic is to sites who also care about security (or care about networking in general?) and consequently use TLS where possible. Anyone know on any stats regarding popular sites reachable over IPv6? For example, what percentage redirect the requests to TLS by default?
Zarathust 12y ago
But as a side bonus, nearly every home computer now have a poor man firewall. I find this to be insanely important for the global internet security.
- api 12y ago
  It is, but mostly because popular operating systems have historically had poor application isolation and vulnerable services. My personal opinion is that having to have a firewall everywhere in front of everything is a hack that was put into place because of awful OS security, and will become less important as OS security improves.
  - eli 12y ago
    And/or you just substitute a NAT that happens to also function like a firewall with a proper firewall. The router could do the same sort of filtering as NAT would entail, but not require a hacky NAT table.
    - VLM 12y ago
      Or rephrased its not possible to implement "working" NAT without a stateful firewall, but the lack of NAT doesn't imply its impossible to deploy a stateful firewall. (It would be interesting to research where this "can't have a stateful FW without NAT" meme came from. It is VERY popular among everyone but network guys)
- anderiv 12y ago
  This doesn't change with the vast majority of residential IPv6 deployments. Many people conflate having a public IP address with not having a firewall. This is not the case at all. Yes, internal clients will get public, routable IPv6 addresses. They are still behind a firewall, though, and you have just as much control over ingress and egress traffic as you did before.
  - userbinator 12y ago
    The difference is in the isolation factor: there is absolutely NO way a packet with an internal IP can get anywhere on the public Internet, and likewise a packet with a public IP will never be accepted by a device that has been configured with an internal one. The failure modes are different - although firewalls can be configured to provide an "outgoing connections only" default like NAT, they are also software and thus not immune to bugs; a buggy firewall letting packets through which shouldn't be is far worse than a buggy NAT.
    - oasisbob 12y ago
      there is absolutely NO way a packet with an internal IP can get anywhere on the public Internet That very much depends on your definition of "public internet." My service provider doesn't properly filter RFC1918 space at their border. From my home on the west coast, I can hit 10.0.0.0/8 devices on the east coast in a separate AS. Is a reachable printer web interface 3000 miles away in New York on the public internet? The "Internet" is a very tough entity to define succinctly, but I'd argue yes.
      - graylights 12y ago
        Why would you need to filter an internal IP as a destination IP, routing should handle that. I understand filtering the source address as internal IP because that could be malicious spoofing of internal host (and destination can't legitimately reply.)
  - maxhou 12y ago
    The problem is that all NAT related issues are not because of NAT itself, but because of the required stateful firewalling for NAT. To be able to NAT and un-NAT, you first need to classify traffic (that NEW, ESTABLISHED, RELATED,... stuff in Linux netfilter), changing the destination or source ip addresses is only the second part of that process. Protocols don't break only because of NAT, but mostly because of stateful firewalling, you'll face the same problems with IPv6 if you enable it.
- userbinator 12y ago
  Agreed; despite what many seem to think I don't believe that every device on a network should have a public IP by default. Even if the whole Internet becomes IPv6-only I'll probably still keep my home network behind a NAT router on a private subnet. As the recent series of articles on "smart" appliance security shows, many are exploitable through services listening on ports which the user normally isn't aware of. I would certainly not want a bigger number of those exposed to the public Internet than there already are.
  - anderiv 12y ago
    See my comment on the parent...having a public IP address does not mean that it's accessible from the internet.
    - simoncion 12y ago
      This might be a totally off-topic tangent. I apologize if it is. It seems to me that if consumer routers are configured to refuse to forward inbound IPv6 packets to machines on the LAN, we would be in almost exactly the same situation vis a vis home service hosting as we are with IPv4 addresses, NATs, and automated port forwarding protocols. Frankly, this would be a giant step backwards from IPv6 as she is envisioned. From what I understand, the "average" home user has little to no idea of what a port is or why one might want to forward it. They are also very likely to be incapable of classifying machines that need not be globally reachable. So, either we have to write smart software that can determine whether or not a network device requires protection from inbound traffic, or we have to make a forwarding policy decision for this user when we send them their router. If we're serious about IPv6, we shouldn't configure our gateway devices to require the software that we write to assume that a globally-reachable address is likely to actually not be globally-reachable.
      - api 12y ago
        It would be slightly less evil without NAT. You'd still need the three-party handshake but it would always work. You'd no longer have the symmetric NAT craziness. You could also dispense with the need for frequent keepalives, a boon to mobile battery life. Getting rid of NAT is step one. Step two is deperimeterization: getting rid of in-line firewalls. Step two is going to have to wait on OSes having better service encapsulation and app isolation models and for programmers to remove their heads from their behinds and stop writing code that is vulnerable to stack-smashing and buffer overflow attacks. The last part will be tough. How much longer will the Sun be a main-sequence star? :)
- mutagen 12y ago
  I used to feel this way but I've come to the opposite conclusion. Most homes have a rarely updated, always on computer connected to the public internet with increasing numbers of known vulnerabilities.
JoeAltmaier 12y ago
Its lots more complicated than ZeroTier would have you believe, especially for Enterprise clients. That can add wrinkles due to VPNs, firewall filtering, non-symmetric packet forwarding. And there's the case of two clients inside the same subnet - to go P2P using the described algorithm requires something called Router Hairpinning which has spotty support. There are ways around all that, and Sococo supports them all. (Caveat: I work at Sococo).
- api 12y ago
  Two hosts in the same subnet is best achieved using LAN locator beacons that allow direct connectivity without involving the server at all. ZeroTier, Dropbox, and I think Skype all do that, though ZeroTier could do it better (there's an issue to improve it).
  - JoeAltmaier 12y ago
    Sure; but again assumes a simple subnet configuration. Lots of enterprise customers have multiple subnets with gateways, internal routers etc. They probably won't respect/forward LAN locator beacons. We (Sococo) gave up on that approach, particularly since Enterprise IT guys like to get excited about broadcast UDP wandering around their subnet. A straightforward approach is, when talking with the 'rendezvous' server, to include in the message your discovered local subnet address(es). Then the server can inform your peer of the entire set of candidate IP addresses you might be available at (NATted address + subnet addresses). P2P connection pinging then works the same way, with the additional constraint that the 1st P2P message must include a unique id to identify the peer. Because non-routable subnet addresses can be re-used (10.x.x.x or 192.168.x.x style). You don't want to try to connect to Alice and discover that XRay has the same subnet address, XRay is available on your subnet, and XRay is also running the same P2P app. Anyway like I mentioned, its complicated and full of wrinkles.
    - idlewords 12y ago
      The article takes up this very idea and dismisses it because it leaks info about private networks.
2bluesc 12y ago
If only I had someone else to talk to on IPv6 other than Gmail or YouTube. +1 to Google for caring more than most and thanks to Comcast for giving me a IPv6 /60 prefix delegation natively. :)
asdffdsajkl 12y ago
I found this twitter post interesting - the dude did a writeup of how to use metasploit when both the attacker and the victim are behind nat and you are able to get code execution some how on the victim: https://twitter.com/b1tripper/status/383085600040947712 https://twitter.com/b1tripper/status/383085600040947712
simmons 12y ago
This a nice summary; I was actually thinking about doing my own writeup of this very thing. I have a few thoughts beyond what was covered in the blog post: For many protocols and modes of communication, UDP is really lousy for the developer -- we end up re-inventing TCP (congestion control, retransmission, etc.). Unfortunately, if we want to traverse NAT, we often must rely on UDP hole punching and thus use UDP. There's a TCP hole punching technique called "TCP simultaneous open", but it seems too flaky to expect to work in the real world. I've been thinking about trying UDT [1] as a user-mode TCP-like connection layer over UDP. In addition to the ugly UPnP technique for asking a router to automatically port-forward, there have been attempts to standardize a much simpler solution in NAT-PMP and it's successor, PCP. (PCP even works for IPv6 stateful firewalls.) Many people do have security concerns about this capability. I don't know to what extent NAT-PMP/PCP has made inroads into the router market -- it would be interesting to conduct some sort of survey. [1] http://udt.sourceforge.net/ http://udt.sourceforge.net/
- simmons 12y ago
  Also, the article frequently mentions a 120-second timeout interval, within which the connection needs to be refreshed. In Linux (and thus most consumer routers?), I believe the timeout is actually 30 seconds for UDP. :(
  - zrm 12y ago
    The 120 second interval is the minimum from RFC4787 Sec. 4.3 REQ-5. (There is an exception that permits shorter intervals but only for specific ports, in particular port 53 for DNS.) If Linux is using 30 seconds then it's in violation and someone should submit a bug report.
    - dvanduzer 12y ago
      Privileged ports were a broken security model to begin with. Consider a a distributed system that relies on that minimum 120 second interval when determining whether to send a keepalive. Failure to send one within this interval would create an otherwise easily avoided network partition. Consider someone adapting this system to operate across a restricted network which only permits traffic on privileged ports to traverse its border. Suddenly idle connections can be purged well under that previously safe two minute window. Instant partition. Whether Linux implements the conditional to distinguish between privileged and unprivileged ports is irrelevant. Any serious systems designer must consider the timeout interval to be 30 seconds.
yry4345 12y ago
> "Lots of people think NAT is a show-stopper for peer to peer communication, but it isn’t. More than 90% of NATs can be traversed, with most being traversable in reliable and deterministic ways." All the traversal methods require coordination with a 3rd party (ie: centralized) server so - yes - this is a show stopper for P2P. As public addresses become more scarce, and carrier NAT becomes common, the problem of finding that intermediary will only get worse. IPv6 should be a solution, but it won't get off the ground if carrier NAT gets priority, for example. (Or if ISPs just put firewalls everywhere, and other "best practices"...)
- zrm 12y ago
  > All the traversal methods require coordination with a 3rd party (ie: centralized) server so - yes - this is a show stopper for P2P. Third party and centralized aren't the same thing. Any peer with a real public address or even a manual port mapping or a router that supports NAT-PMP or PCP can play the role of the "server" in this context.
  - yry4345 12y ago
    In order to boot strap a connection to a P2P network, one must contact a well-known server. It doesn't matter if the well known server is a "peer" that happens to be running the same software, or if it's the BitTorrent DHT bootstrap servers, what matters is that that peer has a disproportionate amount of authority and influence over the network, amounting to a single point of censorship or failure. NAT (and firewalls anywhere except the networked computer - even at the subscriber's router) contribute to/create this asymmetry, where one side has to beg to connect to another, and so everyone winds up settling on the most-memorable 3rd party. Everyone has heard of the king (or Verisign), and so the rich get richer...
    - zrm 12y ago
      There is no requirement that it be a single node or that they all be operated by the same party.
cdoxsey 12y ago
Actually this is entirely achievable right now, with very little code. You can use WebRTC in chrome / firefox, which implements all the nasty details of peer-to-peer communication for you (and uses TLS-esque security). All you need is a STUN / TURN server and something to do the initial handshake and you're off to the races. I've not gotten around too it, but someone should setup a webserver that speaks the protocol (perhaps with this: https://code.google.com/p/libjingle/ https://code.google.com/p/libjingle/) then you serve your site as a static HTML file on AWS or similar, spin up WebRTC, and then communicate with your server that way. Now you can serve a whole website sitting behind a firewall.
zrm 12y ago
> Some NAT devices support various methods of intentionally opening ports from the inside. The most common of these is called Universal Plug-and-Play (UPnP). UPnP should be avoided whenever possible. It's a hideous protocol. NAT-PMP (originally from Apple, now RFC6886) is dramatically simpler and ideal for small networks. Its successor NAT-PCP (RFC6887) is only slightly more complicated in order to better deal with large enterprise networks.
dxhdr 12y ago
It's surprising that the number of non-traversable hosts is only 4-8%. Aren't most cellular (3G/4G) users behind symmetric NAT, or is this considering only PC users?
- callesgg 12y ago
  All the cellar stuff I have used in the last 5 years have given me public open ip addresses. So i don't think that is the case.
  - dmm 12y ago
    As of at least summer 2013 Sprint no longer offers public ips with new phones. It's all carrier-grade NAT. T-Mobile is the same but they provide ipv6, though with just a single ipv6 address which doesn't make any sense. I'm not sure about the other carriers.
- RustyRussell 12y ago
  Their product doesn't do mobile, that's why. My 3G in Australia is definitely NATed (and the source address the other end sees seems to change with each cell!).
  - api 12y ago
    NAT isn't why it doesn't do mobile. It doesn't do mobile yet because there are issues around battery life that have to be solved. Mobile will take the addition of a sleep mode and the use of mobile push notification busses.
- api 12y ago
  I didn't mention carrier-grade NAT, but it's almost always full-cone and traversable. ZeroTier works behind tethering behind carrier-grade cellular NAT.
zurn 12y ago
So true in the kittens dept. The worst part is that while this situation has been developing, Stockholm syndrome has taken hold and half the battle is convincing people to be receptive to having real IP addresses again! Few people know the difference between a NAT box and firewall anymore, and "router" now means NAT box to many people.
- jmspring 12y ago
  In the case of many consumer/desktop machines, being behind a NAT is a very useful first tier security barrier. Every machine being fully reachable -- say via IPv6? I foresee many IT headaches and the Nortons/McAffees of the world raking in more money.
  - zrm 12y ago
    NAT != firewall. You can have a firewall without NAT. Probably the sensible thing to do for IPv6 is to make the default to block the ports of specific applications people don't canonically expect to be visible from the internet, like Windows file sharing or telnet or HP JetDirect, but allow everything else so that VoIP and other P2P apps will all work properly.
    - Wilya 12y ago
      Of course you can do without a NAT. But the NAT has the advantage to make the firewall rules trivial to write. Put "DROP all packets with destination 192.168.0.0/16 coming from the external interface", and a few other boilerplate rules of the same kind, and poof: you just secured 99.9% of the NAT-ed networks. No configuration required. To do the same without a NAT, you need at the very least to adapt the rules to the IP addresses of the machines behind the firewall, which add complexity and increase the likelihood someone will screw up the configuration. And, hu, please don't open ports by default. That's just a recipe for disaster. If apps really want to open a globally accessible port, make them explicitly signal that to the firewall so it opens access.
      - deleted 12y ago
maqr 12y ago
> Ziggy then sends a message to both Alice and Bob. The message to Alice contains Bob’s public IP and port, and the message to Bob contains Alice’s. Is this done by modifying the source address on the outgoing UDP packet? If so, wouldn't modern filtering prevent the spoofed packets from getting to their destination?
- anemic 12y ago
  no, ziggy just acts as a directory of public ip addresses. Once alice and bob know each other's public ip they can start communicating each other. Suppose alice is at A.A.A.A:1234 and bob is at B.B.B.B:5678. Alice sends A.A.A.A:1234 -> B.B.B.B:5678 and bob simulataneously sends B.B.B.B:5678 -> A.A.A.A:1234 When the packets arrive to the routers the NAT already has an opposite rule because of the sent packet. As this is UDP there is no SYN-ACK handshake or other state tracking information in the packets and they traverse the NAT.
cornewut 12y ago
I'm somehow not convinced IPv6 is the solution - someone somewhere will just decide to nat IPv6.
- dspillett 12y ago
  > someone somewhere will just decide to nat IPv6 And that will be their choice, and any problems caused will be their's (or their customers') to face. With the current state of IPv4 there is between little and no choice so NAT can't be directly thought of as "doing it wrong", with IPv6 that would not be the case.
- login01 12y ago
  Cisco has been working on pushing NAT as a standard for IPv6 - Why? Sell's more boxes and training!
  - mprovost 12y ago
    Or maybe their customers are asking them for it?
captainmuon 12y ago
> Another difficult situation arises if two peers are actually on the same local network behind the same NAT router. ... > It might be tempting for peers to encode their private IP address and send it to the intermediate server and/or to the other peer. I thought about this when writing ZeroTier. On the plus side, this would work even on large segmented networks where UDP broadcasts don’t make it everywhere. But the problem is that this exposes internal configuration details about the network to potentially random external peers. Many network security administrators are not going to like that, so I decided against it. I tried to think of a way to anonymize the data but couldn’t, since the IPv4 private address space is so small that no form of hashing will adequately protect against exhaustive search. I wonder if it would be possible to encrypt the local address with the internal MAC address of the router/gateway. Then only nodes seeing the same router could decode the information. I also wonder how Dropbox does this (it can tell when two connected computers are on the same LAN, and transfers files directly).
- Maakuth 12y ago
  Dropbox does the UDP broadcast thing. Try dumping packet in pretty much any LAN today and you see their broadcasts flying around.
  - nly 12y ago
    I see Dropbox traffic hitting my servers. People evidently rent Windows dedis, install Dropbox on them, and they spew out broadcast to the local /24
- richardwhiuk 12y ago
  I know that Dropbox uses multicast packets to announce itself to other nodes. I'd have thought that encrypting the local address with the public IP address of the gateway would be a better solution?
  - Perseids 12y ago
    Neither the IP address nor the MAC address contain enough entropy to make that secure. Even assuming they were completely random, 32 and 48 bit keys can be bruteforced in no time. Additionally the MAC address contains mostly static or easily guessable values and the public IP address is, well, public. Thus even key strengthening along the lines of PBKDF2/bcrypt/scrypt is hopeless.
unwind 12y ago
"The terminology used is somewhat confusing… I’m not really sure what is meant by a “cone.”" I think the linked-to Wikipedia page makes it pretty clear, it's simply a reference to the conical (funnel-like) shape of the right-hand side of the illustration (http://en.wikipedia.org/wiki/Full_cone_NAT#Methods_of_port_translation http://en.wikipedia.org/wiki/Full_cone_NAT#Methods_of_port_t...). Full-cone NAT allows inbound connections from any external host, i.e. it's an unrestricted funnel (or cone).
IgorPartola 12y ago
This is why I IPv6: https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html
- simmons 12y ago
  I'm also anxiously awaiting the rise of IPv6, but I'm guessing that -- in a sane world -- consumer routers will still default to a stateful firewall for IPv6, thus necessitating the continued need for hole punching. :/
  - richardwhiuk 12y ago
    Hole punching will be very reliable though - each end picks a port and starts talking to the other end at roughly the same time. Once they both start talking to each other, the flow will be fine.
julie1 12y ago
NAT may kill kittens, but IPv6 is killing polar bears massively. I recommend the lecture of this: https://www.nanog.org/meetings/nanog46/presentations/Sunday/RAS_Practical_ipv6_61309_N46.pdf https://www.nanog.org/meetings/nanog46/presentations/Sunday/... (deployment document of ipv6) then proceed to the glitches section. I recommend reading nanog mailing list for having a glimpse on the added complexity of dealing with IPv6 in real life. Just peak random mails, it pops up once a month. Like for instance provider turning to LS (Large Scale) NATing or Carrier Grade NATING rather than going IPv6 for rationnale reason: IPv6 engineers are hard to find and LSNAT (+dual stack eventually) since China has proven valid has both a way to handle the scarcity of IPv4 addresses and the need to control user's traffic. http://mailman.nanog.org/pipermail/nanog/2014-July/068892.html http://mailman.nanog.org/pipermail/nanog/2014-July/068892.ht... IPv6 is not bad, it is kind of bloated and requires a tinge more training than IPv4. Plus there are the concerns about privacy (but some IPV6 guru will come up with ULA or another obscure trick. It is IPv6 realm: everything is clear on the paper but is seems confusing to quite a few real life engineers since it requires a lot of RFC stacking in the brain)
- api 12y ago
  > and the need to control user's traffic. Some of us think that's a bad thing :) > Plus there are the concerns about privacy IPv6 has privacy extensions that allow address randomization, and its address space is so large it makes it easy to just make up addresses. Besides, tracking IPs is really only one of hundreds of ways of tracking you on the Internet.
danbruc 12y ago
In some situations Teredo [1] may get the job done. [1] http://en.wikipedia.org/wiki/Teredo_tunneling http://en.wikipedia.org/wiki/Teredo_tunneling
lectrick 12y ago
More like "Where the hell is IPV6 already?" :)

189 points by api 12y ago

I think the vast majority of my IPv6 traffic is to sites who also care about security (or care about networking in general?) and consequently use TLS where possible. Anyone know on any stats regarding popular sites reachable over IPv6? For example, what percentage redirect the requests to TLS by default?

Zarathust 12y ago

But as a side bonus, nearly every home computer now have a poor man firewall. I find this to be insanely important for the global internet security.

api 12y ago
It is, but mostly because popular operating systems have historically had poor application isolation and vulnerable services. My personal opinion is that having to have a firewall everywhere in front of everything is a hack that was put into place because of awful OS security, and will become less important as OS security improves.
- eli 12y ago
  And/or you just substitute a NAT that happens to also function like a firewall with a proper firewall. The router could do the same sort of filtering as NAT would entail, but not require a hacky NAT table.
  - VLM 12y ago
    Or rephrased its not possible to implement "working" NAT without a stateful firewall, but the lack of NAT doesn't imply its impossible to deploy a stateful firewall. (It would be interesting to research where this "can't have a stateful FW without NAT" meme came from. It is VERY popular among everyone but network guys)
anderiv 12y ago
This doesn't change with the vast majority of residential IPv6 deployments. Many people conflate having a public IP address with not having a firewall. This is not the case at all. Yes, internal clients will get public, routable IPv6 addresses. They are still behind a firewall, though, and you have just as much control over ingress and egress traffic as you did before.
- userbinator 12y ago
  The difference is in the isolation factor: there is absolutely NO way a packet with an internal IP can get anywhere on the public Internet, and likewise a packet with a public IP will never be accepted by a device that has been configured with an internal one. The failure modes are different - although firewalls can be configured to provide an "outgoing connections only" default like NAT, they are also software and thus not immune to bugs; a buggy firewall letting packets through which shouldn't be is far worse than a buggy NAT.
  - oasisbob 12y ago
    there is absolutely NO way a packet with an internal IP can get anywhere on the public Internet That very much depends on your definition of "public internet." My service provider doesn't properly filter RFC1918 space at their border. From my home on the west coast, I can hit 10.0.0.0/8 devices on the east coast in a separate AS. Is a reachable printer web interface 3000 miles away in New York on the public internet? The "Internet" is a very tough entity to define succinctly, but I'd argue yes.
    - graylights 12y ago
      Why would you need to filter an internal IP as a destination IP, routing should handle that. I understand filtering the source address as internal IP because that could be malicious spoofing of internal host (and destination can't legitimately reply.)
- maxhou 12y ago
  The problem is that all NAT related issues are not because of NAT itself, but because of the required stateful firewalling for NAT. To be able to NAT and un-NAT, you first need to classify traffic (that NEW, ESTABLISHED, RELATED,... stuff in Linux netfilter), changing the destination or source ip addresses is only the second part of that process. Protocols don't break only because of NAT, but mostly because of stateful firewalling, you'll face the same problems with IPv6 if you enable it.
userbinator 12y ago
Agreed; despite what many seem to think I don't believe that every device on a network should have a public IP by default. Even if the whole Internet becomes IPv6-only I'll probably still keep my home network behind a NAT router on a private subnet. As the recent series of articles on "smart" appliance security shows, many are exploitable through services listening on ports which the user normally isn't aware of. I would certainly not want a bigger number of those exposed to the public Internet than there already are.
- anderiv 12y ago
  See my comment on the parent...having a public IP address does not mean that it's accessible from the internet.
  - simoncion 12y ago
    This might be a totally off-topic tangent. I apologize if it is. It seems to me that if consumer routers are configured to refuse to forward inbound IPv6 packets to machines on the LAN, we would be in almost exactly the same situation vis a vis home service hosting as we are with IPv4 addresses, NATs, and automated port forwarding protocols. Frankly, this would be a giant step backwards from IPv6 as she is envisioned. From what I understand, the "average" home user has little to no idea of what a port is or why one might want to forward it. They are also very likely to be incapable of classifying machines that need not be globally reachable. So, either we have to write smart software that can determine whether or not a network device requires protection from inbound traffic, or we have to make a forwarding policy decision for this user when we send them their router. If we're serious about IPv6, we shouldn't configure our gateway devices to require the software that we write to assume that a globally-reachable address is likely to actually not be globally-reachable.
    - api 12y ago
      It would be slightly less evil without NAT. You'd still need the three-party handshake but it would always work. You'd no longer have the symmetric NAT craziness. You could also dispense with the need for frequent keepalives, a boon to mobile battery life. Getting rid of NAT is step one. Step two is deperimeterization: getting rid of in-line firewalls. Step two is going to have to wait on OSes having better service encapsulation and app isolation models and for programmers to remove their heads from their behinds and stop writing code that is vulnerable to stack-smashing and buffer overflow attacks. The last part will be tough. How much longer will the Sun be a main-sequence star? :)
mutagen 12y ago
I used to feel this way but I've come to the opposite conclusion. Most homes have a rarely updated, always on computer connected to the public internet with increasing numbers of known vulnerabilities.

JoeAltmaier 12y ago

Its lots more complicated than ZeroTier would have you believe, especially for Enterprise clients. That can add wrinkles due to VPNs, firewall filtering, non-symmetric packet forwarding. And there's the case of two clients inside the same subnet - to go P2P using the described algorithm requires something called Router Hairpinning which has spotty support. There are ways around all that, and Sococo supports them all. (Caveat: I work at Sococo).

api 12y ago
Two hosts in the same subnet is best achieved using LAN locator beacons that allow direct connectivity without involving the server at all. ZeroTier, Dropbox, and I think Skype all do that, though ZeroTier could do it better (there's an issue to improve it).
- JoeAltmaier 12y ago
  Sure; but again assumes a simple subnet configuration. Lots of enterprise customers have multiple subnets with gateways, internal routers etc. They probably won't respect/forward LAN locator beacons. We (Sococo) gave up on that approach, particularly since Enterprise IT guys like to get excited about broadcast UDP wandering around their subnet. A straightforward approach is, when talking with the 'rendezvous' server, to include in the message your discovered local subnet address(es). Then the server can inform your peer of the entire set of candidate IP addresses you might be available at (NATted address + subnet addresses). P2P connection pinging then works the same way, with the additional constraint that the 1st P2P message must include a unique id to identify the peer. Because non-routable subnet addresses can be re-used (10.x.x.x or 192.168.x.x style). You don't want to try to connect to Alice and discover that XRay has the same subnet address, XRay is available on your subnet, and XRay is also running the same P2P app. Anyway like I mentioned, its complicated and full of wrinkles.
  - idlewords 12y ago
    The article takes up this very idea and dismisses it because it leaks info about private networks.

2bluesc 12y ago

If only I had someone else to talk to on IPv6 other than Gmail or YouTube. +1 to Google for caring more than most and thanks to Comcast for giving me a IPv6 /60 prefix delegation natively. :)

asdffdsajkl 12y ago

I found this twitter post interesting - the dude did a writeup of how to use metasploit when both the attacker and the victim are behind nat and you are able to get code execution some how on the victim: https://twitter.com/b1tripper/status/383085600040947712 https://twitter.com/b1tripper/status/383085600040947712

simmons 12y ago

This a nice summary; I was actually thinking about doing my own writeup of this very thing. I have a few thoughts beyond what was covered in the blog post: For many protocols and modes of communication, UDP is really lousy for the developer -- we end up re-inventing TCP (congestion control, retransmission, etc.). Unfortunately, if we want to traverse NAT, we often must rely on UDP hole punching and thus use UDP. There's a TCP hole punching technique called "TCP simultaneous open", but it seems too flaky to expect to work in the real world. I've been thinking about trying UDT [1] as a user-mode TCP-like connection layer over UDP. In addition to the ugly UPnP technique for asking a router to automatically port-forward, there have been attempts to standardize a much simpler solution in NAT-PMP and it's successor, PCP. (PCP even works for IPv6 stateful firewalls.) Many people do have security concerns about this capability. I don't know to what extent NAT-PMP/PCP has made inroads into the router market -- it would be interesting to conduct some sort of survey. [1] http://udt.sourceforge.net/ http://udt.sourceforge.net/

simmons 12y ago
Also, the article frequently mentions a 120-second timeout interval, within which the connection needs to be refreshed. In Linux (and thus most consumer routers?), I believe the timeout is actually 30 seconds for UDP. :(
- zrm 12y ago
  The 120 second interval is the minimum from RFC4787 Sec. 4.3 REQ-5. (There is an exception that permits shorter intervals but only for specific ports, in particular port 53 for DNS.) If Linux is using 30 seconds then it's in violation and someone should submit a bug report.
  - dvanduzer 12y ago
    Privileged ports were a broken security model to begin with. Consider a a distributed system that relies on that minimum 120 second interval when determining whether to send a keepalive. Failure to send one within this interval would create an otherwise easily avoided network partition. Consider someone adapting this system to operate across a restricted network which only permits traffic on privileged ports to traverse its border. Suddenly idle connections can be purged well under that previously safe two minute window. Instant partition. Whether Linux implements the conditional to distinguish between privileged and unprivileged ports is irrelevant. Any serious systems designer must consider the timeout interval to be 30 seconds.

yry4345 12y ago

> "Lots of people think NAT is a show-stopper for peer to peer communication, but it isn’t. More than 90% of NATs can be traversed, with most being traversable in reliable and deterministic ways." All the traversal methods require coordination with a 3rd party (ie: centralized) server so - yes - this is a show stopper for P2P. As public addresses become more scarce, and carrier NAT becomes common, the problem of finding that intermediary will only get worse. IPv6 should be a solution, but it won't get off the ground if carrier NAT gets priority, for example. (Or if ISPs just put firewalls everywhere, and other "best practices"...)

zrm 12y ago
> All the traversal methods require coordination with a 3rd party (ie: centralized) server so - yes - this is a show stopper for P2P. Third party and centralized aren't the same thing. Any peer with a real public address or even a manual port mapping or a router that supports NAT-PMP or PCP can play the role of the "server" in this context.
- yry4345 12y ago
  In order to boot strap a connection to a P2P network, one must contact a well-known server. It doesn't matter if the well known server is a "peer" that happens to be running the same software, or if it's the BitTorrent DHT bootstrap servers, what matters is that that peer has a disproportionate amount of authority and influence over the network, amounting to a single point of censorship or failure. NAT (and firewalls anywhere except the networked computer - even at the subscriber's router) contribute to/create this asymmetry, where one side has to beg to connect to another, and so everyone winds up settling on the most-memorable 3rd party. Everyone has heard of the king (or Verisign), and so the rich get richer...
  - zrm 12y ago
    There is no requirement that it be a single node or that they all be operated by the same party.

cdoxsey 12y ago

Actually this is entirely achievable right now, with very little code. You can use WebRTC in chrome / firefox, which implements all the nasty details of peer-to-peer communication for you (and uses TLS-esque security). All you need is a STUN / TURN server and something to do the initial handshake and you're off to the races. I've not gotten around too it, but someone should setup a webserver that speaks the protocol (perhaps with this: https://code.google.com/p/libjingle/ https://code.google.com/p/libjingle/) then you serve your site as a static HTML file on AWS or similar, spin up WebRTC, and then communicate with your server that way. Now you can serve a whole website sitting behind a firewall.

zrm 12y ago

> Some NAT devices support various methods of intentionally opening ports from the inside. The most common of these is called Universal Plug-and-Play (UPnP). UPnP should be avoided whenever possible. It's a hideous protocol. NAT-PMP (originally from Apple, now RFC6886) is dramatically simpler and ideal for small networks. Its successor NAT-PCP (RFC6887) is only slightly more complicated in order to better deal with large enterprise networks.

dxhdr 12y ago

It's surprising that the number of non-traversable hosts is only 4-8%. Aren't most cellular (3G/4G) users behind symmetric NAT, or is this considering only PC users?

callesgg 12y ago
All the cellar stuff I have used in the last 5 years have given me public open ip addresses. So i don't think that is the case.
- dmm 12y ago
  As of at least summer 2013 Sprint no longer offers public ips with new phones. It's all carrier-grade NAT. T-Mobile is the same but they provide ipv6, though with just a single ipv6 address which doesn't make any sense. I'm not sure about the other carriers.
RustyRussell 12y ago
Their product doesn't do mobile, that's why. My 3G in Australia is definitely NATed (and the source address the other end sees seems to change with each cell!).
- api 12y ago
  NAT isn't why it doesn't do mobile. It doesn't do mobile yet because there are issues around battery life that have to be solved. Mobile will take the addition of a sleep mode and the use of mobile push notification busses.
api 12y ago
I didn't mention carrier-grade NAT, but it's almost always full-cone and traversable. ZeroTier works behind tethering behind carrier-grade cellular NAT.

zurn 12y ago

So true in the kittens dept. The worst part is that while this situation has been developing, Stockholm syndrome has taken hold and half the battle is convincing people to be receptive to having real IP addresses again! Few people know the difference between a NAT box and firewall anymore, and "router" now means NAT box to many people.

jmspring 12y ago
In the case of many consumer/desktop machines, being behind a NAT is a very useful first tier security barrier. Every machine being fully reachable -- say via IPv6? I foresee many IT headaches and the Nortons/McAffees of the world raking in more money.
- zrm 12y ago
  NAT != firewall. You can have a firewall without NAT. Probably the sensible thing to do for IPv6 is to make the default to block the ports of specific applications people don't canonically expect to be visible from the internet, like Windows file sharing or telnet or HP JetDirect, but allow everything else so that VoIP and other P2P apps will all work properly.
  - Wilya 12y ago
    Of course you can do without a NAT. But the NAT has the advantage to make the firewall rules trivial to write. Put "DROP all packets with destination 192.168.0.0/16 coming from the external interface", and a few other boilerplate rules of the same kind, and poof: you just secured 99.9% of the NAT-ed networks. No configuration required. To do the same without a NAT, you need at the very least to adapt the rules to the IP addresses of the machines behind the firewall, which add complexity and increase the likelihood someone will screw up the configuration. And, hu, please don't open ports by default. That's just a recipe for disaster. If apps really want to open a globally accessible port, make them explicitly signal that to the firewall so it opens access.
    - deleted 12y ago

maqr 12y ago

> Ziggy then sends a message to both Alice and Bob. The message to Alice contains Bob’s public IP and port, and the message to Bob contains Alice’s. Is this done by modifying the source address on the outgoing UDP packet? If so, wouldn't modern filtering prevent the spoofed packets from getting to their destination?

anemic 12y ago
no, ziggy just acts as a directory of public ip addresses. Once alice and bob know each other's public ip they can start communicating each other. Suppose alice is at A.A.A.A:1234 and bob is at B.B.B.B:5678. Alice sends A.A.A.A:1234 -> B.B.B.B:5678 and bob simulataneously sends B.B.B.B:5678 -> A.A.A.A:1234 When the packets arrive to the routers the NAT already has an opposite rule because of the sent packet. As this is UDP there is no SYN-ACK handshake or other state tracking information in the packets and they traverse the NAT.

cornewut 12y ago

I'm somehow not convinced IPv6 is the solution - someone somewhere will just decide to nat IPv6.

dspillett 12y ago
> someone somewhere will just decide to nat IPv6 And that will be their choice, and any problems caused will be their's (or their customers') to face. With the current state of IPv4 there is between little and no choice so NAT can't be directly thought of as "doing it wrong", with IPv6 that would not be the case.
login01 12y ago
Cisco has been working on pushing NAT as a standard for IPv6 - Why? Sell's more boxes and training!
- mprovost 12y ago
  Or maybe their customers are asking them for it?

captainmuon 12y ago

> Another difficult situation arises if two peers are actually on the same local network behind the same NAT router. ... > It might be tempting for peers to encode their private IP address and send it to the intermediate server and/or to the other peer. I thought about this when writing ZeroTier. On the plus side, this would work even on large segmented networks where UDP broadcasts don’t make it everywhere. But the problem is that this exposes internal configuration details about the network to potentially random external peers. Many network security administrators are not going to like that, so I decided against it. I tried to think of a way to anonymize the data but couldn’t, since the IPv4 private address space is so small that no form of hashing will adequately protect against exhaustive search. I wonder if it would be possible to encrypt the local address with the internal MAC address of the router/gateway. Then only nodes seeing the same router could decode the information. I also wonder how Dropbox does this (it can tell when two connected computers are on the same LAN, and transfers files directly).

Maakuth 12y ago
Dropbox does the UDP broadcast thing. Try dumping packet in pretty much any LAN today and you see their broadcasts flying around.
- nly 12y ago
  I see Dropbox traffic hitting my servers. People evidently rent Windows dedis, install Dropbox on them, and they spew out broadcast to the local /24
richardwhiuk 12y ago
I know that Dropbox uses multicast packets to announce itself to other nodes. I'd have thought that encrypting the local address with the public IP address of the gateway would be a better solution?
- Perseids 12y ago
  Neither the IP address nor the MAC address contain enough entropy to make that secure. Even assuming they were completely random, 32 and 48 bit keys can be bruteforced in no time. Additionally the MAC address contains mostly static or easily guessable values and the public IP address is, well, public. Thus even key strengthening along the lines of PBKDF2/bcrypt/scrypt is hopeless.

unwind 12y ago

"The terminology used is somewhat confusing… I’m not really sure what is meant by a “cone.”" I think the linked-to Wikipedia page makes it pretty clear, it's simply a reference to the conical (funnel-like) shape of the right-hand side of the illustration (http://en.wikipedia.org/wiki/Full_cone_NAT#Methods_of_port_translation http://en.wikipedia.org/wiki/Full_cone_NAT#Methods_of_port_t...). Full-cone NAT allows inbound connections from any external host, i.e. it's an unrestricted funnel (or cone).

IgorPartola 12y ago

This is why I IPv6: https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html

simmons 12y ago
I'm also anxiously awaiting the rise of IPv6, but I'm guessing that -- in a sane world -- consumer routers will still default to a stateful firewall for IPv6, thus necessitating the continued need for hole punching. :/
- richardwhiuk 12y ago
  Hole punching will be very reliable though - each end picks a port and starts talking to the other end at roughly the same time. Once they both start talking to each other, the flow will be fine.

julie1 12y ago

NAT may kill kittens, but IPv6 is killing polar bears massively. I recommend the lecture of this: https://www.nanog.org/meetings/nanog46/presentations/Sunday/RAS_Practical_ipv6_61309_N46.pdf https://www.nanog.org/meetings/nanog46/presentations/Sunday/... (deployment document of ipv6) then proceed to the glitches section. I recommend reading nanog mailing list for having a glimpse on the added complexity of dealing with IPv6 in real life. Just peak random mails, it pops up once a month. Like for instance provider turning to LS (Large Scale) NATing or Carrier Grade NATING rather than going IPv6 for rationnale reason: IPv6 engineers are hard to find and LSNAT (+dual stack eventually) since China has proven valid has both a way to handle the scarcity of IPv4 addresses and the need to control user's traffic. http://mailman.nanog.org/pipermail/nanog/2014-July/068892.html http://mailman.nanog.org/pipermail/nanog/2014-July/068892.ht... IPv6 is not bad, it is kind of bloated and requires a tinge more training than IPv4. Plus there are the concerns about privacy (but some IPV6 guru will come up with ULA or another obscure trick. It is IPv6 realm: everything is clear on the paper but is seems confusing to quite a few real life engineers since it requires a lot of RFC stacking in the brain)

api 12y ago
> and the need to control user's traffic. Some of us think that's a bad thing :) > Plus there are the concerns about privacy IPv6 has privacy extensions that allow address randomization, and its address space is so large it makes it easy to just make up addresses. Besides, tracking IPs is really only one of hundreds of ways of tracking you on the Internet.

danbruc 12y ago

In some situations Teredo [1] may get the job done. [1] http://en.wikipedia.org/wiki/Teredo_tunneling http://en.wikipedia.org/wiki/Teredo_tunneling

lectrick 12y ago

More like "Where the hell is IPV6 already?" :)