5 ms·
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 o
by mhandley 12y ago
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.
- zAy0LfpBZLC8mAC 12y ago> 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.
- mhandley 12y agoIt'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://www0.cs.ucl.ac.uk/staff/M.Handley/papers/dos-arch.pdf http://nutss.gforge.cis.cornell.edu/ http://nutss.gforge.cis.cornell.edu/
- zAy0LfpBZLC8mAC 12y agoSplitting 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?
- mhandley 12y agoWe 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.
- zAy0LfpBZLC8mAC 12y agoExcept 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.
- deleted 12y ago[deleted]
- HackinOut 12y agoWell 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.
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]