carping about CARP

Fri Nov 30 15:35:14 UTC 2012

Comments inline ... as best I can.

On 30/11/2012, Robert E. Seastrom <rs at seastrom.com> wrote:
>
> 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.

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
>
>