←back to thread

The New Internet

(tailscale.com)
517 points ingve | 6 comments | 26 Jul 24 18:29 UTC | HN request time: 0.27s | source | bottom
Show context
teddyh ◴[27 Jul 24 03:19 UTC] 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 #
1. ZhongXina ◴[27 Jul 24 12:39 UTC] No.41086195[source]▶
No, we definitely don't want "automatic IPSec" (especially IPSec!), or really any enforced encryption at the network level, even if it's something sane at this moment like WireGuard. Look at old VPN protocols or authentication schemes like RADIUS which have glaring security holes and are impossible to fix because of compatibility issues, and they're running at much smaller scales than the whole internet. Hell, the way the industry is solving TCP ossification problems is by throwing TCP away and reimplementing it on top of UDP, that should tell us something.
replies(2): >>41086520 #>>41092386 #
2. teddyh ◴[27 Jul 24 13:36 UTC] No.41086520[source]▶
Your argument seems to be to never implement anything, because eventually it will become old and it will be hard to move away from it? This seems to be an argument against anything new, and it is therefore hard to take seriously.
replies(3): >>41086609 #>>41090041 #>>41092334 #
3. api ◴[27 Jul 24 13:53 UTC] No.41086609[source]▶
It’s an argument against complexity. IP had amazing longevity because of its simplicity and openness.

Even if something is open, complexity is almost like closed as we can see with crazy complicated web standards for which there are few implementations.

4. zbentley ◴[27 Jul 24 23:14 UTC] No.41090041[source]▶
Not GP, but I interpreted it as an argument to innovate/proliferate implementations early and often, but to standardize minimally and as late as possible.
5. snek_case ◴[28 Jul 24 10:28 UTC] No.41092334[source]▶
The argument is more that encryption technologies can become outdated quickly. You also make it harder for small embedded devices to implement network connections if you mandate that all traffic must be encrypted.

A simple protocol is more likely to last.

6. jeroenhd ◴[28 Jul 24 10:47 UTC] No.41092386[source]▶
IPSec is still widely deployed, securely even. All manual, of course, because it doesn't do the stuff that makes HTTPS easy.

IPSec is not always a VPN protocol. L2TP over IPSec is often used as one, but IPSec does little more than encrypt a tunnel between two IP addresses. IPSec in tunnel mode can be a minimal VPN, but it's not used as such as in VPN scenarios without a second packet encapsulation protocol, as it lacks authorization beyond key exchange.

As for the risk of ossification: that didn't go away with the current system either. HTTPS over TLS 1.3 looks like a TLS 1.2 session resumption on the wire (in its default configuration) because shitty middleboxes are used often enough that it would impede the protocol.

The "let's remake TCP over UDP" approach QUIC takes has very similar origins. UDP is generally allowed by random firewalls over that network, while other (more suited) protocols for this type of stuff like SCTP are not. The operating system doesn't allow opening raw network sockets without high privileges, so adding a new QUIC protocol at the layer of TCP and UDP to implement them at the right spot in the stack wouldn't be usable for many devices. Same is true for the TCP stack you have to use what the OS provides or get higher privileges to do your own; patching the TCP state machine isn't practical. So, if you want to implement a better version of TCP optimised for web browsing and such, you use UDP, because while technically incorrect, it'll work in most cases and has the least restrictions.

In the context of the network, IPSec is the new protocol here, not the result of ossification.