[171593] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: US patent 5473599

daemon@ATHENA.MIT.EDU (Constantine A. Murenin)
Tue May 6 22:43:21 2014

X-Original-To: nanog@nanog.org
In-Reply-To: <8E02EE5F-A0B8-40FF-87BB-F32D09E15FB4@puck.nether.net>
Date: Tue, 6 May 2014 19:43:11 -0700
From: "Constantine A. Murenin" <mureninc@gmail.com>
To: Jared Mauch <jared@puck.nether.net>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org

On 6 May 2014 18:51, Jared Mauch <jared@puck.nether.net> wrote:
>
> On May 6, 2014, at 9:11 PM, Constantine A. Murenin <mureninc@gmail.com> w=
rote:
>
>> On 6 May 2014 15:17, David Conrad <drc@virtualized.org> wrote:
>>> Constantine,
>>>
>>> On May 6, 2014, at 4:15 PM, Constantine A. Murenin <mureninc@gmail.com>=
 wrote:
>>>> Any complaints for Google using the https port 443 for SPDY?
>>>
>>> AFAIK, the use of SPDY does not preclude the use of HTTPS on the same n=
etwork. 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 i=
t impossible to run both VRRP and CARP on the same network due to MAC addre=
ss conflicts would suggest you might want to pick a better analogy.
>>
>> 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 de=
cided to participate in the community vs running off, I think you would hav=
e 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 t=
he 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 p=
rotocol (udp vs tcp) so they can co-exist.  There isn't really a true colli=
sion in the fact that an application listening to a socket will get the wro=
ng packet.  You either get SOCK_DGRAM or SOCK_STREAM.

SPDY does not use UDP, it uses TCP.  Check your facts.

CARP uses a VRRP version number that has not been defined by VRRP,
hence there is no conflict there, either.  The link from the quote
above has a quote from Henning.

>
>> 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 t=
hat supports *BSD for use of their space or something else.

Politics.  Again, this is a non-issue for most users -- there's a very
easy, straightforward and complete workaround.

C.

home help back first fref pref prev next nref lref last post