Everyone Should Build Their Own Network Stack

Join the discussion

• Hacker News
• Back in the 8-bit days, we all wrote our own kernel process schedulers in order to make simple games. If you had an Apple II and wanted music, you'd need to make yours a hard real time one as well.
  by rbanffy
• This kind of project is so much fun and a great learning exercise. While I respect the tongue-in-cheek proposition, we really would benefit from a wider understanding of network protocols. Doing an exercise like this is eye opening.
  by mlhpdx
• Everyone should build their own ** is the general advise I would give just about anything. Otherwise it is hard to appreciate how much effort it goes into things that we take for granted.

  Everything looks simple from the outset until you try to build it yourself.

  by _pdp_
• if you have time, money, energy, attention to do it then yes

  but unfortunately not everyone have same opprtunities

  by tonyhart7
• At least look inside and appreciate the value of it already being together!
  by DANmode
• We do these things not because they are easy, but because we thought they would be easy.

  I also think there is an incredible transference of skills from one domain to another. This is a risk (everything looks like nail when you have hammer), but there are many domains that are very mature where you can learn a trick and apply it to a new domain over and over again.

  by Hasz
• I recently saw this guy on HN who had written a web server for an Atmel AVR and also implemented a TCP/IP stack to boot. It obviously was far from feature complete, but it did work. He used SLIP to communicate with the "server."
  by hn_submit
• Huh, I thought the thesis was going to be "... because it's a good learning experience everyone should do to understand how networking works" but the reason offered comes down to security. However, I'm going to go with what I had thought originally and actually make this an assignment for students. Anyone have experience witht that, could this be done in a semester?
  by ModernMech
• I did this for a couple years at University of Washington. We did IP, TCP, RIP, forwarding and a couple other things. they weren't compatible with the actual RFCs- they were kind of stripped down to the bare essence. I wrote the sample and the tests, and then I ripped out the guts and presented them with a shell, went over the protocol in lecture and provided a kind of spec for them to implement.

  the parts I was most proud of was (a) your score was directly related to the number of tests passing, so you know in advance what your score would be and could decide how much effort. (b) every assignment came with a relevant visualization that showed things like the routing table as a directed graph, or the TCP sequence diagram. I was available in the lab for a good 2-3 hours a day on weekdays to answer questions.

  I think some of the students got a pretty good picture of how things worked, but the overwhelming opinion was that it was just too much work. a lot of the students just copied off each other. we also had quarters, so ...

  by convolvatron
• I would seriously recommend against building your own network stack for production use. Or writing your own web server for production use. Or database (whatever SQL or NoSQL) also for production use.

  These sort of things are more complicated than you could expect and have plentiful pitfalls. Whatever you can do in reasonable amount of time is probably not that good compared to existing alternatives.

  If you have actually pressing reason to build one and are ready and have means to spend time and effort on it go ahead. But carefully consider the effort needed...

  by Ekaros
• Wanting to incorporate an http server into a C project of mine, the only battle-tested or feature-complete options either allocated dynamic memory UTH without an option to override the allocators, or are too opinionated with the core API, like mandating callbacks for everything. Suprisingly there's no decent (single header) C library that don't have these 2 issues, at least that I could find.
  by hyperbolablabla
• This is just an opinion and not a very sensible one at that. The Linux TCP/IP stack is one of the most scrutinized network stacks in the world and more than likely free of bugs that coud lead to a server takeover.
  by hn_submit
• They thought QubesOS was secure but they found a trivial sandbox escape to root today.
  by inigyou
• lols, what about the sendfile and other vulnerabilities that lasted decades. Linux just does not have a secure mentality, it has a hacker mentality, maybe acceptable for a lot of uses, but it is what it is.
  by fizlebit
• Are you aware of the syzkaller and how many bugs it still finds including in networking stack?
  by dilyevsky
• The real nightmare scenario is not just finding a vulnerability in the Linux network stack but finding vulnerabilities at the protocol level in TCP/IP itself or HTTP. That’s a problem that cannot be fixed. Has there ever been a precedent for this in computing?
  by znnajdla
• Yes, lots. Early spdy was vulnerable to CRIME attacks and so was TLS1.0 (and to bunch of other attacks). Kaminsky DNS cache poisoning is another one that comes to mind
  by dilyevsky
• When these things come up, what usually happens is implementations stop following the spec as written.

  Many issues can be handled with minimal coordination, but some things work much better with consensus and you see flag day campaigns. Ipv6 flag day had very limited impact on that day, but may restarted the process and actually got things moving. DNS flag days have been successful.

  by toast0
• Many: OS detection (ICMP, IGMP, ARP, TCP, etc.), topology disclosure (ICMP), DoS (many early protocols did not perceive resource exhaustion in their threat model; a prominent example being SYN floods / TCP half-open), etc.
  by contingencies
• Good to see that people still have this spirit of rolling their sleeves up and doing something like this for fun. Underneath it there is a very real point about mono-cultures and the increased magnitude of the impact of a risk, although more eyes checking one implementation should reduce the probability.
  by amoss
• Monoculture. It's like when all bananas used to be clones of each other and a disease wiped out the whole species.
  by andai
• Used to be? Isn’t this still the case?
  by tmountain
• A while back I wrote an FPGA-based minimal network stack to work with the MRMAC hard IP of an AMD VC1902 with basically the same functionality: ARP, IPv4, ICMP Echo reply and UDP send/receive. I added the bare bare minimum to get UDP GRO working on the receiver side (Linux).

  I also enjoyed the learning experience and works perfectly fine at up to 100G. But I definitely appreciate that I didn't have to go through the same pain under Linux where this stuff just works.

  by Hoftheater
• This article might be a bit tongue-in-cheek but it's actually something I've been thinking seriously about for a while. I can imagine a future where every country and company writes their own operating system and that might actually be a very good thing. There is a security advantage in not using popular technology stacks and rebuilding everything public-facing in-house. Because with Mythos-level AI capabilities, it is almost guaranteed that anyone with access to Mythos/Cyber can find a zero day in your stack. If your stack is proprietary and bespoke with no public access to source code it's much harder to find vulnerabilities, because they can only probe your public facing interfaces.
  by znnajdla
• They won't be compatible with each other, guaranteed. Compatibility in reality comes from everyone using the same reference implementations that have been compatibility-tested, not from everyone implementing the same specifications.
  by inigyou
• This is the same erroneous reasoning as historical claims that FOSS was less secure due to being public. That has been disproven many times over by now.

  The only way it might hold here is if no one with access to the cutting edge models bothers to run your code through one while an adversary does. That seems highly unlikely, particularly for any well funded organization.

  That said I agree that monoculture is bad. Vulnerabilities like heartbleed or spectre are so devastating precisely because they apply to approximately everyone.

  by fc417fc802
• My first job was at Westinghouse instrumenting a nuclear power plant. Our entire hardware-software package was a freebie given to the customer as part of a $200 million refueling contract (and that's in 1988 dollars). We, a team of 10, created a bespoke application stack which was effectively a web browser. The client machines were Sun 3 workstations. The server was some industrial mini computer that didn't have a TCP/IP stack - so we did in fact have to roll our own network stack.
  by intrasight
• ...what kind of credentials did you have to become a hw/sw engineer at a nuclear power plant as your first job?
  by diath
• Hah, the first engineering job I had was on Ovation DCS doing power plant controls. That system traces the lineage to the WDPF systems.

  Was the server you mention here the actual DCS? With the Motorola CPU's? Running vxworks? Pretty cool recognizing something niche that is still, vaguely familiar. :)

  by RealityVoid