US patent 5473599

Tue May 6 18:54:53 UTC 2014

On 6 May 2014 07:56,  <Valdis.Kletnieks at vt.edu> wrote:
> On Tue, 06 May 2014 09:22:37 +0200, Henning Brauer said:
>> * Nick Hilliard <nick at foobar.org> [2014-04-26 22:56]:
>> > the situation was created by the openbsd team, not the ieee, the ietf or
>> > iana.
>>
>> that's nothing short of a lie.
>
> Umm.. remind me who chose the conflicting value and shipped product that used
> it, when they knew (or should have known) that it would be in conflict?
>
> I'd almost accept an assertion that the issue wasn't recognized as a problem,
> or was believed to be a hypothetical that wouldn't happen in the real world.
> But trying to deny who picked the number doesn't help the situation.

The situation is actually very clearly documented in the commentary to
OpenBSD 3.5 release song on the web-site:

http://www.openbsd.org/lyrics.html#35

Let me quote some excerpts:

>>>> As free software programmers, we therefore find ourselves in the position that these RAND standards must not be implemented by us, and we must deviate from the standard. We find all this rather Unreasonable and Discriminatory and we *will* design competing protocols. Some standards organization, eh?

>>>> On August 7 2002, after many communications, Robert Barr (Cisco's lawyer) firmly informed the OpenBSD community that Cisco would defend its patents for VRRP implementations -- meaning basically that it was impossible for a free software group to produce a truly free implementation of the IETF standard protocol.

>>>> We read the patent document carefully and ensured that CARP was fundamentally different. We also avoided many of the flaws in HSRP and VRRP (such as an inherent lack of security). And since we are OpenBSD developers, we designed it to use cryptography.

>>>> To date, we have built a few networks that include as many as 4 firewalls, all running random reboot cycles. As long as one firewall is alive in a group, traffic through them moves smoothly and correctly for all of our packet filter functionality. Cisco's low end products are unable to do this reliably, and if they have high end products which can do this, you most certainly cannot afford them.

>>>> As a final note of course, when we petitioned IANA, the IETF body regulating "official" internet protocol numbers, to give us numbers for CARP and pfsync our request was denied. Apparently we had failed to go through an official standards organization. Consequently we were forced to choose a protocol number which would not conflict with anything else of value, and decided to place CARP at IP protocol 112. We also placed pfsync at an open and unused number. We informed IANA of these decisions, but they declined to reply.

Frankly, I don't really see what the huge loss is.  Perhaps people
should realise that OpenBSD has recently removed The Heartbeat
Extension from TLS in libssl, and boycott the upcoming LibreSSL, since
its likelihood of having another heartbleed has been so reduced, yet
the API is still compatible with OpenSSL.  ???

C.