Comment by mhandley | Hacker News Reader

Comment by mhandley | Hacker News Reader

The Internet got a lot of things right - in particular, it is an excellent design for evolution. None of the original hardware is still around, it's grown by orders of magnitude in both size and speed, and almost all the most popular applications today hadn't been thought of in the 1980s.

Having said that, there are definite deficiencies. It's fragile in many ways: it shouldn't be possible to launch flooding DoS attacks; encryption should be baked in to all the transport protocols; the ability to connect to a computer should be much more under the control of the recipient (today's firewalls are a poor workaround for a design deficiency). The routing system is pretty fragile.

The ability to handle multiple networks simultaneously, and gracefully move between (or use more than one simultaneously) isn't something that was originally necessary, but is today with mobile devices. We're working on fixing that with MPTCP, but it will take a long time to univerally deploy.

So, lots of architectural issues, but it's important not to lose sight of what is good about the current network too.

> the ability to connect to a computer should be much more under the control of the recipient (today's firewalls are a poor workaround for a design deficiency).

Erm ... no, it is absolutely intentional that the core of the network doesn't keep any flow state, because that doesn't scale.

It's not fundamental to keep per-flow state to have more control over reachability. Once you step back from the current Internet architecture, there are a whole host of possibilities. Here's are a couple of (rather old) papers for example:

http://www0.cs.ucl.ac.uk/staff/M.Handley/papers/dos-arch.pdf

http://nutss.gforge.cis.cornell.edu/

Splitting the address space into "client" and "server" addresses, supposedly for some security benefit? Come on, you can't be serious about that?!

I have only skimmed the paper, but it seems to me to be a collection of bad ideas, and I can't really be bothered to read all 8 pages. If you think there is actually something useful in there, would you mind condensing that into one paragraph?

We already have "client" and "server" addresses, courtesy of NATs. NATs are a huge pain from an architectural point of view, but all the same, many people like them because they provide some measure of security as a side effect. That paper was all about trying to capture this within the architecture, and providing the same effect in depth, rather than just at the NAT itself. It was a thought experiment more than a serious proposal, but that's the way new ideas come about - someone proposes a radical-but-flawed idea, and others see some merit in the principle, but find ways to avoid the flaws. I wasn't trying to push this solution on you - just responding to the over-general per-flow state point.

Except that the stateful packet filter that sometimes comes with a NAT gateway (and that provides the security that people like) depends exactly not at all on NAT and the pain that comes with that kind of address class distinction.

Well I don't have stats but from personal experience (perhaps I have a bit more experience with french rather than US providers), home routers do not use a specific stateful firewall, and use masquerading NAT. So it would depend on the way NAT is done.

Reply on news.ycombinator.com