This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xense-devel] Re: [Xen-devel] RFC: virtual network access control

To: Gerd Hoffmann <kraxel@xxxxxxx>
Subject: Re: [Xense-devel] Re: [Xen-devel] RFC: virtual network access control
From: Reiner Sailer <sailer@xxxxxxxxxx>
Date: Fri, 28 Jul 2006 15:49:59 -0400
Cc: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, xense-devel@xxxxxxxxxxxxxxxxxxx, Bryan D Payne <bdpayne@xxxxxxxxxx>
Delivery-date: Fri, 28 Jul 2006 12:50:28 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44CA2983.3030602@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

xense-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 07/28/2006 11:13:07 AM:

> > We see other problems as well: IPtables seems to not see any of the
> > ethernet-bridged packets. If you wanted to use IPtables then you
> > would need to replace the ethernet bridge with routing each packet.
> You want CONFIG_BRIDGE_NETFILTER=y, this makes iptabes see bridged packets.
> Additionally you need CONFIG_NETFILTER_XT_MATCH_PHYSDEV=y, that allows
> matching on the physical device name for bridged packets.  That way you
> can filter by domain (because each domain has its own virtual bridge
> port) instead of ip/mac address.
> cheers,
>   Gerd

Using IPtables this way sounds like a feasible compromise for the short term.

There are drawbacks to this short-term solution:
* dependencies on user space tools (also coordination requirements wrt other users of IPtables)
* performance: rules add up in IPTables when the number of interfaces increases
* scalability: for every interface coming up we make a number of hypercalls to setup the filters to the existing interfaces [O(n) for sHype/ACM; other non-symmetric policies might involve more overhead]

For these reasons, I suggest that we include networking in our discussions about the long-term security architecture and related interfaces in Xen.

If there are no other suggestions then we will proceed following the suggestion to use IPtables and filtering based on devices.

Xen-devel mailing list