[171592] in North American Network Operators' Group
Re: US patent 5473599
daemon@ATHENA.MIT.EDU (Jared Mauch)
Tue May 6 21:51:51 2014
X-Original-To: nanog@nanog.org
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <CAPKkNb7-+5iu02Pm5rSNd94L8M8UXPsHXbvN6h5bCK4LMS34YQ@mail.gmail.com>
Date: Tue, 6 May 2014 21:51:41 -0400
To: "Constantine A. Murenin" <mureninc@gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On May 6, 2014, at 9:11 PM, Constantine A. Murenin <mureninc@gmail.com> =
wrote:
> On 6 May 2014 15:17, David Conrad <drc@virtualized.org> wrote:
>> Constantine,
>>=20
>> On May 6, 2014, at 4:15 PM, Constantine A. Murenin =
<mureninc@gmail.com> wrote:
>>>> Protocol 112 was assigned by IANA for VRRP in 1998.
>>>>=20
>>>> When did OpenBSD choose to squat on 112?
>>>=20
>>> If you don't use it, you lose it.
>>=20
>> Are you suggesting no one is running VRRP? Surprising given RFC 5798.
>>=20
>> By the way, according to Wikipedia, it would seem the OpenBSD =
developers decided to squat on 112 in 2003, 5 years after 112 was =
assigned.
>=20
> Your point being?
That the "BSD" community sometimes doesn't play well with others, and =
certainly won't fess up when they make a mistake and cause collateral =
damage. It's clear to me this discussion is becoming a losing prospect =
for all sides, it reminds me of all the small ways the BSD community has =
frustrated me, from not fixing defects found in -RC images that would =
prevent successful upgrades due to driver bugs to lack of hardware =
support. =20
>=20
>>=20
>>> There are only so many protocol numbers; out of those potentially
>>> available and non-conflicting,
>>=20
>> Yes. That is exactly why most responsible and professional developers =
work with IANA to obtain the assignments they need instead of =
intentionally squatting on numbers, particularly numbers known to be =
already assigned.
>>=20
>>> it was deemed the best choice to go
>>> with the protocol number that was guaranteed to be useless =
otherwise.
>>=20
>> Except it wasn't useless: it was, in fact, in use by VRRP. Further, =
the OpenBSD developers chose to squat on 240 for pfsync - a number that =
has not yet been allocated. If the OpenBSD developers were so concerned =
about making the best choice, it seems odd they chose an allocated =
number for one protocol and an unallocated number for another protocol.
>=20
> Can you explain why exactly do you find this odd?
Because it's further polluting the ecosystem that we all depend on to =
operate properly. Asking for a number shouldn't be that hard and there =
are many people who can help shepherd these things through the =
community. The problem is when folks just squat on numbers and don't =
move. There have been collisions over the years that one can see =
documented in /etc/services on hosts that have been worked around, this =
isn't the first time, nor i'm sure will it be the last.
> VRRP/HSRP have had only one protocol number allocated to it; it's not
> like it had two, so, another one had to come out of somewhere else.
Yes, I think the issue here is that CARP is the interloper. You don't =
mind me coming over and bringing my trash to your back yard do you? =20
>=20
>>=20
>> To be honest, it would seem from appearances that OpenBSD's use of =
112 was deemed a "cute" (that is, unprofessional and irresponsible) way =
for the OpenBSD developers to say 'screw you' to the IETF, IANA, Cisco, =
network operators, etc. The fact that OpenBSD developers continue to =
defend this choice is one reason why I won't run OpenBSD (or CARP).
>>=20
>>> Any complaints for Google using the https port 443 for SPDY?
>>=20
>> AFAIK, the use of SPDY does not preclude the use of HTTPS on the same =
network. The fact that in addition to the OpenBSD developers choosing to =
use 112, they also chose to use the MAC addresses used for VRRP, thus =
making it impossible to run both VRRP and CARP on the same network due =
to MAC address conflicts would suggest you might want to pick a better =
analogy.
>=20
> Well, that's kinda the issue here -- the comparison with SPDY is
> actually quite valid. I haven't seen any facts that CARP actually
> precludes you from using VRRP on your network, unless you use broken
> VRRP/HSRP implementations (BTW, did you thank OpenBSD for forcing
> Cisco to fix those?
I'm certainly an advocate for fixing bugs in software. If OpenBSD has =
decided to participate in the community vs running off, I think you =
would have seen more "thanks" vs people being upset. I've been involved =
in a number of negative testing operations against router vendors that =
found defects. Did you work closely with a CERT or the PSIRT team? If =
not, that may be the sign of what is going on here.
> or would you rather retain an extra attack vector
> for your routers?), or configure CARP and VRRP to use the same MAC
> addresses through the same Virtual ID setting (user error), when
> clearly a choice is available. On the contrary, it's actually clearly
> and unambiguously confirmed in this very thread that both could
> coexist just fine:
> http://mailman.nanog.org/pipermail/nanog/2014-April/066529.html .
SPDY is sitting on the same well known port number but with a different =
protocol (udp vs tcp) so they can co-exist. There isn't really a true =
collision in the fact that an application listening to a socket will get =
the wrong packet. You either get SOCK_DGRAM or SOCK_STREAM.
> So, then the only problem, perhaps, is that noone has apparently
> bothered to explicitly document that both VRRP and CARP use
> 00:00:5e:00:01:xx MAC addresses, and that the "xx" part comes from the
> "Virtual Router IDentifier (VRID)" in VRRP and "virtual host ID
> (VHID)" in CARP, providing a colliding namespace, so, one cannot run
> both with the same Virtual ID on the same network segment.
Or that CARP didn't get their OUI, ask for help from one of the vendors =
that supports *BSD for use of their space or something else.
> Why exactly is this not documented? You could always claim,
> "politics", and it probably was back then 10 years ago when this story
> developed; but, in today's reality, OpenBSD is quite well known for
> its minimalism in all things UNIX, just as Apple in all things visual
> design. The likelihood of someone mixing CARP and VRRP, on the same
> network segment / same VLAN, and with the same Virtual IDs, and
> without ever hearing of the controversies from which CARP had to be
> born (and being curious of the origins of the "cute" name), seems
> quite small to me. So, documenting it at this point would be quite
> pointless, if not only for the future generations or Google reference.
>=20
> So, just as always, much ado about nothing. If someone sends a good
> documentation patch, without making the change seem out of place,
> it'll probably be committed into the tree shortly.
I think it's easy to interpret it as much ado about nothing, but clearly =
there are some scars on each side.
- Jared
