←back to thread

The New Internet

(tailscale.com)
517 points ingve | 6 comments | | HN request time: 0.001s | source | bottom
Show context
teddyh ◴[] No.41084227[source]
The eternal problem with companies like Tailscale (and Cloudflare, Google, etc. etc.) is that, by solving a problem with the modern internet which the internet should have been designed to solve by itself, like simple end-to-end secure connectivity, Tailscale becomes incentivized to keep the problem. What the internet would need is something like IPv6 with automatic encryption via IPsec, with PKI provided by DNSSEC. But Tailscale has every incentive to prevent such things to be widely and compatibly implemented, because it would destroy their business. Their whole business depends on the problem persisting.

(Repost of <https://news.ycombinator.com/item?id=38570370>)

replies(14): >>41084990 #>>41084996 #>>41085022 #>>41085061 #>>41085166 #>>41085236 #>>41085716 #>>41085987 #>>41086195 #>>41086648 #>>41087141 #>>41087359 #>>41089848 #>>41092877 #
hnarn ◴[] No.41085716[source]
This sounds like a reasonable point, but the more I think about it, the more it sounds like digital flagellation.

IPv6 was released in 1998. It had been 21 (!) years since the release of IPv6 and still what you're describing had not been implemented when Tailscale was released in 2019. Who was stopping anyone from doing it then, and who is stopping anyone from doing it now?

It's easy to paint companies as bad actors, especially since they often are, but Google, Cloudflare and Tailscale all became what they are for a reason: they solved a real problem, so people gave them money, or whatever is money-equivalent, like personal data.

If your argument is inverted, it's a kind of inverse accelerationism (decelerationism?) whereby only in making the Internet worse for everyone, the really good solutions can see the light. I don't buy it.

Tailscale is not the reason we're not seeing what you're describing, the immense work involved in creating it is why, and it's only when that immense amount of work becomes slightly less immense that any solution at all emerges. Tailscale for example would probably not exist if they had to invent Wireguard, and the fact that Tailscale now exists has led to Headscale existing, creating yet another springboard in a line of springboards to create "something" like what you describe -- for those willing to put in the time.

replies(4): >>41085824 #>>41085838 #>>41086171 #>>41090058 #
throw0101d ◴[] No.41085838[source]
> Who was stopping anyone from doing it then, and who is stopping anyone from doing it now?

The folks who either (a) got in early on the IPv4 address land rush (especially the Western developed countries), or (b) with buckets of money who buy addresses.

If you're India, there probably weren't enough IPv4 address in the first place to handle your population, so you're doing IPv6:

* https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...

Or even if you're in the West, if you're poor (a community Native American ISP):

> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.

* https://community.roku.com/t5/Features-settings-updates/It-s...

* Discussion: https://news.ycombinator.com/item?id=35047624

IPv4 'wasn't a problem' because the megacorps who generally run things where I'm guessing you're from (the West) were able to solve it in other means… until they can't. T-Mobile US has 120M and a few years ago it turns out that money couldn't solve IPv4-only anymore so they went to IPv6:

* https://www.youtube.com/watch?v=QGbxCKAqNUE

IPv6 is not taking off because IPv4 (and NAT/STUN/TURN) is 'better', but rather because (a) inertial, and (b) it 'works' (with enough kludges thrown at it).

replies(1): >>41086487 #
api ◴[] No.41086487[source]
There is another reason: the addresses are long and impossible to remember and hard to type.

I always bring this up and it’s always dismissed because tech people continue to dismiss usability concerns.

Even “small” usability differences can have a huge effect on adoption.

replies(6): >>41086535 #>>41086588 #>>41089497 #>>41091332 #>>41091723 #>>41092279 #
Gormo ◴[] No.41089497[source]
Also, NAT is desirable for security/network isolation reasons, and having no distinction between a local IP and a public IP has a lot of disadvantages.

Yes, there are ways to configure IPv6 to isolate subnets, separate local traffic from internet traffic, set up firewalls and DMZs, run local DNS, etc., but they're all more complicated to configure and administer than their IPv4 equivalents.

replies(4): >>41089808 #>>41089818 #>>41090012 #>>41090543 #
1. throw0101d ◴[] No.41089808[source]
> Also, NAT is desirable for security/network isolation reasons […]

This is security theatre. People have been saying that NAT is not a security feature for over a decade:

* https://blog.ipspace.net/2011/12/is-nat-security-feature/

but the message still has not sunk in. The "Zero Trust" paper was published by John Kindervag in 2010:

* https://media.paloaltonetworks.com/documents/Forrester-No-Mo...

Most modern attacks start from a compromised internal host (e.g., from phishing), or through stolen credentials via a remote access method. The above is "castle-and-moat" thinking that tends to have weaker internal controls because it is thought the internal network is "hidden" from the dangerous outside network.

Set your firewall to default deny, then add a rule for allow outgoing connections, followed by only allow incoming connections if they are replies. For most machines (and networks), most of the time, this is what's needed: the above is applicable for both IPv6 and IPv4 (with or without NAT).

The protection comes from filtering (generally) and stateful packet inspection, not from hiding addresses.

> […] and having no distinction between a local IP and a public IP has a lot of disadvantages.

Just because something has a global addresses does not mean global reachability (see default deny above). Further you can layout your IPv6 address plan so that you can tell at a glance if hosts are externally accessible. Using a /48 a basis, you break out sixteen /52s, numbered $PREFIX:[0-f]000::/52.

To make it easier to remember what is externally accessible, you put all of those hosts in $PREFIX:e000::/52, where e stands for external. That /52 can then be broken down into:

* sixteen /56s

* 256 /60s

* 4096 /64s

or any combination thereof. See Figure A-5 for various ways to slice and dice:

* https://www.oreilly.com/library/view/ipv6-address-planning/9...

Everything in $PREFIX:[0-d,f]000::/52 is not externally reachable.

replies(1): >>41090886 #
2. aboardRat4 ◴[] No.41090886[source]
>https://blog.ipspace.net/2011/12/is-nat-security-feature/ >>Basic NAT (as defined in RFC 2663) performs just the IP address translation (one inside host to one IP address in the NAT pool). The moment the inside host starts a session through the NAT, it becomes fully exposed to the outside world.

This is a lie. A "session through the NAT" does not really expose the host to the outside world, because in 99% of the cases this is a TCP session, and the NAT machine would drop all "out of order" packets.

>Most modern attacks start from a compromised internal host (e.g., from phishing), or through stolen credentials via a remote access method.

Your statement is a perfect example of https://en.wikipedia.org/wiki/Survivorship_bias.

Most modern attacks start from an internal host exactly because NAT makes external attacks infeasible for the majority of scenarios.

>Set your firewall to default deny, then add a rule for allow outgoing connections, followed by only allow incoming connections if they are replies.

What about I don't do it, and the system is still _automatically_ secure, because NAT does exactly that while being _required_ for the system to work.

>See Figure A-5

LOL. What about I don't see any figures, and the system still works and is secure for the 99% of the cases.

replies(2): >>41091930 #>>41092500 #
3. alfons_foobar ◴[] No.41091930[source]
> This is a lie. A "session through the NAT" does not really expose the host to the outside world, because in 99% of the cases this is a TCP session, and the NAT machine would drop all "out of order" packets.

No, it's not. NAT only translates addresses and does not inspect the TCP "internals" (like sequence number etc, which would allow it to block certain packets).

What you are describing is a stateful firewall that allows "reply packets" for an established TCP-session.

replies(1): >>41099541 #
4. throw0101d ◴[] No.41092500[source]
> Most modern attacks start from an internal host exactly because NAT makes external attacks infeasible for the majority of scenarios.

Or, you know, because firewalls block stuff.

I've had hosts with public IPv4 addresses attacked on (e.g.) tcp/80 and tcp/443 because that's what the firewall allowed through so the web service was available to the public. I've had hosts with internal IPv4 addresses attacked on web ports because they were behind a (reverse proxy) load balancer for serving traffic: the fact that they had a 10/8 and were behind a NAT did not protect them from attack.

Before recently switching ISPs, my last one had IPv6 (new one does not). They activated IPv6 at some point, and I enabled it on my Asus, and suddenly all my internal devices got an IPv6 address (via RA), including things like my printer.

I had SSH enabled on my macOS laptop and desktop, but could not SSH into them from an outside source. My printer has a web interface on port 80 that I could connect to internally, but not externally. Even though all the devices had IPv6 addresses.

Just because a device is globally addressable does not mean it is globally reachable.

> What about I don't do it, and the system is still _automatically_ secure, because NAT does exactly that while being _required_ for the system to work.

Because NAT is doing that I describe, so you are doing it. The firewall is checking state on incoming packets and rejecting those that are not in its state table. The firewall is also coïncidentally just happening to also be fiddling some bits in the address field.

It is the stateful inspection that is protecting you.

* https://en.wikipedia.org/wiki/Stateful_firewall

replies(1): >>41095709 #
5. mrkstu ◴[] No.41095709{3}[source]
You have a mix of accurate mix with not so much here.

> I've had hosts with internal IPv4 addresses attacked on web ports because they were behind a (reverse proxy) load balancer for serving traffic: the fact that they had a 10/8 and were behind a NAT did not protect them from attack.

You explicitly set up a NAT bypass (reverse proxy) and then claim NAT didn't protect them. If I am an external attacker coming in towards a single public IP where the backside hasn't set up UPNP/Port Forwarding/STUN/Reverse Proxy, NAT does exactly what the previous poster said. It drops packets because the 'destination' is the router itself in the packet. It has no where else to go, it has literally reached its destination.

A stateful firewall is in no way necessary for this functionality to exist. Even UDP stateless packets cannot bypass the NAT because there if there is no table tracking the conversation from the POV of the inside->out initiating the conversation because the router would have zero idea which interior host to forward the packet to and no reason to do so.

6. aboardRat4 ◴[] No.41099541{3}[source]
>No, it's not. NAT only translates addresses and does not inspect the TCP "internals" (like sequence number etc, which would allow it to block certain packets).

Yes it is. How would it forward response packets back if it doesn't track connections?

In real life I haven't seen "stateless NAT" for about 20 years.

But cgnat machines usually go beyond that and even verify sequence numbers.