Very comforting to know that most of the core underpinning of the internet doesn't follow the robustness principle by default.
Still, I guess it keeps support contracts active and network engineers in a perpetual hell of on call alerts
Still, I guess it keeps support contracts active and network engineers in a perpetual hell of on call alerts
The robustness principle is also long considered to be not that great of an idea for protocols. There's a good document here going into this:
> With that being said, I would like to thank the OpenBSD security team, who very rapidly acknowledged my report, and prepared a patch. My only regret with dealing with the OpenBSD team was reporting the issue to them too quickly, as they are uninterested in waiting for any kind of coordination in disclosure.
Lesson to network engineers: switch your routers to OpenBSD/OpenBGPd and keep up on your syspatches to escape this particular hell. ;)
This BS with disclosure coordination and all the other crap vendors have been trying to train researchers to do for years needs to stop. You find a issue, you publish it, vendors need to deal with bad code and products in realtime, not when it suits them.
There is IMHO no ethical alternative to responsible disclosure, and using actual people who can get harmed by having their information disclosed as pawns isn't the way to go forward.
One of the main reasons for coordinated disclosure is that, over time, it has become evident that vendors will not do that. We can say it until we're blue in the face, but vendor behavior will remain largely unchanged regardless (there are a few bright spots, but not nearly enough).
So you go to war with the army you have. In this case, that means frequently deferring/coordinating security event communications. As much as I wish the market would appropriately penalize vendors that encourage researchers to sit on 0-days, that rarely happens, and the cost of insecurity is passed onto consumers instead.
Tl;dr delaying disclosure does suck, but you should still do it.
'Tis the world we live in, so might as well get used to it.
You could technically replace all the control and decision-making with whatever off-the-shelf computer platform you want, and have it drive the carrier-grade router and "manually" populate its routing table via some API/Telnet/SNMP. In fact, as long as the hardware packet-routing core is still good, this might be a good way to upgrade out-of-support equipment that is no longer getting updates to its control-plane computer.
It was only broken in the sense that it requires you to get out a keyboard and manually continue to a root prompt and type `fsck` (and then Y a bunch of times) and presumably some files may have been corrupted but i haven’t seen any.
For a router I’d much prefer that it comes up on its own after I lose power, but the system isn’t totally broken or anything. It’s happened probably 3 times in the last year or so.
To another commenter saying it’s crazy to not run a UPS with your router: this is residential. 99% of people don’t have a UPS for their router. They probably don’t even have a separate router and all and just use an all in one modem/router/wifi combo. None of these people are crazy, they’re just not made of money and a UPS is expensive. IMO it’s more crazy to not have a journaled file system in this day and age, no other systems have issues with sudden power loss at my house.
I wonder if the outage happened during patching or something maybe?
Say, compare RFC3174 (sha1) and e.g. rfc4664 (l2vpn) the first is almost a copy-paste implementation, with tests and all. the second reads like a "write a presentation, ten pages minimum"
or look at the base bgp4 rfc - that overspecified imaginary state machine is a good illustration of how bad things are there.