[171577] in North American Network Operators' Group
Re: US patent 5473599
daemon@ATHENA.MIT.EDU (Constantine A. Murenin)
Tue May 6 14:55:04 2014
X-Original-To: nanog@nanog.org
In-Reply-To: <5573.1399388210@turing-police.cc.vt.edu>
Date: Tue, 6 May 2014 11:54:53 -0700
From: "Constantine A. Murenin" <mureninc@gmail.com>
To: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On 6 May 2014 07:56, <Valdis.Kletnieks@vt.edu> wrote:
> On Tue, 06 May 2014 09:22:37 +0200, Henning Brauer said:
>> * Nick Hilliard <nick@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 prob=
lem,
> or was believed to be a hypothetical that wouldn't happen in the real wor=
ld.
> 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 posit=
ion that these RAND standards must not be implemented by us, and we must de=
viate from the standard. We find all this rather Unreasonable and Discrimin=
atory and we *will* design competing protocols. Some standards organization=
, eh?
>>>> On August 7 2002, after many communications, Robert Barr (Cisco's lawy=
er) firmly informed the OpenBSD community that Cisco would defend its paten=
ts for VRRP implementations -- meaning basically that it was impossible for=
a free software group to produce a truly free implementation of the IETF s=
tandard protocol.
>>>> We read the patent document carefully and ensured that CARP was fundam=
entally 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 firewa=
lls, 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 p=
acket 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 ce=
rtainly cannot afford them.
>>>> As a final note of course, when we petitioned IANA, the IETF body regu=
lating "official" internet protocol numbers, to give us numbers for CARP an=
d pfsync our request was denied. Apparently we had failed to go through an =
official standards organization. Consequently we were forced to choose a pr=
otocol number which would not conflict with anything else of value, and dec=
ided 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 r=
eply.
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.
