Comments inline ... as best I can. On 30/11/2012, Robert E. Seastrom <rs@seastrom.com> wrote:
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.
You should hammer on OpenBSD. However, as yet this is an unknown. http://openbsd.org/report.html As far irony goes, there is some here but I'm not sure what you've got is countable yet.
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.
Of course.
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!
The phrase you're looking for is denial of service, a known security phenomena.
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.
As far as not using the same protocol number, that's neither here nor there. Something I've noticed looking at information security is the taxonomy of Confidentiality, Integrity, Availability - which addresses your previous points. Something else I've noticed is the notion of security through obscurity and how it cedes the initative to the attacker. Experience tells me this is not lost on the OpenBSD folks. Translation, it's commonly understood that secure protocols shouldn't rely on trusting others to obey the rules ... and whether or not it's OpenBSD or Johnny Black Hat that's on 122 or whatever, if that causes issues then it's either down to the protocol or the administrator. I have no doubt OpenBSD understood all this. If I take Theo's word for it, he employed a mechanism available in the rfc (i.e. VRRP) to allow traffic to be differentiated. Regardless, if a competing implementation can cause a DoS or any other issue that's either a design failure that should be addressed in a subsequent rfc or if it's a design limitation, then it's a failure to concommittantly secure the network. Blaming OpenBSD for protocol number won't fly. If I'm to take Stuart's cue then somebody hasn't read the documentation. Simple.
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.
At a casual reading, looking at the security considerations of for example ... http://tools.ietf.org/rfc/rfc3768.txt ... suggests to me that there are exploitable vectors inherent to this protocol. I'll say it again, I'm no subject matter expert. I'd be happy for you point me in the right direction, otherwise you're going to have to wait for me to get up to speed. Otherwise see previous, if there are no mechanisms to secure VRRP or CARP then either the network or the machine needs to be secure or the protocol shouldn't be in service or relied upon.
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.
No matter what protocol we look at, ultimately that comes down to protocol design. After that is network design. If a protocol is open to attack by unauthenticated users then it's up to me to secure the network against unauthenticated users. Expecting only legitimate traffic no matter what the door or window we're looking at is not the right way to do it. The bad guys certainly don't care either way whether you want malformed packets or not or complimentary looking implementations or not.
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