[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 2/2] bridge driver: don't masquerade local subnet broadcast/multicast packets

I'm not sure if everyone that needs to see this discussion are
subscribed to RH bugzilla bug #709418 so I will repeat my comments from
comment #12 on that bug here:

On 13-05-27 10:34 PM, Laszlo Ersek wrote:
> Packets sent by guests on virbrN, *or* by dnsmasq on the same, to
> - (netmask-independent local network broadcast
>   address), or to
> - (local subnetwork multicast range)

Multicast is much wider than just  Per my patch in
attachment 526549 [details], it's in fact  All multicast
needs to be exempt from NAT.

Quoting from Wikipedia article

IPv4 multicast addresses are defined by the leading address bits of
1110, originating from the classful network design of the early Internet
when this group of addresses was designated as Class D. The Classless
Inter-Domain Routing (CIDR) prefix of this group is

Indeed, Wikipedia is not authoritative, but it does provide a good
starting point to finding authoritative information if you want.

I suppose the authoritative doc is at
or somesuch.  It does not explicitly say but it certainly
implies it in discussing the entire space from through

> diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
> index d5886fe..2b3b250 100644
> --- a/src/network/bridge_driver.c
> +++ b/src/network/bridge_driver.c
> @@ -1542,6 +1542,9 @@ networkRefreshDaemons(struct network_driver *driver)
>      }
>  }
> +static const char networkLocalMulticast[] = "";

This should be /8, not /24.  There are many multicast protocols that
operate outside of that network.  In fact they all must. is reserved and assignment must be made from IANA.

Let me give you a scenario where your fails to correct the

Imagine you have a cluster of VMs all with a network address of
192.168.122.[2-10]/24 and is your VM "server".  Now
imagine those VMs are using a multicast address of (just for
argument's sake).  Each node will be listening on for other
"members" of the group to build a list of members.

But once the packet from (say)> goes through the
"VM host"'s NAT it will look to the other group members to be from host, so they all add to their member list.  Then sends it's packet to, it goes through NAT also
and all of the group members notice they already have in
their group and just ignore it.  That goes on for all of the [2-10]
nodes and none of them get added to the group list.

That's because NAT broke the protocol.

Further, to your arguments in comment #13 in BZ #709418 about needing to
map ports > 1023 for security:

The source port mapping goal has some specific parameters to it.  It's
trying to avoid a VM from masquerading as it's host and leveraging it's
host's permission in the network.  But that's only a problem because the
VM is masquerading as the host.  When you exempt multicast from
masquerading you no longer have the problem of the VM being mistaken for
the host and therefore you don't need the "quasi-security" of not
allowing the VM to use ports < 1024.

Put another way, mapping the source port numbers is only a requirement
because the VM is borrowing the identity of the host.  Once you
eliminate the identity borrowing you can eliminate the need for the
safety guards that that lending is putting in place.


Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]