netdev - Re: [PATCH net-next] add DOVE extensions for VXLAN

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]

Message-ID: <OFD9622F46.08427B4F-ON85257AB5.00792B0C-85257AB5.007B6F17@us.ibm.com>
Date:	Tue, 13 Nov 2012 17:28:17 -0500
From:	David Stevens <dlstevens@...ibm.com>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] add DOVE extensions for VXLAN

Stephen Hemminger <shemminger@...tta.com> wrote on 11/13/2012 04:28:42 PM:

> 
> There are some issues with this.
>  1. DOVE flag is mixing multiple functions (arp and route) together,
>     users may want one without the other.

        I can separate these.

>  2. There is an implicit assumption that IP stack has valid IP address
>     in the tenant network (vxlan). This is rarely the case. For security
>     and other reasons, in my opinion the best practice is not to have
>     the bridge as part of the tenant network.

        No, actually for testing I didn't set an IP address on the tunnel
endpoint at all. The neighbor table entries must be in the domain, but
they are only used within the domain when the tunnel endpoint is on a
bridge and the host has no IP address on that interface.

>  3. Misses might be common and this could easily be used to DoS the host
>     from a malicious guest.

        Yes. The management piece can add forwarding table entries with
"0.0.0.0" as the dst IP address to disable MAC misses, and neighbor
table entries to disable IP misses, but it is our intention to have all
reachable destinations with both forwarding table and neighbor table
entries and no learning or multicast address (ie, no forwarding of 
anything
that isn't in the forwarding table). And yes, we want a notification
for every miss packet.
        Someone who doesn't want all of them shouldn't use this feature.
If we're dropping the "dove" flag in favor of individual flags for each
feature, then I could make this into "l2miss" and "l3miss" flags and
they should default off, of course.

                                                        +-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