Ask HN: If we could redesign the Internet from scratch, what should it be?
I ask the question purely out of interest, not specifically about tweeking HTTP and TCP/IP but also about the underlying hardware, much of which is decades old. If we could completely divorce the Internet from history, what would be the best design. Would it take much more inspiration from OSI, or look radically different? Perhaps the question doesn't make sense: if we radically changed the Internet it would no longer be the Internet, much as the Internet is not simply an improved version of the phone network.
87 comments
[ 22.5 ms ] story [ 1483 ms ] thread* More security baked in by default.
* Quicker implementation and standardization of features the market demands -- so Java, Flash and ActiveX could be avoided.
* Lesser reliance on central nodes (nameservers, etc), with a larger emphasis on a network of peers, which dynamically grows with actual need.
* Oh and somehow fix domain system. I don't think there's any value that domain squatters provide to the network that don't have simpler alternatives.
https://gnunet.org/gns-implementation
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.
Erm ... no, it is absolutely intentional that the core of the network doesn't keep any flow state, because that doesn't scale.
http://www0.cs.ucl.ac.uk/staff/M.Handley/papers/dos-arch.pdf
http://nutss.gforge.cis.cornell.edu/
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?
I realise these are actually SSL criticisms but oh well.
The SPDY spec and the HTTP2 draft have a lot of good ideas too regarding the implementation of the communications.
* The ability to be anonymous baked into the hardware infrastructure [3]. In the Internet's life, people have been more "anonymous" than not. Even in the Facebook age, many still communicate under pseudonyms on the Internet (thinking they are anonymous - but unfortunately the surveillance state and all the ad-tracking has made that wishful thinking)
* Being a lot more censorship-resistant/decentralized. If the Internet was being redesigned, stuff like the Great Firewall of China shouldn't be made possible. The Internet has been such a democratizing force because people have been (for the most part) out of reach of the governments' might. I can only see a strengthening of that feature as a great thing. Yes, bad things will be done, too, but in balance, I think the free Internet has been proven to be an overwhelmingly net positive thing.
* As others have said, much better support from the Internet stakeholders of modern secure standards. There has just been so much reluctance to change things for the better from major Internet stakeholders. That's why I'm a huge fan of Google's recent pushes for SHA2, HTTPS, etc (some would say "forceful" pushes, but I think that's unavoidable if we want them done within a few short years, instead of decades. Considering how large the Internet is today, they are bound to step on a few toes anyway).
1] - https://www.youtube.com/watch?v=pNkz5PtoUrw
[2] - http://cr.yp.to/tcpip/minimalt-20131031.pdf
[3] - https://code.google.com/p/phantom/
With the influx of low power devices, implementing distributed versions of many of today's centralized services could be much more fun.
It’s probably helped at least as much as it’s hindered
I believe that's what GP was referring to.
(Disclaimer: can't remember which variant of cone/full this is categorized as -- I thought there was a really useful "Current state of NAT in practice" blog post that was linked a few months ago)
Now, it so happens that dynamic NAT also needs to do connection tracking in order to be able to map addresses back and forth, just like a stateful firewall does, and that therefore, it's easy to also implement stateful packet filtering on top of the same connection tracking state - however, there is no need to do NAT in order to do the connection tracking and the filtering based on that, you could have the exact same stateful packet filtering with the exact same security properties, just without messing with the address fields of the packets and all the bad things that result from that.
True, but NAT doesn't work without statefully filtering/routing packets, and unlike generic packet filters, the use of NAT is basically a requirement for most people connecting devices to the internet.
The question is: if IPV6 was around 30 years ago and no one ever needed to use NAT to stick a whole address space behind a single address, how would things be different today? How long would it have taken for packet filters to become a default feature on home routers, and what would their default settings be?
How common are stateful packet filters on home routers today? I don't really know - thanks to NAT, you can get away without for most attack scenarios nowadays, so I wouldn't be surprised if vendors don't really bother with it. But given that connection tracking doesn't seem to be that difficult with home router hardware, I would have expected stateful packet filters in home routers as a default feature early on, with everything inbound blocked by default (and then some UPnP like protocol for opening ports as needed, just without the stupid address collisions you get with NAT).
Knowing what we know now, would those designs be different? Undoubtably, yes. Would they likely be better? Likewise, yes.
Anyone who's worked with protocols knows just how bad the initial design usually is.
http://en.wikipedia.org/wiki/Internet_Engineering_Task_Force
http://en.wikipedia.org/wiki/Internet_Technical_Committee
And I am sure DARPA and whomever worked on the original networking protocols would horify you by their style of design by comittee...
http://csr.bu.edu/rina/about.html http://irati.eu/nextworks/
The theory has been around for ages but it's starting to gain traction with a prototype stack released recently.
http://irati.github.io/stack/
Also, making the network content-aware to a greater degree gives me nightmares of bloated XML / WS-I style schemas making their way into core specs.
That said, your points are a definite need with the size of the modern network (and the order of magnitude difference in traffic spikes). Imho, it'd be great to have a more formalized caching system, whereby the server could tag content as recommended-cache (core page content) or not (comment threads) & invalidate asynchronously if it became necessary.
I'd be interested to see what we could do with SSDs / future technology with feasible latencies to assemble such a system.
Hypothetically, there's no reason it couldn't be incentivized via a peering-style agreement: e.g. I cached and served X amount of traffic that you didn't have to, therefore you'll pay me Y% of the cost of you serving that traffic yourself (where Y < 100% & it still makes sense for both parties).
TLS: CAs. TLS/SSL is largely "security on the internet", and any of thousands of CAs could sign a cert for any of our websites. Very few exceptions apply here - to protect against this, you effectively need to be on the client (see certificate pinning on chrome). We need something like TACK[1] here. The current state of the TLS CA system is very convenient for malicious actors of any size.
Routing: BGP is an overly trusting protocol[2]. Any of thousands of ASN can advertise a route and its peers will happily chug that traffic along to it. This would allow, for instance, a Pakistani ISP "taking over" YouTube, or more recently, Indosat trying to take over the Internet[3].
There's many things that would be "nice-to-have" fixes, but these two are pretty urgent in my opinion. They were designed for a much friendlier Internet.
[1] https://tack.io/
[2] http://security.stackexchange.com/questions/56069/what-secur...
[3] http://www.bgpmon.net/hijack-event-today-by-indosat/
I don't think BGP needs to be fixed at all, the underlying problem is inherent to the Internet, changing the protocol will only close one of the several different ways for stealing data.
About TLS, yes, we need something better. Your link currently does not work, but I've never seen a proposal that's actualy better than TLS + DANE.
TLS can indeed offset its CA burdens onto DANE, when DANE becomes a thing[2] and DNSSEC becomes ubiquitous[3]. We are so far away from that, that even google hasn't bothered with DNSSEC[4]. Considering the enormous infrastructure changes that this requires, we'll hardly be getting our money's worth - still a strict top-down system: IANA/Verisign have the root-root zone/keys. Verisign "owns" .coms (root zone), as well as most (all?) other gTLDs.
TACK is a proposed TLS extension for certificate pinning for the masses. It doesn't solve DNSSEC problems (not its scope), but requires far fewer infrastructure updates to be implemented. It is also not perfect[5] but still a much closer/realistic goal than DANE. We need something yesterday - the green lock icon means fuck-all right now.
And finally:
> I don't think BGP needs to be fixed at all, the underlying problem is inherent to the Internet, changing the protocol will only close one of the several different ways for stealing data.
Strongly disagree. If it does close off one of the ways of stealing data, it definitely needs fixing.
[1] never -> until Humans intervene to manually block the BS route[2] DANE Browser support matrix: [ [] ] (2d array, versions on the X axis)
[3] For this to really work for the end client, you need nearly ubiquitous support. The client must be its own recursive nameserver (don't trust your ISP), and all recursive nameservers until the authoritative one need to speak DNSSEC as well (I think). Of course, the g/cc TLD also needs to support DNSSEC (not all do), the owners of the site must have set it up properly, etc. After all that is ubiquitous enough to you enforce DANE for proper TLS ("green icon"), you just need to update all clients everywhere with the new rules. We're currently at step 0.1 of this process - the root zones for most g/cc TLDs are there, and that's about it.
[4a] http://dnsviz.net/d/google.com/dnssec/
[4b] http://dnsviz.net/d/whitehouse.gov/dnssec/ (for comparison)
[4c] http://www.dnssec-name-and-shame.com/ (NOISY site - be warned) Test out a few top alexa sites. You'll be surprised.
[5] It can only protect your second (and subsequent) visits to the site. If your first time hits a malicious impersonator, you're shit out of luck. Furthermore, the impersonator could "tack" its own malicious certificate for some lols when you actually get to talk to the actual target.com.
Homoiconic; code would be part of the internet. Views on datasets would themselves be stored in a persistent database. Clients would simply subscribe to the code feed and can update automatically, while still being able choose to run old clients, apps er even just particular versions of functions.
Conversational; interactions between services consist of exchanges of immutable data between services (just like conversations.) I publish some code; you publish your interactions with that code. I publish a question; you publish an answer to that question. This has the added benefit of being able to map it onto existing encrypted communication protocols like OTR.
When I have to do front-end web dev, I feel like coming out my high end sedan and riding a skateboard : skateboarding is certainly a lot of fun for the cool kids, but I'd rather sit comfortably in my sedan.
OK ... now I guess I just have to ask you to get off my lawn :-)
I'm sure if I put my heart to it I would come to love JS (you know like in Stockholm syndrome ;-)
It would basically delete all the throw away accounts that we have to do nowadays and the security risk with repeating passwords. It might even get rid of email as we know it since you could do communication user to user.
Development nowadays
- Mozilla's Persona: https://login.persona.org/ getting adopted slowly.
- Facebook/twitter/linkedin/etc login apis. Not ideal since you are tied to the place.
Pros: emails and communication, p2p, payments, development time (no difficult login).
Cons: stolen id = stolen life, privacy
Security. HTTP and other similar protocols without encryption by default are not appropriate for today's Internet. Similarly, we wouldn't have to use opportunistic encryption of email.
Better support for protocols other than TCP and UDP. SCTP is a great protocol that fits many application level protocols so well. Instead corporate IT very often sets up the firewall to simply drop anything but the two most popular protocols.
Sadly, we still wouldn't have a more widespread web of trust. Once you buy into WoT, it can be an invaluable tool, but the problem is largely orthogonal to the development of the Internet: publicist crypto is just too difficult to make easy and robust. I only list this here because I believe a more widespread WoT would mean the end of CA's, government snooping, and many other evils.
Multiplayer gamers everywhere just did a giant Hoo-ah to that. I think the network admins are already drunk.
Now I do agree that my point was kind of moot because it's indeed easy to firewall without NAT. I am all for IPv6 if it's done well. I especially like the idea of finally moving away from ARP Spoofing attacks thanks to Neighbor Discovery (ND).
I know it's now in the spirit of your question - but everyone else seems to have answered those well (DNS, https, routing at AN)
- changing the IP address or having other temporary interruptions (e.g. train in tunnel) should not force me to re-open all my SSH sessions
I have no idea what that means from a technical POV though.
I used it alot when I ran an irc client (I use IRCCloud now).
http://stackoverflow.com/a/2216721