David Walker <davidianwalker@gmail.com> writes:
[ patent fight recap ]
Thanks for posting those. I recall the discussions surrounding the HSRP patents well, but it's been a while and I have proportionally more gray hair (and less overall) now. My problem is not with Theo nor with the IETF. My problem is with a crappy and credulous implementation. When an outage is caused by redundancy software that comes from an organization that prides itself on well-written code, the irony meter goes off the scale.
From where I stand, the OpenBSD project has been consistent on insulating itself against future legal issues, no matter how remote, with the idea that your security should not be restrained by anyone other than you.
What is "security" though and what it its aim? To my way of thinking, what happened to me last night wherein a box misbehaved and caused indigestion on an entire broadcast domain was a non-trivial security and availability incident. On the scale of badness, it's somewhat worse than a "magic packet causes this box to reboot" flaw, but not as bad as a "box gets owned, sensitive data gets divulged" incident. In my world, at least, security and availability are intimately intertwined. Were they not, one could easily "win" the security "game" by the simple expedient of turning the host off. Mission accomplished!
I believe that idea has legs regardless of practical considerations and stands on it's own.
Besides, I won't discount OpenBSD out of hand for forging ahead, withstanding practical issues, considering the runs they've got on the board and the many facepalm fails we see in the diametrically opposed corporate world.
It might be a very good thing they've bothered to take the time on this.
The problem here is "insufficient paranoia about packets that come flying in over the transom, based on naive contemporaneous belief that a particular protocol number was not in use". I mean, gosh, who would ever send packets on an unused protocol number? And who other than us would get frustrated with the process and decide to forge ahead on their own. Most of us here are familiar with Postel's oft-quoted RFC793 robustness principle ("be conservative in what you do, be liberal in what you accept from others"). Yet, when one is engaging in an off-label use of any protocol, identifier, etc. it is incumbent on the protocol designer to mark their traffic in a particular way so that it is easy to identify, both for themselves and for others. Sure, one could argue that this is merely abstracting away the semantics of the protocol number field (hopefully to a field with more data space) but the whole point is to not accidentally interoperate with something with which you are not prepared to interoperate. Stated another way, nothing is keeping me from using udp/139 for something else so long as my packets aren't misinterpreted by SMB servers out there as being SMB, and so long as I don't accidentally eat someone else's SMB and do something stupid. Would you eat food that someone left on your doorstep with no note and no hint as to who it came from? Obviously from your mom, right? I mean who else would leave food on your doorstep? How about Halloween candy with open wrappers? The comparisons in the messages you cited to a four year old may not be that far off. -r