nova team mailing list archive

[Dan Wendlandt <dan@xxxxxxxxxx>]

On Wed, Sep 15, 2010 at 4:33 AM, Soren Hansen <soren@xxxxxxxxxx> wrote:

> I have a spec[1] and a corresponding branch[2] about making basic use of
> libvirt's nwfilter support. It basically just adds a snippet to the
> libvirt templates that enables a number of network filtering techniques.
> Specifically, it prevents MAC spoofing, ARP spoofing, and IP spoofing. I
> didn't bother making this configurable, since it seems like the sort of
> thing everyone will always want. As such, there's no API call to enable
> it, nor is there a setting in the datamodel that enables/disables it.
>
>
Hi Soren,

Thanks for sending this out.  My vote would be to expose this as optional,
at least with respect to ARP and IP packets.  Such filters definitely make
sense in a "flat" network model like Amazon, but there are interesting use
cases (in addition to what Josh mentioned) for clouds that choose to expose
a private network (e.g., VLAN) model:

1) Using a VM as an L3 Firewall/NAT.  In this scenario, a firewall VM might
have VIFs on both a "public" and "private" network, with VM hosts only on
the "private" network.  The firewall VM must be able to transmit packets
packets with many different source IP addresses (enforcing a particular MAC
and ARP limits, however, would still be fine).

2) A common mechanism for primary-secondary failover in some clouds is to
run two VMs that both provide a particular service and have a "fail-over" IP
that can float between the two.  If the secondary fails to get heartbeat
responses from the primary, it will "steal" the fail-over IP address, for
example, using a gratuitous ARP with its MAC address for the fail-over IP.
This technique is definitely common in clouds with per-tenant private
network, but I believe it is also supported in some clouds with a flatter
networking model (in fact, I believe that Rackspace provides such a
capability:
http://cloudservers.rackspacecloud.com/index.php/IP_Failover_-_High_Availability_Explained).
 In this case, limiting a VM to using a single IP for ARP and IP would
be
prohibitive, though MAC filters would be fine.

3) The final scenario is a case where customers may want to control their
own IP addressing, and thus the cloud provider and hypervisor layer does not
know what IP addresses to enforce for IP / ARP traffic.   This applies only
in the context of private per-tenant network, for example, if a customer
wishes to connect a network in the cloud to a network on their on premises,
or simply wants to use the same RFC 1918 space they used in the data center
before transitioning an app to the cloud.

In sum, I think there are some compelling reasons to provide the option of
not enforcing a particular IP address in ARP / IP packets sent by a VM.  Off
the top of my head I can't think of such well-known use cases for needing to
disable MAC address spoofing protections (anyone using a VM as an L2 bridge
for transparent IDS?) but I wouldn't be surprised if someone else did.

Thanks,

Dan


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira Networks, Inc.
www.nicira.com | www.openvswitch.org
cell: 650-906-2650
~~~~~~~~~~~~~~~~~~~~~~~~~~~