Comments inline ... as best I can.
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.
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.
