We are already working on plans for DNS. BGP has been in the back of our minds for a while but we haven’t had the bandwidth to start seriously looking into that yet. If you have ideas get in touch!
I get why BGP sounds like a good target, since it's self-contained and high-importance, but I'd assume the most important BGP4 deployments on the Internet aren't in systems that can replace their BGP4 servers with anything that Cisco isn't itself shipping. Lots of people run little `birds` to advise their upstreams, but they're not running full-feed defaultless; they're minimally exposed. I think the win from a community-driven BGP4 project might be small compared to the investment. But you've been thinking about this already, so I'd love to hear about how wrong I am. :)
What you are describing matches my impression of things. It has been on the back burner because even if we had a great memory safe version of, say, openbgpd, I am not sure that would have particularly widespread impact. You are probably right that we would need to convince Cisco and friends to move to memory safe code.
we would need to convince Cisco and friends to move to memory safe code.
For BGP and DNS, probably. But a few big buyers pushing on that might get it.
An all-Rust home router with WiFi, cable, fiber. and DSL would be useful. The trouble is, if it's written by open source people, it will have zillions of versions and be configured by editing a text file.
A bigger problem would probably be that consumer routers are built as quickly and as cheaply as possible. Every megabyte of additional storage costs cents on the dollar extra and even that gets shaved off if possible. All the router security research I've seen done by well-intending academics got turned away by manufacturers because they don't want to ship additional software in their already-constrained images.
Rust, on the other hand, has all the downsides of static compilation combined with the library bloat we see in nodejs.
For a home router to run Rust, you'd probably need to compile the entire router into a single firmware image doing everything or you'd need to build an extensive dynamic linking system on top of the existing Rust infrastructure. Or, alternatively, convince the router manufacturers to spend another dollar or two on their EEPROM, but good luck getting them to do that.
Finally, the core parts of the system (the drivers running the DSL/cable/fiber/wifi hardware) are all closed source blobs that the manufacturers (be it Broadcom, Intel, Cisco, or Qualcom) need you to load and execute, usually written in a language like C with none of the benefits of Rust. Unless you want to rewrite the drivers in Rust (and good luck to you reverse engineering all of those and fighting the cease and desist letters you receive), the core parts of the system are still vulnerable as all hell.
The configuration can be made reasonably simple; OpenWRT has a GUI that can easily be dumbed down enough so normal folk can use it. Even in consumer routers, a lot of configuration is still dumped to text files already, anyway.
Rust can work with dynamically linked code. It's just limited to the C ABI in most cases because Rust itself doesn't have an ABI that's stable across compiler versions.
Many Chinese companies are building their own authoritative NS based on code from miekg/dns :)
Writing one importing that library is really simple, we should do it more often in the West too.
Right, I just ported our Rust DNS server (built with the equally excellent NLNet crate) to miekg/dns. It's great. But people tend to be writing "interesting" DNS servers, which is not the thing you actually need if you're trying to get rid of BIND and nsd; you need stuff that behaves exactly like BIND and nsd, just minus the memory corruption.
Big Internet BGP servers also aren't super exposed due to the common use of TCP MD5 (RFC 2385) or TCP AO (RFC 5925). The userspace daemon won't even see packets from attackers who don't have the shared secret for that peer link.
We are already working on plans for DNS. BGP has been in the back of our minds for a while but we haven’t had the bandwidth to start seriously looking into that yet. If you have ideas get in touch!