nova team mailing list archive

[Joshua McKenty <jmckenty@xxxxxxxxx>]

We *have*, actually, experimented with running snort -inline as an L2 IDS,
but the VMs turned out to be a lousy place for it. (Weird/bad things happen
in linux bridging occasionally).

On Mon, Sep 20, 2010 at 8:15 PM, Dan Wendlandt <dan@xxxxxxxxxx> wrote:

>
>
> 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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> Mailing list: https://launchpad.net/~nova
> Post to     : nova@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~nova
> More help   : https://help.launchpad.net/ListHelp
>
>