On Wed, Sep 15, 2010 at 4:33 AM, Soren Hansen <[email protected]> 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________ Mailing list: https://launchpad.net/~nova Post to : [email protected] Unsubscribe : https://launchpad.net/~nova More help : https://help.launchpad.net/ListHelp
