[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
carping about CARP
- Subject: carping about CARP
- From: rs at seastrom.com (Robert E. Seastrom)
- Date: Fri, 30 Nov 2012 07:44:26 -0500
- In-reply-to: <[email protected]om> (David Walker's message of "Fri, 30 Nov 2012 19:29:50 +1030")
- References: <[email protected]> <[email protected]om>
David Walker <davidianwalker at 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
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.