netdev - Re: [PATCH net] vxlan: revert per-vxlan port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 22 May 2013 22:14:39 -0400
From:	David Stevens <dlstevens@...ibm.com>
To:	Stephen Hemminger <stephen@...workplumber.org>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	netdev-owner@...r.kernel.org
Subject: Re: [PATCH net] vxlan: revert per-vxlan port

Stephen Hemminger <stephen@...workplumber.org> wrote on 05/22/2013 
08:39:54 PM:

> The per-vxlan device stuff is the issue. I don't think it works
> as is in 3.10 because there is no real way to use it to receive.
> And don't want to let it out broken. By reverting that part, we avoid
> raising false expectations.
> 

Of course you can use it to receive; the remote hosts can be
listening on a different port and this is the only mechanism
to send to those if there are not fdb entries on the local machine.

So, for example, host A:
binds to 1234
has no fdb entries, but sets the default remote port to 4789

host B
binds to 4789
has no fdb entries and sets the default remote port to 1234

...or you have an agent listening on a multicast address with port 5429
and the agent's job is to dynamically populate the fdb tables of any
hosts that don't have matching entries. All the VXLAN instances bind
to, say 4789, and the agent binds to port 5429. The agent receives a
packet, and adds an entry to the fdb table on the sending host where
the destination is the actual VXLAN receiver with port 4789. But the
default port on all of them for this kind of set-up is correctly the
different 5429, not 4789.

These configurations have nothing to do with multiple listen ports,
and reverting the patch prohibits an admin from doing it at all.
In the first set up, you can link two segments on different ports
without knowing any destination MAC addresses. In the second, you
can separate traffic not matching any destination MAC from traffic
with a known destination, and use that to fill forwarding tables.

I know these configurations don't match your sense of how VXLAN
should be used, but these are not "broken", do receives perfectly fine,
and have no dependency at all on multiple listen ports. I don't know
what  "false expectations" you think are there-- I think anyone
changing the default destination port to a different value from
the binding port simply expects that transmits using the default
will go to one port and received packets will go to another. Deciding
in advance that that is never appropriate is short-sighted; that
decision belongs with the admin setting it up. Reverting the patch
removes that choice.

                                                        +-DLS

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html