5 ms·

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

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

greyface- 3y ago
> I worry about the state of networking vendors. > 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. ;)
- literalAardvark 3y ago
  That just sounds like creating a new level of hell
  - martijnvds 3y ago
    One full of daemons.
- appplication 3y ago
  I could have sworn I saw someone on here a few weeks ago saying how they switched their router to openBSD and ended up in some horrible broken state after a power outage or something. I can’t recall the details, maybe someone else would recall.
  - basedrum 3y ago
    Maybe because you need to go to the data center to reboot open bsd
  - binkHN 3y ago
    Who here is running a production system without redundant or backup power?
    - appplication 3y ago
      I should have clarified: I think they said they did it on their home router.
  - Shared404 3y ago
    Huh, I've been running an openbsd router as my prod home network router for ~ a year now without issue, and it has handled power outages and more without issues. I wonder if the outage happened during patching or something maybe?
  - ninkendo 3y ago
    It was probably me: https://news.ycombinator.com/item?id=36837184 https://news.ycombinator.com/item?id=36837184 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.
    - appplication 3y ago
      Yep! That’s the post I was thinking of. Thanks for hopping in with context!
- Hikikomori 3y ago
  Any 100+ Terabit Openbsd routers out there?
  - Nextgrid 3y ago
    I would very much doubt any of those carrier-grade routers run BGP in hardware. Chances are the control plane is handled by a bog-standard Linux/VxWorks/BSD that does all the logic of talking BGP/etc and then populates the right registers in the switching/routing hardware which handles the actual data plane. 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.
- ExoticPearTree 3y ago
  > 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. 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.
  - mschuster91 3y ago
    While I agree in theory, in practice this will lead to bad actors ranging from trolls to cyberwar troops exploiting it immediately. 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.
    - ExoticPearTree 3y ago
      Yes, but have that pain inflicted on end customers long enough and they will eventually transfer it to the vendors one way or another.
  - zbentley 3y ago
    > vendors need to deal with bad code and products in realtime 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.
    - salawat 3y ago
      Alas, it is the consumer that apparently drives pain reception for vendors, as they have no interest in minimizing consumer pain, but their own pain. Their own pain is defined as lost business. 'Tis the world we live in, so might as well get used to it.
- karavelov 3y ago
  why not switch to bird that was not affected at all? not just acknowledged and fixed. isn’t it “safe be default” better than “fixed after they pointed the flaw”
treve 3y ago
The robustness principle: "be conservative in what you do, be liberal in what you accept from others", hardly applies here. Whether or not it was followed, a crash shouldn't happen. 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: https://datatracker.ietf.org/doc/html/rfc9413 https://datatracker.ietf.org/doc/html/rfc9413
- vermilingua 3y ago
  It isn’t a crash, BGP terminates the session and retries because it considers the connection to be malformed. So, “be liberal in what you accept” certainly does apply.
  - j16sdiz 3y ago
    This "terminate and retry" behaviour is specified in RFC7606
    - fanf2 3y ago
      That is the exact opposite of what RFC 7606 says. As it explains in its introduction, it deprecates session reset in favour of treat-as-withdraw in most cases, unless there is an explicit exception to the general rule.
- forkerenok 3y ago
  That RFC is a very insightful read. Thanks for sharing!
hn8305823 3y ago
The software on big routers that run the Internet is far more reliable than it was 20 years ago. It's not perfect and each vendor has cycles of good and bad code releases but it's so much better than it used to be.
112233 3y ago
This is not helped by the RFCs that specify the behaviour of these core protocols. It is rare to find a network protocol rfc that is clear, specific and not self contradictory (IPSec rfcs come to mind as a positive example). 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.

greyface- 3y ago

> I worry about the state of networking vendors. > 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. ;)

literalAardvark 3y ago
That just sounds like creating a new level of hell
- martijnvds 3y ago
  One full of daemons.
appplication 3y ago
I could have sworn I saw someone on here a few weeks ago saying how they switched their router to openBSD and ended up in some horrible broken state after a power outage or something. I can’t recall the details, maybe someone else would recall.
- basedrum 3y ago
  Maybe because you need to go to the data center to reboot open bsd
- binkHN 3y ago
  Who here is running a production system without redundant or backup power?
  - appplication 3y ago
    I should have clarified: I think they said they did it on their home router.
- Shared404 3y ago
  Huh, I've been running an openbsd router as my prod home network router for ~ a year now without issue, and it has handled power outages and more without issues. I wonder if the outage happened during patching or something maybe?
- ninkendo 3y ago
  It was probably me: https://news.ycombinator.com/item?id=36837184 https://news.ycombinator.com/item?id=36837184 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.
  - appplication 3y ago
    Yep! That’s the post I was thinking of. Thanks for hopping in with context!
Hikikomori 3y ago
Any 100+ Terabit Openbsd routers out there?
- Nextgrid 3y ago
  I would very much doubt any of those carrier-grade routers run BGP in hardware. Chances are the control plane is handled by a bog-standard Linux/VxWorks/BSD that does all the logic of talking BGP/etc and then populates the right registers in the switching/routing hardware which handles the actual data plane. 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.
ExoticPearTree 3y ago
> 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. 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.
- mschuster91 3y ago
  While I agree in theory, in practice this will lead to bad actors ranging from trolls to cyberwar troops exploiting it immediately. 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.
  - ExoticPearTree 3y ago
    Yes, but have that pain inflicted on end customers long enough and they will eventually transfer it to the vendors one way or another.
- zbentley 3y ago
  > vendors need to deal with bad code and products in realtime 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.
  - salawat 3y ago
    Alas, it is the consumer that apparently drives pain reception for vendors, as they have no interest in minimizing consumer pain, but their own pain. Their own pain is defined as lost business. 'Tis the world we live in, so might as well get used to it.
karavelov 3y ago
why not switch to bird that was not affected at all? not just acknowledged and fixed. isn’t it “safe be default” better than “fixed after they pointed the flaw”

treve 3y ago

The robustness principle: "be conservative in what you do, be liberal in what you accept from others", hardly applies here. Whether or not it was followed, a crash shouldn't happen. 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: https://datatracker.ietf.org/doc/html/rfc9413 https://datatracker.ietf.org/doc/html/rfc9413

vermilingua 3y ago
It isn’t a crash, BGP terminates the session and retries because it considers the connection to be malformed. So, “be liberal in what you accept” certainly does apply.
- j16sdiz 3y ago
  This "terminate and retry" behaviour is specified in RFC7606
  - fanf2 3y ago
    That is the exact opposite of what RFC 7606 says. As it explains in its introduction, it deprecates session reset in favour of treat-as-withdraw in most cases, unless there is an explicit exception to the general rule.
forkerenok 3y ago
That RFC is a very insightful read. Thanks for sharing!

hn8305823 3y ago

The software on big routers that run the Internet is far more reliable than it was 20 years ago. It's not perfect and each vendor has cycles of good and bad code releases but it's so much better than it used to be.

112233 3y ago

This is not helped by the RFCs that specify the behaviour of these core protocols. It is rare to find a network protocol rfc that is clear, specific and not self contradictory (IPSec rfcs come to mind as a positive example). 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.